From nobody Tue Nov 5 12:41:16 2019 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 D6DCB12090F for ; Tue, 5 Nov 2019 12:41:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9icq-e2_Pib for ; Tue, 5 Nov 2019 12:41:12 -0800 (PST) Received: from mail-vs1-f48.google.com (mail-vs1-f48.google.com [209.85.217.48]) (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 EA056120BB2 for ; Tue, 5 Nov 2019 12:41:11 -0800 (PST) Received: by mail-vs1-f48.google.com with SMTP id c25so4088200vsp.0 for ; Tue, 05 Nov 2019 12:41:11 -0800 (PST) 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=Ch0jfAGIBeA8HL+CXItJMy51DWSMrnrMZnRksCezfFI=; b=B9h9heL0KiEIshbpMYsGYqJIbJcDgm3fe3WSg209kSXuu1jqNVavg8grHWBSqhbiKv 8k3iIGkg2iSj7OH0nJqIPlHUzr8qLV+EDj2npw16n0QSwp43dlOLz5lapPrwBMzMPnZU CMXajPYmy9SLTFlhvu0gydb32k7LWhdvIqAS7T8Lmbt5xR/zGAPinTYFcWLtXHAMro5a hWKYOuw7tn+iZwoYkXa7W6yMtI2+GLuCnpvM2VoNfWtWKoeX+2hsDRNr4x2kzve2IIac cXaPUyPW9IKA9OOQqULmn3HRnq9Yrs9/0TIHIG7l/aJag6qxntWAmDa63pix21tHzxMd Twng== X-Gm-Message-State: APjAAAULd2LPWN3Zws8dW0r74n6ERf/h7kHSMyzh5Y4Kxsl6LySftARS jCzaQY4zGxqB14/qZAihsH1AbJzoU5FRbJkkVl8iON2Q X-Google-Smtp-Source: APXvYqweg7UMYKK907F9OykNVqMY/fIyWddFugc/cx2y2lMtODcXHJ/k9Yao5G29iyu9W1XJ/blvXsx0IeM3AHr65u8= X-Received: by 2002:a05:6102:810:: with SMTP id g16mr16593989vsb.69.1572986470733; Tue, 05 Nov 2019 12:41:10 -0800 (PST) MIME-Version: 1.0 References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> In-Reply-To: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> From: Daniel Migault Date: Tue, 5 Nov 2019 15:40:59 -0500 Message-ID: To: add@ietf.org Content-Type: multipart/alternative; boundary="000000000000d31c3e05969f735c" Archived-At: Subject: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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: Tue, 05 Nov 2019 20:41:14 -0000 --000000000000d31c3e05969f735c Content-Type: text/plain; charset="UTF-8" Please find an analysis on DoH and privacy. The intent is to provide an analysis. Any feed backs are welcome! Yours, Daniel ---------- Forwarded message --------- From: Date: Mon, Nov 4, 2019 at 11:20 AM Subject: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-00.txt To: Daniel Migault A new version of I-D, draft-mglt-abcd-doh-privacy-analysis-00.txt has been successfully submitted by Daniel Migault and posted to the IETF repository. Name: draft-mglt-abcd-doh-privacy-analysis Revision: 00 Title: A privacy analysis on DoH deployment Document date: 2019-11-04 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/internet-drafts/draft-mglt-abcd-doh-privacy-analysis-00.txt Status: https://datatracker.ietf.org/doc/draft-mglt-abcd-doh-privacy-analysis/ Htmlized: https://tools.ietf.org/html/draft-mglt-abcd-doh-privacy-analysis-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-mglt-abcd-doh-privacy-analysis Abstract: This document provides an analysis on DoH impact on privacy 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 --000000000000d31c3e05969f735c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Please find an analysis on DoH and privacy. The intent= is to provide an analysis. Any feed backs are welcome!

= Yours,=C2=A0
Daniel
---------- Forwarded message ---------
From: <internet-dra= fts@ietf.org>
Date: Mon, Nov 4, 2019 at 11:20 AM
Subjec= t: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-00.txt=
To: Daniel Migault <mglt.ietf= @gmail.com>



A new version of I-D, draft-mglt-abcd-doh-privacy-analysis-00.txt
has been successfully submitted by Daniel Migault and posted to the
IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mglt-abcd-doh-privacy-a= nalysis
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A privacy analysis on DoH deployme= nt
Document date:=C2=A0 2019-11-04
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-mglt-a= bcd-doh-privacy-analysis-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-mglt-abcd-doh-privacy-an= alysis/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-mglt-abcd-doh-privacy-analysis-00<= br> Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-mglt-abcd-doh-priva= cy-analysis


Abstract:
=C2=A0 =C2=A0This document provides an analysis on DoH impact on privacy



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

--000000000000d31c3e05969f735c-- From nobody Tue Nov 5 13:34:48 2019 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 D433D120BC9 for ; Tue, 5 Nov 2019 13:34:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 R-pmt3thtTQ1 for ; Tue, 5 Nov 2019 13:34:46 -0800 (PST) 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 F0EC01208CB for ; Tue, 5 Nov 2019 13:34:45 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id r144so24396922iod.8 for ; Tue, 05 Nov 2019 13:34:45 -0800 (PST) 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=hztaiRyPiXWMPPmWaGMoiBxc2IiOlXcHxsRxig90ueQ=; b=D2a6JcvIMXt7xrLKLcZ89g3rP84FVCP0moy1MEqUNbpYE8LXEOcTl6tZ5FR/gX1wAk Ywp0BHgIUGsH+Ee/2md1OdOSBa1EquVd6J+ZCI0BvTBP8qKRMcP/RP96wJaC5fwTuMug gZXfUnaFjISkkmS4xAnOsmhnclkAvwVzPI+Swz9n1f5MpScl50vAeNb5/3Xa2oLnw4Wk Ldh9cigar05TvHVaSvMHNUHwOu/hsh8QMnjD2p0hOYR5O2MKEJhQpoVQRqnCOMaXfh5K zMKNq6xXxW4Fdgz0TTy9x2vKQ2Vd/StvH1OIauCg0o6IzkgLYbewkH5Lm+j/12bbTUUZ qT1A== 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=hztaiRyPiXWMPPmWaGMoiBxc2IiOlXcHxsRxig90ueQ=; b=UhlGSdjWfi6YMEZCNCTO3johEexBrscExKhsTTn+SiaNj3LO68D9WNlzAkeV2N3rsD WiWphK1Jvzpvyxp+MMTiIZVbkuZM8tMTNcdaWDznsNv6OAIfSHNViJvZ8n0CT7C0rHmW 3aXNpjCUH2/Qo2Wuq6bAdP3+pYI4Wmt6LhOtmKEYUieKP5DE7FJ0Z9fUmXMXQrcV0a4b 0qYGS1odhguAWVDnE2V2MeqmCc+3Xlzu7yGcOpzWcvG3+YEqu35CRVAvpVtpNmYf0DKp x3tWMCum3heZyYfWrxS/YY8KU2+hVU6YP74g57D63uAbKChDp8HFmbbUKRTRYLlo0AHC nx3A== X-Gm-Message-State: APjAAAUMzgnX+o34UP3iolPW87F4++sCxiCJ0CD6/XYDLdSyffaDPK9O +/DgRbknR8dmqUbdhJaomoiFPGhAp0YRCvjezKrK0zZ9MiQ= X-Google-Smtp-Source: APXvYqyPsvqb7NnzeizPTFt1oBkMMQmspWRYuq1Ypj+ljS3qCwa6AuKgqtJ0zYL8PIGTxwS1PiZj9pPBTjrWcOuXYuM= X-Received: by 2002:a02:9307:: with SMTP id d7mr5071955jah.103.1572989684994; Tue, 05 Nov 2019 13:34:44 -0800 (PST) MIME-Version: 1.0 References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> In-Reply-To: From: Rob Sayre Date: Tue, 5 Nov 2019 13:34:32 -0800 Message-ID: To: Daniel Migault Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000068d8220596a0337f" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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: Tue, 05 Nov 2019 21:34:48 -0000 --00000000000068d8220596a0337f Content-Type: text/plain; charset="UTF-8" On Tue, Nov 5, 2019 at 12:41 PM Daniel Migault wrote: > > Please find an analysis on DoH and privacy. The intent is to provide an > analysis. Any feed backs are welcome! > One aspect I've found common to criticisms of DoT and DoH is that they tend to focus on "privacy", which I take to mean confidentiality. It's true that these encrypted transports might not provide confidentiality, since the information in the query can currently leak in several ways. However, DoT and DoH do provide message integrity between the client and the selected resolver. It's difficult to argue that this property is a bad thing. thanks, Rob --00000000000068d8220596a0337f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 5, 2019 at 12:41 PM Daniel Mi= gault <daniel.migault=3D40ericsson.com@dmarc.ietf.org> wrote:
<= br>Please find an analysis on DoH and privacy. The intent is to provide an = analysis. Any feed backs are welcome!

One aspect I've found common to criticisms of DoT and DoH is that they= tend to focus on "privacy", which I take to mean confidentiality= . It's true that these encrypted transports might not provide confident= iality, since the information in the query can currently leak in several wa= ys.

However, DoT and DoH do provide message integr= ity between the client and the selected resolver. It's difficult to arg= ue that this property is a bad thing.

thanks,
Rob

--00000000000068d8220596a0337f-- From nobody Tue Nov 5 14:39:15 2019 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 CC53D120826 for ; Tue, 5 Nov 2019 14:39:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, 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 UWv1Btmasm8y for ; Tue, 5 Nov 2019 14:39:11 -0800 (PST) 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 5BB98120025 for ; Tue, 5 Nov 2019 14:39:11 -0800 (PST) Received: by mail-qv1-xf33.google.com with SMTP id cg2so628527qvb.10 for ; Tue, 05 Nov 2019 14:39:11 -0800 (PST) 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=7JO+WqmDlmky6lpZyQk5DzS9Zx7bThqSXv1ex4Ap6lo=; b=ArJ+omtKsnO3AJGdcH+I3lXg8nUw0sb06Q0sbGb4/8X8CFbWKQ+pNDR7fYNKJhHHwF ci/YxhJV++NhbNegDlH8brb3LUhN6i7VT+FTLa0kD8NmKy4N1jmQUq3k5TxabqfyAqnq 0nSxuGfUJji+Wk/RgbSkLsmeJ4lWhAd5Co2d1vfUEpS0FHv2WOLIEwYxEetulpryob0v KWWOw2FJZNNohxWzTXvWmr9Fjaz39JlMnltXdWKMU7GCPr4sXKE9hO554ClgUUG/xjOn VtHY/eEBEWBF/rJKvFPWkW0WYasUrmBaYqDA4iL7DCgmV3SiI7HimU7CPs2NGQHuu9iu LHCw== 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=7JO+WqmDlmky6lpZyQk5DzS9Zx7bThqSXv1ex4Ap6lo=; b=NKhx3pPhW2K7uwv+NGzbDJCR06B0FQ/bQmnXZNqg1vG27wjMYEL9aRpIaWC0s4F7gH es5gTwPcxEbq4ArnC/pnhsvqldSRqDJ3prEY2dMlZ/h+c7dXkcUzOnntKeHh7kpiCTYA jzL1KaB0etXTfeM7zzTDKSyk2ttU+8m7v0wAgdlu5phXN5htD+NpaRQOy2Rz8ZI50z3/ odPdSNTIDwonYAfMPPIdhSc19sRvloP3cLOA7JhCXMOOr/omrndDzbsyQS5kNf/Jh5/p d6dncQSaStcBiIaIGDcXznPeH+MVIWRQmQpiXRMun2fRjLWYLPDEQOGe2/nTjNAZ0LZN 8kmw== X-Gm-Message-State: APjAAAW7UX4cL7zKnUVLl6eh5HAJvyd0YB9B+IsdOV1vjeK3hGRJZ1z9 j/v7E1DZuEjWYZ/jH6Ypf0KdPBXUgn74lvG3bxs= X-Google-Smtp-Source: APXvYqwZh8M90DNp0XvXbmPT35Y4XOkjgHmDWGWAtHcG4YkvUvV9RKrHxotQQHQSkq7oZFY1WlNpnvW+T8OZPAyi4wY= X-Received: by 2002:a0c:ee90:: with SMTP id u16mr9073631qvr.56.1572993550120; Tue, 05 Nov 2019 14:39:10 -0800 (PST) MIME-Version: 1.0 References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> In-Reply-To: From: Alec Muffett Date: Tue, 5 Nov 2019 22:38:33 +0000 Message-ID: To: Rob Sayre Cc: Daniel Migault , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000c9fb820596a11990" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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: Tue, 05 Nov 2019 22:39:14 -0000 --000000000000c9fb820596a11990 Content-Type: text/plain; charset="UTF-8" On Tue, 5 Nov 2019 at 21:34, Rob Sayre wrote: > One aspect I've found common to criticisms of DoT and DoH is that they > tend to focus on "privacy", which I take to mean confidentiality.. It's > true that these encrypted transports might not provide confidentiality, > since the information in the query can currently leak in several ways. > > However, DoT and DoH do provide message integrity between the client and > the selected resolver. It's difficult to argue that this property is a bad > thing. > This; it's a curious blind spot, similar to the perennial "Why would {Facebook*, NYTimes, BBC} run a Tor Onion site?" question. Answer: security models contain more than {anonymity, privacy} and (in the latter case) Tor Onion Networking offers benefits like integrity and assurance of to whom you are connected. Assurances which DoH also affords over Do53, specifically. -a * https://www.wired.com/2014/10/facebook-tor-dark-site/ -- > http://dropsafe.crypticide.com/aboutalecm --000000000000c9fb820596a11990 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, 5 Nov 2019 at 21= :34, Rob Sayre <sayrer@gmail.com= > wrote:
One aspect I've found common t= o criticisms of DoT and DoH is that they tend to focus on "privacy&quo= t;, which I take to mean confidentiality.. It's true that these encrypt= ed transports might not provide confidentiality, since the information in t= he query can currently leak in several ways.

Howev= er, DoT and DoH do provide message integrity between the client and the sel= ected resolver. It's difficult to argue that this property is a bad thi= ng.

This; it&#= 39;s a curious blind spot, similar to the perennial "Why would {Facebo= ok*, NYTimes, BBC} run a Tor Onion site?" question.

Answer: security models contain more than {anonymity, privacy} and (= in the latter case) Tor Onion Networking offers benefits like integrity and= assurance of to whom you are connected.

Assurance= s which DoH also affords over Do53, specifically.

= =C2=A0 =C2=A0 -a


--=C2=A0
http://dropsafe.crypticide.= com/aboutalecm
--000000000000c9fb820596a11990-- From nobody Wed Nov 6 06:20:24 2019 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 D09291208B0 for ; Wed, 6 Nov 2019 06:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nrYquX8wQeWN for ; Wed, 6 Nov 2019 06:20:20 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C9E1208AE for ; Wed, 6 Nov 2019 06:20:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B3B79BE47; Wed, 6 Nov 2019 14:20:18 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsgbEfvA5SKj; Wed, 6 Nov 2019 14:20:16 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id BEAFBBE3E; Wed, 6 Nov 2019 14:20:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1573050016; bh=FKVcx9S8F0YjSFaZJ1UDa4/A5ZfjzyRO7wO9oYcyzuU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=FrFBpLUEgYIeVjEjKxekruOW7GHC8+8mnZZ1cJfNDkSFUIEeXBk+r5haRsyE6RJuE 3GSEzuoJW+o4/EsSFIIwWOnZBA3ftwldeeJnpE2EMtsMdJnVU7JdrT8R++qvSLCYhX ti99GFFZYL3Qariyp36yxtx7hsciVatMqLLIaSyg= To: Daniel Migault , add@ietf.org References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> Date: Wed, 6 Nov 2019 14:20:15 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="XAZY5Zf5yAE2xbv27kTTsJOOm8MTczgcL" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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, 06 Nov 2019 14:20:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --XAZY5Zf5yAE2xbv27kTTsJOOm8MTczgcL Content-Type: multipart/mixed; boundary="tsN0gf7ZTtEqhXkRt8ioCGVgGXAMktrHI"; protected-headers="v1" From: Stephen Farrell To: Daniel Migault , add@ietf.org Message-ID: <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-00.txt References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> In-Reply-To: --tsN0gf7ZTtEqhXkRt8ioCGVgGXAMktrHI Content-Type: multipart/mixed; boundary="------------E90441BE695CB5AC64ADF481" Content-Language: en-US This is a multi-part message in MIME format. --------------E90441BE695CB5AC64ADF481 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Daniel, On 05/11/2019 20:40, Daniel Migault wrote: > Please find an analysis on DoH and privacy. The intent is to provide an= > analysis. Any feed backs are welcome! My feedback: - I don't see how this adds to the discussion. ISTM this is yet another one-sided description of the issues. What do you think is the added benefit of having this text in an Internet-draft? Honestly, I don't get it. - In particular, I don't think your "conclusion" that "the overall picture of concentration shows that it represents a threat to the end user's privacy" can be justified based on the content. I'm assuming "represents a threat" is not just weasel-wording for "might be" which is trivially true. If you mean anything stronger than "might be" then that's not justified IMO and if you mean "might be" or anything weaker, then it looks like stretching to find a pejorative way to describe things. Cheers, S. PS: In saying the above, I do think there are dangers in how DoH deployments might increase centralisation. But I also think that one-sided descriptions of those dangers make the conversations more, and not less, difficult. >=20 > Yours, > Daniel > ---------- Forwarded message --------- > From: > Date: Mon, Nov 4, 2019 at 11:20 AM > Subject: New Version Notification for > draft-mglt-abcd-doh-privacy-analysis-00.txt > To: Daniel Migault >=20 >=20 >=20 > A new version of I-D, draft-mglt-abcd-doh-privacy-analysis-00.txt > has been successfully submitted by Daniel Migault and posted to the > IETF repository. >=20 > Name: draft-mglt-abcd-doh-privacy-analysis > Revision: 00 > Title: A privacy analysis on DoH deployment > Document date: 2019-11-04 > Group: Individual Submission > Pages: 11 > URL: > https://www.ietf.org/internet-drafts/draft-mglt-abcd-doh-privacy-analys= is-00.txt > Status: > https://datatracker.ietf.org/doc/draft-mglt-abcd-doh-privacy-analysis/ > Htmlized: > https://tools.ietf.org/html/draft-mglt-abcd-doh-privacy-analysis-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-mglt-abcd-doh-privacy-analy= sis >=20 >=20 > Abstract: > This document provides an analysis on DoH impact on privacy >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submi= ssion > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 >=20 --------------E90441BE695CB5AC64ADF481 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------E90441BE695CB5AC64ADF481-- --tsN0gf7ZTtEqhXkRt8ioCGVgGXAMktrHI-- --XAZY5Zf5yAE2xbv27kTTsJOOm8MTczgcL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3C1p8ACgkQWrL68XsX K+oSDw//dYjYIHfDKes3J44APfIlMdCNvzUsPvkQ989AU9kiH0EOO3udalBZpkJP 1WqnPmzBC7lEk2Ql7KA8QxJ9TYbLe6HXcMMnwTl6hkBiVYaRKSH6Mx8H4ssNnZNc qIEiRSGu9DRWzB8arTHgFpSv1yjLmbJc0mgcR+EFhafWSF6pUcp7RjkdHBKNNDZ3 rwGp8a8HenQmRXe+Vd9ARph8LNgCYLRZnyk7oaQBQMQRA6VQGgnvaFX+UPlkwPit xqRvrCrdajGG2vMaK96cZW5byFFYHrz0EAk0VD3z9RoQKKBHgK/HNO3zKw34Ewum UG+z3EitxSOsK4FiJQoBFMndf1EP/xfrdfDztOPuJIQtx4ARl9ohCCZEb3XoFI4y KoPfBloYmZxPcRGJT7e/mY6NPLkzSGA9d3G6ne8TWBQz81O7zrBMFmp1Gj2Uu7Lk fL7bhUbjV1Q9EhhLjtyGIf6ZmEivZMv+Pz2T64KKSEuUmXs4Fia9W3xDFki+1CFg oxFywXz06av3bJoXM1kpMxHN4kw7lRj8ZUVnQHfy4tCIjE1IOPJpVg9anf8Sdhna dlXHHrCsHWOG7FJRykKEH4Ye5fa94+KnnUvsnsG85BzkyvFDGS83lEifzhpEPB6Y vbCKulhfJuTRdd9CZw2lZkplFNW1YKpEuvK9+a04gLcf71w31SY= =wlf5 -----END PGP SIGNATURE----- --XAZY5Zf5yAE2xbv27kTTsJOOm8MTczgcL-- From nobody Wed Nov 6 11:10:28 2019 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 A9B4B12001A for ; Wed, 6 Nov 2019 11:10:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 rh29f5tF1zGb for ; Wed, 6 Nov 2019 11:10:23 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640114.outbound.protection.outlook.com [40.107.64.114]) (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 6DDFB120044 for ; Wed, 6 Nov 2019 11:10:23 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UDbvQkjWzqXjqNEz874KF50+Tx9SGuq2Z3GSIlkxrSUvDO7BKmrBBbSlsjAuIP/Ck2SIIH0+BK+fNFXLiV3Ixj3MTrQc7pNYB/fRvszuup9lwrf+VVeh2Sf0U7whuPhyQFvKN+4JdeMYG43B/i/ioRZBYJ85Cq8/bD8W/3pkscy753GUze09N/zwVlLT/Jki0fNFDBNEkQ3QQmHbf8+7YBEBjiGgqrfdgsqph60/z0vlCY2R/dBaDU7h039XaMAoVu2aXvI4sKL5BmOl75Ps+kWTgk63gi741hZ5UT61FfmapP/WEQiMrfK/oeyf4fR6lRRQ4fG22whmk8HIdfVeIQ== 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=d1kRu7qNB4qQbxXyAoU/9XTENFqVv5UxF7WCP2V7B00=; b=mh6yfernixLFCcihvg4y4Kf9Hvoj4vaPKep0e7nytGRCwlr0OA8mqWuxTgtySXfp6o4rE6M5CWuZirI4OcpIM9ZM7G8PybGnXD2FHklkdGRIDFH6007K0hDK7WeqAlqonHNHM6dWmtJ3jOEYErVCWWMzPkUchgf4/gExXWX3kSgdlL7H8IrYlytJFNJiekVw38divPwUOVDKLFIpZW91Dlq/KLL/mJf9YKZ7IXZ1FfrVemk+Vf4wMuQIZJI9edvh3gcuXlTMw44qxEeg3Ek3WLqudTBbk6ZQDnMs7Wckd2wYIvx0U3qjqUHDoTWz43VAsYOipsibz+ZF72TuZQGFYw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d1kRu7qNB4qQbxXyAoU/9XTENFqVv5UxF7WCP2V7B00=; b=T8gBNBMcXBEdhyaHAMkggVpwEX8pN8v1LD7eA2c6pYaYmZf2Yhv9tJCSoFrFp0pEq5hp202DY/2XXcE3NirrcQecGu+Dan9XepsvpUh18DrhdWySV8EtsK7cEMeLemlrGF8Az2p0Z8y6D5Yfsv3aQhC97ml1oms7P+O0ESa2aEk= Received: from SN2PR00MB0077.namprd00.prod.outlook.com (10.167.20.149) by SN2PR00MB0224.namprd00.prod.outlook.com (10.167.19.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2465.0; Wed, 6 Nov 2019 19:10:21 +0000 Received: from SN2PR00MB0077.namprd00.prod.outlook.com ([fe80::a4d4:609:3efd:657a]) by SN2PR00MB0077.namprd00.prod.outlook.com ([fe80::a4d4:609:3efd:657a%12]) with mapi id 15.20.2469.000; Wed, 6 Nov 2019 19:10:21 +0000 From: Tommy Jensen To: Stephen Farrell , Daniel Migault , "add@ietf.org" Thread-Topic: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-00.txt Thread-Index: AQHVlBmqI+TJbrJbJk2D2aZbSQ7kPqd+MmqAgABJNKk= Date: Wed, 6 Nov 2019 19:10:20 +0000 Message-ID: References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> , <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> In-Reply-To: <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-11-06T19:10:20.541Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jensen.Thomas@microsoft.com; x-originating-ip: [2001:4898:80e8:1:e13d:ce9e:14de:9b2b] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ce2453f2-2969-4d7d-e959-08d762ecf823 x-ms-traffictypediagnostic: SN2PR00MB0224: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02135EB356 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(39860400002)(366004)(396003)(346002)(52314003)(189003)(199004)(316002)(55016002)(71200400001)(10090500001)(71190400001)(2501003)(6436002)(486006)(66556008)(105004)(6116002)(606006)(46003)(478600001)(476003)(446003)(52536014)(11346002)(19627405001)(66574012)(86362001)(9686003)(64756008)(186003)(66446008)(53546011)(54896002)(6506007)(102836004)(229853002)(6306002)(256004)(76116006)(91956017)(5660300002)(296002)(22452003)(7736002)(8936002)(15650500001)(66946007)(561944003)(99286004)(74316002)(7696005)(76176011)(33656002)(8990500004)(110136005)(81156014)(81166006)(8676002)(10290500003)(14444005)(966005)(6246003)(66476007)(2906002)(14454004)(236005)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR00MB0224; H:SN2PR00MB0077.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jO5IGUX0g3NZSAXCnMVAxeoB2+D7Ex4ueqD3337+O1AO3OuAOdZmfdbiAnM7VauryifK+daTLQROxtyQClT/7y4fC5Je1uUdFuF+LYBHNW9AaoVTLM/oN93at63ro2jtxvJgxI2DJJQh6jRNNux5j2WNN/y1Q83oBaPqbif4cDDGy3PZKrEzI2RKVS+lPEozXesMK6UK8y5uJ4PxQe2itvFEY2fiySvlr18kxunkeXdYg1LI5DWYHsYfzGbdFNlDoY2A3Wt6wuJjk+KNwKqR1bHXE3X0ksHNY3NKU27gKRB1z63U8aIs1ix0i3/BFwwsbh7JDuMbhxK1GN8JzaNfJxu42WjULOyI8gbsCKF4q+BLtGpWRlucmaJpA1SnVhkGj28ETITSKdny7Kq0GmKdeMrB7HDzUwxaoQe14FVe7YM+Um/t7XPBfDmVHGnM1NDs x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN2PR00MB0077009FBBB40FB2B3DD9B35FA790SN2PR00MB0077namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: ce2453f2-2969-4d7d-e959-08d762ecf823 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Nov 2019 19:10:20.9812 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: BwWvwxqsANDFbt6quVBwo8EKisW3bnx2MrwjZr3n2LBIKW85JdN6mWXcSRRO1UMmWYrd1I1aIlkqxc7wHjJAsg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR00MB0224 Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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, 06 Nov 2019 19:10:27 -0000 --_000_SN2PR00MB0077009FBBB40FB2B3DD9B35FA790SN2PR00MB0077namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hey Daniel, Adding onto Stephen's comments (+1 to not sure what the goal of this docume= nt is), I'll point out a reoccurrence of the common but false assumption th= at DoH always means browsers and always means centralization: draft>> DoH changes this paradigm in the way that an application can circum= vent the policy set by the end user, without the end user being aware of it= . Firstly, the encryption is performed by the application and as such does= not provide any visibility to the operating system. DoH doesn't change this paradigm at all, as it isn't a protocol just for ap= ps (see the Adaptive DNS proposal for an example of a platform providing Do= H). This problem (apps doing their own DNS and circumventing system configu= red policy) existed before and continues to exist with classic DNS; it just= so happened that the traffic was plain text so any network sniffing softwa= re could observe and possibly modify or block it. I consider that an unfort= unate side effect of plain text protocols, not a feature we should be worki= ng to preserve. It's not like apps doing their own DNS queries today are vi= sible to most users today, who don't know what packet inspection is. I think if we drive widespread adoption of encrypted DNS protocols by platf= orms and ISPs, we'll have better luck convincing well-behaved applications = to defer to platform configurations than any other approach. After all, why= build per-app experiences if the platform experience is already "good" in = the eyes of the privacy conscious? This will address the concern of central= ization of the DNS as well (which is not an inherent DoH problem, but an in= herent "default provider for all customers of X app/platform" problem). As far as ill-behaved applications go, they were going to do whatever they = wanted anyway, and pushing DoH adoption doesn't give them powers they didn'= t already have. At some point, the problem becomes one of the user needing = to decide what apps they trust which we cannot help with via protocol desig= n. Thanks, Tommy ________________________________ From: Add on behalf of Stephen Farrell Sent: Wednesday, November 6, 2019 6:20 AM To: Daniel Migault ; add@ie= tf.org Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-pr= ivacy-analysis-00.txt Hi Daniel, On 05/11/2019 20:40, Daniel Migault wrote: > Please find an analysis on DoH and privacy. The intent is to provide an > analysis. Any feed backs are welcome! My feedback: - I don't see how this adds to the discussion. ISTM this is yet another one-sided description of the issues. What do you think is the added benefit of having this text in an Internet-draft? Honestly, I don't get it. - In particular, I don't think your "conclusion" that "the overall picture of concentration shows that it represents a threat to the end user's privacy" can be justified based on the content. I'm assuming "represents a threat" is not just weasel-wording for "might be" which is trivially true. If you mean anything stronger than "might be" then that's not justified IMO and if you mean "might be" or anything weaker, then it looks like stretching to find a pejorative way to describe things. Cheers, S. PS: In saying the above, I do think there are dangers in how DoH deployments might increase centralisation. But I also think that one-sided descriptions of those dangers make the conversations more, and not less, difficult. > > Yours, > Daniel > ---------- Forwarded message --------- > From: > Date: Mon, Nov 4, 2019 at 11:20 AM > Subject: New Version Notification for > draft-mglt-abcd-doh-privacy-analysis-00.txt > To: Daniel Migault > > > > A new version of I-D, draft-mglt-abcd-doh-privacy-analysis-00.txt > has been successfully submitted by Daniel Migault and posted to the > IETF repository. > > Name: draft-mglt-abcd-doh-privacy-analysis > Revision: 00 > Title: A privacy analysis on DoH deployment > Document date: 2019-11-04 > Group: Individual Submission > Pages: 11 > URL: > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Finternet-drafts%2Fdraft-mglt-abcd-doh-privacy-analysis-00.txt&= ;data=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d76= 2c47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&= ;sdata=3Dw7GwUhz%2BIVSB5VW%2BtyEKvAUjTTh%2BNhq12tpVbM5Zw0o%3D&reserved= =3D0 > Status: > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-mglt-abcd-doh-privacy-analysis%2F&data=3D= 02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%= 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&sdata= =3DXmWL4PabqWROpOd1YmGsKfQ9ucjP16tanC5PnTuewAw%3D&reserved=3D0 > Htmlized: > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis-00&data=3D02%7C= 01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%7C72f= 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&sdata=3DtpXD= CA5qibyJU0%2FBcvkCHxRoKhWTZYi9s4fln0MQLx8%3D&reserved=3D0 > Htmlized: > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis&dat= a=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47= bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&sda= ta=3Dl4GflUzS14Z68kdSWxLzCjIYKoHWtY%2BwxFxCO5FY%2FEY%3D&reserved=3D0 > > > Abstract: > This document provides an analysis on DoH impact on privacy > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > --_000_SN2PR00MB0077009FBBB40FB2B3DD9B35FA790SN2PR00MB0077namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hey Daniel,

Adding onto Stephen's comments (+1 to not sure what the goal of this do= cument is), I'll point out a reoccurrence of the common but false assumptio= n that DoH always means browsers and always means centralization:

draft>> DoH changes this paradigm in the way that an application= can circumvent the policy set by the end user, without the end user being = aware of it.  Firstly, the encryption is performed by the application = and as such does not provide any visibility to the operating system.

DoH doesn't change this paradigm at all, as it isn't a protocol just for ap= ps (see the Adaptive DNS proposal for an example of a platform providing Do= H). This problem (apps doing their own DNS and circumventing system configu= red policy) existed before and continues to exist with classic DNS; it just so happened that the traffic was plain = text so any network sniffing software could observe and possibly modify or = block it. I consider that an unfortunate side effect of plain text protocol= s, not a feature we should be working to preserve. It's not like apps doing their own DNS queries today are visi= ble to most users today, who don't know what packet inspection is.

I think if we drive widespread adoption of encrypted DNS protocols by platf= orms and ISPs, we'll have better luck convincing well-behaved applications = to defer to platform configurations than any other approach. After all, why= build per-app experiences if the platform experience is already "good" in the eyes of the privacy= conscious? This will address the concern of centralization of the DNS as w= ell (which is not an inherent DoH problem, but an inherent "default pr= ovider for all customers of X app/platform" problem).

As far as ill-behaved applications go, they were going to do whatever they = wanted anyway, and pushing DoH adoption doesn't give them powers they didn'= t already have. At some point, the problem becomes one of the user needing = to decide what apps they trust which we cannot help with via protocol design.

Thanks,
Tommy
From: Add <add-bounces@i= etf.org> on behalf of Stephen Farrell <stephen.farrell@cs.tcd.ie><= br> Sent: Wednesday, November 6, 2019 6:20 AM
To: Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.or= g>; add@ietf.org <add@ietf.org>
Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd= -doh-privacy-analysis-00.txt
 

Hi Daniel,

On 05/11/2019 20:40, Daniel Migault wrote:
> Please find an analysis on DoH and privacy. The intent is to provide a= n
> analysis. Any feed backs are welcome!

My feedback:

- I don't see how this adds to the discussion. ISTM this
is yet another one-sided description of the issues. What do
you think is the added benefit of having this text in an
Internet-draft? Honestly, I don't get it.

- In particular, I don't think your "conclusion" that "the overall picture of concentration shows that it represents
a threat to the end user's privacy" can be justified based
on the content. I'm assuming "represents a threat" is not
just weasel-wording for "might be" which is trivially
true. If you mean anything stronger than "might be" then
that's not justified IMO and if you mean "might be" or
anything weaker, then it looks like stretching to find
a pejorative way to describe things.

Cheers,
S.

PS: In saying the above, I do think there are dangers in
how DoH deployments might increase centralisation. But I
also think that one-sided descriptions of those dangers
make the conversations more, and not less, difficult.

>
> Yours,
> Daniel
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Mon, Nov 4, 2019 at 11:20 AM
> Subject: New Version Notification for
> draft-mglt-abcd-doh-privacy-analysis-00.txt
> To: Daniel Migault <mglt.ietf@gmail.com>
>
>
>
> A new version of I-D, draft-mglt-abcd-doh-privacy-analysis-00.txt
> has been successfully submitted by Daniel Migault and posted to the > IETF repository.
>
> Name:           draf= t-mglt-abcd-doh-privacy-analysis
> Revision:       00
> Title:          A privacy= analysis on DoH deployment
> Document date:  2019-11-04
> Group:          Individua= l Submission
> Pages:          11
> URL:
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Finternet-drafts%2Fdraft-mglt-abcd-doh-privacy-analysis-00.txt&a= mp;data=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d= 762c47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&a= mp;amp;sdata=3Dw7GwUhz%2BIVSB5VW%2BtyEKvAUjTTh%2BNhq12tpVbM5Zw0o%3D&amp= ;reserved=3D0
> Status:
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-mglt-abcd-doh-privacy-analysis%2F&amp;data= =3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47b= cc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&amp;= sdata=3DXmWL4PabqWROpOd1YmGsKfQ9ucjP16tanC5PnTuewAw%3D&amp;reserved=3D0=
> Htmlized:
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis-00&amp;data=3D02%= 7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%7C7= 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&amp;sdata= =3DtpXDCA5qibyJU0%2FBcvkCHxRoKhWTZYi9s4fln0MQLx8%3D&amp;reserved=3D0
> Htmlized:
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis&amp;d= ata=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c= 47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&a= mp;sdata=3Dl4GflUzS14Z68kdSWxLzCjIYKoHWtY%2BwxFxCO5FY%2FEY%3D&amp;reser= ved=3D0
>
>
> Abstract:
>    This document provides an analysis on DoH impact on = privacy
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>
>
--_000_SN2PR00MB0077009FBBB40FB2B3DD9B35FA790SN2PR00MB0077namp_-- From nobody Wed Nov 6 11:35:34 2019 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 3344212026E for ; Wed, 6 Nov 2019 11:35:32 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 cw1yFfTbPO9d for ; Wed, 6 Nov 2019 11:35:29 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 436E012010C for ; Wed, 6 Nov 2019 11:35:29 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id h15so16006536qka.13 for ; Wed, 06 Nov 2019 11:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=i0d/bY8HSkxz8iYtbIXw2MWdI7ntp/VMgW2dBZSar0o=; b=qrzyuKfiopNlvRaTVanPshIzEAwE14uI1IAJbKXj2//2OKXFZvabnNeKQ4sRY96Vq0 6aLkg3vRTjclExhB1+nqhEl5MTaqd5qTpVv0BbcZnAbVVpzabLr0IPn0FLY6QtgUNFbN tdBkxI2RJX/37+u5fXfStPbr5+ZLT4h/lDLTxkL8cfHmaBsgci/5YJL9aaTqDqxsDVb4 IC652O6HBFvaf9jpnz/mFheIpAYiAkSE6uAu9cYMqmu38+Xv9hJUT+Z8ClYobbrT2p5u ACrwHnuMLvj4VeRHuUJAc5Zv0DOnKrrLgwgLQPBsA5+Qs5wQSYgQr3HNPytxxBqM5Rxi 8D6w== 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=i0d/bY8HSkxz8iYtbIXw2MWdI7ntp/VMgW2dBZSar0o=; b=XzrLtQeo9gq1B6SJxBseJZZNVCg9Ca5rw4KYG1bmpX7GyUPoJz4OnRgnRCcbv71sK8 z4pr4F2BiG84gvRDKdjdZKoFn88K6z4YrWSvYgZsLBHjw1FbTMMan9tBNOOFBPz9vu3a s7KvRg+4QNK+kkrD+cWySqXcgErvhMZ85avn4DAiYarICm5JhFzTcp1jTSImmctA+pCK G8XhAMmUJLj4ioPhdNF52N+YAXJba6y0GGDCfrXSw9u6WsbA0nrsoel7je7unDcU9zg9 FUrGiCl3lx5PMMbunZNsajl2Vblw/1QxeQoQKU7+sBTrGwexCcsbERYD22u4kJmwk6hG DfhQ== X-Gm-Message-State: APjAAAVpuI7IRjgS872mj0F/vLSnvlTQtULGJ1AX22LP6JjEhfK9m/nn /tGZQGreftcOaVihBXEfXg/cK06V6cVkL4MKHoAP5B6nAkU= X-Google-Smtp-Source: APXvYqwuDdq+Lq4R4ZsJmQDkEo3eFs+DfA2et2afBN2e+hUO3N6uHXvVhhC+ZI/UajzuTPMSHlrQDe0tM7frBWQWyIc= X-Received: by 2002:ae9:ec0a:: with SMTP id h10mr3491885qkg.334.1573068928007; Wed, 06 Nov 2019 11:35:28 -0800 (PST) MIME-Version: 1.0 References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> In-Reply-To: From: Bob Harold Date: Wed, 6 Nov 2019 14:35:16 -0500 Message-ID: To: Tommy Jensen Cc: Stephen Farrell , Daniel Migault , "add@ietf.org" Content-Type: multipart/alternative; boundary="000000000000a956cd0596b2a6ae" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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, 06 Nov 2019 19:35:32 -0000 --000000000000a956cd0596b2a6ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 6, 2019 at 2:10 PM Tommy Jensen wrote: > Hey Daniel, > > Adding onto Stephen's comments (+1 to not sure what the goal of this > document is), I'll point out a reoccurrence of the common but false > assumption that DoH always means browsers and always means centralization= : > > draft>> DoH changes this paradigm in the way that an application can > circumvent the policy set by the end user, without the end user being awa= re > of it. Firstly, the encryption is performed by the application and as su= ch > does not provide any visibility to the operating system. > > DoH doesn't change this paradigm at all, as it isn't a protocol just for > apps (see the Adaptive DNS proposal for an example of a platform providin= g > DoH). This problem (apps doing their own DNS and circumventing system > configured policy) existed before and continues to exist with classic DNS= ; > it just so happened that the traffic was plain text so any network sniffi= ng > software could observe and possibly modify or block it. I consider that a= n > unfortunate side effect of plain text protocols, not a feature we should = be > working to preserve. It's not like apps doing their own DNS queries today > are visible to most users today, who don't know what packet inspection is= . > > I think if we drive widespread adoption of encrypted DNS protocols by > platforms and ISPs, we'll have better luck convincing well-behaved > applications to defer to platform configurations than any other approach. > After all, why build per-app experiences if the platform experience is > already "good" in the eyes of the privacy conscious? This will address th= e > concern of centralization of the DNS as well (which is not an inherent Do= H > problem, but an inherent "default provider for all customers of X > app/platform" problem). > > As far as ill-behaved applications go, they were going to do whatever the= y > wanted anyway, and pushing DoH adoption doesn't give them powers they > didn't already have. At some point, the problem becomes one of the user > needing to decide what apps they trust which we cannot help with via > protocol design. > I agree with most of your points - but here you say "pushing DoH adoption doesn't give them powers they didn't already have". One concern is IF some major web service enables DoH on a major web server, then that does make it very easy for apps to hide their DNS in a way they could not easily do before. --=20 Bob Harold > > Thanks, > Tommy > ------------------------------ > *From:* Add on behalf of Stephen Farrell < > stephen.farrell@cs.tcd.ie> > *Sent:* Wednesday, November 6, 2019 6:20 AM > *To:* Daniel Migault ; > add@ietf.org > *Subject:* Re: [Add] Fwd: New Version Notification for > draft-mglt-abcd-doh-privacy-analysis-00.txt > > > Hi Daniel, > > On 05/11/2019 20:40, Daniel Migault wrote: > > Please find an analysis on DoH and privacy. The intent is to provide an > > analysis. Any feed backs are welcome! > > My feedback: > > - I don't see how this adds to the discussion. ISTM this > is yet another one-sided description of the issues. What do > you think is the added benefit of having this text in an > Internet-draft? Honestly, I don't get it. > > - In particular, I don't think your "conclusion" that "the > overall picture of concentration shows that it represents > a threat to the end user's privacy" can be justified based > on the content. I'm assuming "represents a threat" is not > just weasel-wording for "might be" which is trivially > true. If you mean anything stronger than "might be" then > that's not justified IMO and if you mean "might be" or > anything weaker, then it looks like stretching to find > a pejorative way to describe things. > > Cheers, > S. > > PS: In saying the above, I do think there are dangers in > how DoH deployments might increase centralisation. But I > also think that one-sided descriptions of those dangers > make the conversations more, and not less, difficult. > > > > > Yours, > > Daniel > > ---------- Forwarded message --------- > > From: > > Date: Mon, Nov 4, 2019 at 11:20 AM > > Subject: New Version Notification for > > draft-mglt-abcd-doh-privacy-analysis-00.txt > > To: Daniel Migault > > > > > > > > A new version of I-D, draft-mglt-abcd-doh-privacy-analysis-00.txt > > has been successfully submitted by Daniel Migault and posted to the > > IETF repository. > > > > Name: draft-mglt-abcd-doh-privacy-analysis > > Revision: 00 > > Title: A privacy analysis on DoH deployment > > Document date: 2019-11-04 > > Group: Individual Submission > > Pages: 11 > > URL: > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Finternet-drafts%2Fdraft-mglt-abcd-doh-privacy-analysis-00.txt&= ;data=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d76= 2c47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&= ;sdata=3Dw7GwUhz%2BIVSB5VW%2BtyEKvAUjTTh%2BNhq12tpVbM5Zw0o%3D&reserved= =3D0 > > Status: > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-mglt-abcd-doh-privacy-analysis%2F&data=3D= 02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%= 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&sdata= =3DXmWL4PabqWROpOd1YmGsKfQ9ucjP16tanC5PnTuewAw%3D&reserved=3D0 > > Htmlized: > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis-00&data=3D02%7C= 01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%7C72f= 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&sdata=3DtpXD= CA5qibyJU0%2FBcvkCHxRoKhWTZYi9s4fln0MQLx8%3D&reserved=3D0 > > Htmlized: > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis&dat= a=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47= bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&sda= ta=3Dl4GflUzS14Z68kdSWxLzCjIYKoHWtY%2BwxFxCO5FY%2FEY%3D&reserved=3D0 > > > > > > Abstract: > > This document provides an analysis on DoH impact on privacy > > > > > > > > > > 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 > > > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000a956cd0596b2a6ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

<= /div>
On Wed, Nov 6, 2019 at 2:10 PM Tommy Jensen <Jensen.Thomas= =3D40microsoft.com@dmarc.= ietf.org> wrote:
Hey Daniel,

Adding onto Stephen's comments (+1 to not sure what the goal of this do= cument is), I'll point out a reoccurrence of the common but false assum= ption that DoH always means browsers and always means centralization:

draft>>=C2=A0DoH changes this paradigm in the way that an application= can circumvent the policy set by the end user, without the end user being = aware of it.=C2=A0 Firstly, the encryption is performed by the application = and as such does not provide any visibility to the operating system.

DoH doesn't change this paradigm at all, as it isn't a protocol jus= t for apps (see the Adaptive DNS proposal for an example of a platform prov= iding DoH). This problem (apps doing their own DNS and circumventing system= configured policy) existed before and continues to exist with classic DNS; it just so happened that the traffic was plain = text so any network sniffing software could observe and possibly modify or = block it. I consider that an unfortunate side effect of plain text protocol= s, not a feature we should be working to preserve. It's not like apps doing their own DNS queries today are = visible to most users today, who don't know what packet inspection is.<= /div>

I think if we drive widespread adoption of encrypted DNS protocols by platf= orms and ISPs, we'll have better luck convincing well-behaved applicati= ons to defer to platform configurations than any other approach. After all,= why build per-app experiences if the platform experience is already "good" in the eyes of the privacy= conscious? This will address the concern of centralization of the DNS as w= ell (which is not an inherent DoH problem, but an inherent "default pr= ovider for all customers of X app/platform" problem).

As far as ill-behaved applications go, they were going to do whatever they = wanted anyway, and pushing DoH adoption doesn't give them powers they d= idn't already have. At some point, the problem becomes one of the user = needing to decide what apps they trust which we cannot help with via protocol design.

=
I agree with most of your points - but here you say "pushin= g DoH adoption doesn't give them powers they didn't already have&qu= ot;.=C2=A0 One concern is IF some major web service enables DoH on a major = web server, then that does make it very easy for apps to hide their DNS in = a way they could not easily do before.

--=C2=A0
Bob Harold
=C2=A0

Thanks,
Tommy
From= : Add <add= -bounces@ietf.org> on behalf of Stephen Farrell <stephen.farrell@cs.tcd.ie>
Sent: Wednesday, November 6, 2019 6:20 AM
To: Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.org>= ;; add@ietf.org <<= a href=3D"mailto:add@ietf.org" target=3D"_blank">add@ietf.org>
Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd= -doh-privacy-analysis-00.txt
=C2=A0

Hi Daniel,

On 05/11/2019 20:40, Daniel Migault wrote:
> Please find an analysis on DoH and privacy. The intent is to provide a= n
> analysis. Any feed backs are welcome!

My feedback:

- I don't see how this adds to the discussion. ISTM this
is yet another one-sided description of the issues. What do
you think is the added benefit of having this text in an
Internet-draft? Honestly, I don't get it.

- In particular, I don't think your "conclusion" that "t= he
overall picture of concentration shows that it represents
a threat to the end user's privacy" can be justified based
on the content. I'm assuming "represents a threat" is not
just weasel-wording for "might be" which is trivially
true. If you mean anything stronger than "might be" then
that's not justified IMO and if you mean "might be" or
anything weaker, then it looks like stretching to find
a pejorative way to describe things.

Cheers,
S.

PS: In saying the above, I do think there are dangers in
how DoH deployments might increase centralisation. But I
also think that one-sided descriptions of those dangers
make the conversations more, and not less, difficult.

>
> Yours,
> Daniel
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Mon, Nov 4, 2019 at 11:20 AM
> Subject: New Version Notification for
> draft-mglt-abcd-doh-privacy-analysis-00.txt
> To: Daniel Migault <mglt.ietf@gmail.com>
>
>
>
> A new version of I-D, draft-mglt-abcd-doh-privacy-analysis-00.txt
> has been successfully submitted by Daniel Migault and posted to the > IETF repository.
>
> Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draf= t-mglt-abcd-doh-privacy-analysis
> Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00
> Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A privacy= analysis on DoH deployment
> Document date:=C2=A0 2019-11-04
> Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Individua= l Submission
> Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 11
> URL:
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Finternet-drafts%2Fdraft-mglt-abcd-doh-privacy-analysis-00.txt&a= mp;data=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d= 762c47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&a= mp;amp;sdata=3Dw7GwUhz%2BIVSB5VW%2BtyEKvAUjTTh%2BNhq12tpVbM5Zw0o%3D&amp= ;reserved=3D0
> Status:
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-mglt-abcd-doh-privacy-analysis%2F&amp;data= =3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47b= cc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&amp;= sdata=3DXmWL4PabqWROpOd1YmGsKfQ9ucjP16tanC5PnTuewAw%3D&amp;reserved=3D0=
> Htmlized:
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis-00&amp;data=3D02%= 7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%7C7= 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&amp;sdata= =3DtpXDCA5qibyJU0%2FBcvkCHxRoKhWTZYi9s4fln0MQLx8%3D&amp;reserved=3D0
> Htmlized:
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis&amp;d= ata=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c= 47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&a= mp;sdata=3Dl4GflUzS14Z68kdSWxLzCjIYKoHWtY%2BwxFxCO5FY%2FEY%3D&amp;reser= ved=3D0
>
>
> Abstract:
>=C2=A0=C2=A0=C2=A0 This document provides an analysis on DoH impact on = privacy
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000a956cd0596b2a6ae-- From nobody Wed Nov 6 12:51:00 2019 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 8466C1200A4 for ; Wed, 6 Nov 2019 12:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, 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=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 nNOp4iGZ5wGJ for ; Wed, 6 Nov 2019 12:50:58 -0800 (PST) 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 DF06A12010E for ; Wed, 6 Nov 2019 12:50:57 -0800 (PST) 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)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id D9E6B6A234; Wed, 6 Nov 2019 21:50:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1573073455; bh=B6KpOtH0OOVd07VMdVGQf6mGNUk02j1W8uoAEwsBtPA=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=wGXCa0hVmKhWptgfrMQGvxm9VC/f42uzFin6SReduvvWAuP4N85I1Pp28i607qdGq 35vBLcbmBWOUg3x+ZFIRH3/hgpVWt5Hbzo4xB044thWPJ2CiKCH7dJ4JVxMUxmUmSf egmgqxFFcpx6i4IT1g26UKGZRM6bgVGgWwQDPEfgoYpKdFnBAeE4fTbNjPPc5ysks5 Mt4uLQlMUPIFlaMgYp8z5MGfL/FMVw9r6xy4P2E3Y9XNGILvPrL0IDMAqDbl+6+ujG C3DeWtc9dEN11RK7jRiX/TJjIDCNJFX66u0LUxBL2DmNqAInc8uoXM5MltWnLCRqCQ d3CGmYgsmwYCg== 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 C4CAF3C0101; Wed, 6 Nov 2019 21:50:55 +0100 (CET) Date: Wed, 6 Nov 2019 21:50:55 +0100 (CET) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Bob Harold Cc: Daniel Migault , "add@ietf.org" Message-ID: <1030648680.29401.1573073455702@appsuite-gw1.open-xchange.com> In-Reply-To: References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev15 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] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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, 06 Nov 2019 20:51:00 -0000

Il 6 novembre 2019 20:35 Bob Harold <rharolde@umich.edu> ha scritto:



On Wed, Nov 6, 2019 at 2:10 PM Tommy Jensen <Jensen.Thomas= 40microsoft.com@dmarc.ietf.org> wrote:
As far as ill-behaved applications go, they were going to do whatever they wanted anyway, and pushing DoH adoption doesn't give them powers they didn't already have. At some point, the problem becomes one of the user needing to decide what apps they trust which we cannot help with via protocol design.

I agree with most of your points - but here you say "pushing DoH adoption doesn't give them powers they didn't already have".  One concern is IF some major web service enables DoH on a major web server, then that does make it very easy for apps to hide their DNS in a way they could not easily do before.
More generally, applications could already do their own DNS-over-whatever-type-of-encryption-and-obfuscation-protocol, but they would have to develop it on their own and also develop and run the related server. After standardizing DoH and getting it widely adopted, applications that want to reach that objective just need to deploy a readily available Web client library and use any of the many public servers - something that any script kiddie can do.

Note that this is less true of DoT, since DoT towards out-of-perimeter servers would more easily be detectable and blockable. This is why I have heard some cybersecurity people suggest that the industry should promote DoT rather than DoH, as they see it less likely that DoT will circumvent national cybersecurity practices and law enforcement mechanisms.

Regarding Daniel's draft, I appreciate the effort and I partly tried to do this and other analyses in my draft for Prague, but I then realized that there are people here that will never consent to such a document becoming an agreed standard, even if informational. So I suggest that we should focus on a few technical developments for interoperability purposes that we can agree upon, such as standardized ways for the local network to advertise their own Do* service and their use of it for local policy enforcement, and give up discussions on deployment models and human rights assessments. I don't think we could ever get to agreement here on whether DoH brings more privacy and freedom or less of it, as the answer is really "it depends".

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
From nobody Wed Nov 6 13:25:53 2019 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 93A8A120120 for ; Wed, 6 Nov 2019 13:25:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ddfi5tI707OC for ; Wed, 6 Nov 2019 13:25:49 -0800 (PST) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (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 7B86F120047 for ; Wed, 6 Nov 2019 13:25:49 -0800 (PST) Received: by mail-vs1-f47.google.com with SMTP id j85so16988611vsd.11 for ; Wed, 06 Nov 2019 13:25:49 -0800 (PST) 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=Wds4NtZx6kdvk1eAjPFmVTig5/It+TLucBGgZjHz2TA=; b=j30vsXg5UxQlZd2LVaFDJxUudjGt+TbqDS5R6s59ehqcHVlZq/Y82Y3IfguqtSvQPq boVsm/rUhi+9Gqv4RdN7WtKO95dKA08PH/tD6kE7Vt75+PBPAOd7Q6Fu7Xvhv0r04ssy 4ezvKoAJUCvYQStkpiBGrSAAeWY0iMSD5xHpYlIIXosPjVf8KhUlkD35eMkoIgFUCD8f p3GJ42JUuTvI1tw/yGStEldFYKBf6TZ2yjARpFKVG2tDg22dLXtFntSg8Y3AdRYpyAs0 MCe6sAFsdbbIcQl7ErA3ZD+HSUlmuXiQA/rso8YnGWsbRifgOjQKMZZ5UQ/d/K/uu+5l GzaA== X-Gm-Message-State: APjAAAVfGoKt5otLuN9iOZJWw3kTUCDknDRNwhoTJFd1D0Qf3xXjMtqu CWbqzr+qDVKIAx1hlCWjwQx9971IzdSUQWJlkNiGgoIzr9U= X-Google-Smtp-Source: APXvYqxgTH65dsisvuNNAc5gSwz5yE1x6yiR/owEREK6JRgFwnhUdOK8NEkOSWcXQxhaeA3KEdoIqg6HRyA77ebPbkA= X-Received: by 2002:a67:685:: with SMTP id 127mr23789vsg.169.1573075548377; Wed, 06 Nov 2019 13:25:48 -0800 (PST) MIME-Version: 1.0 References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> In-Reply-To: <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> From: Daniel Migault Date: Wed, 6 Nov 2019 16:25:37 -0500 Message-ID: To: Stephen Farrell Cc: Daniel Migault , add@ietf.org Content-Type: multipart/alternative; boundary="0000000000004415450596b4315d" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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, 06 Nov 2019 21:25:52 -0000 --0000000000004415450596b4315d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Stephen, Thank you for the feed back and taking the time to read the draft. To answer to your question, the purpose of this draft is to provide an analysis of the privacy impact of the deployment of DoH. In that sense it addresses two of your concerns -- "this is yet another one-sided description of the issues."--, that is: * 1) clarification of (potential) issues - and the context in which there may be issues. * 2) misleading communications It seems, at least to me, two valid reasons for having the analysis as an internet draft. Regarding your comment, as the author whose english is not his native language, I can guarantee there is no intention of carrying a pejorative meaning nor that the document being one sided. For instance, the term "threat" was used as in a similar way as in RFC6973 [1]. """ Although recipients, intermediaries, and enablers may not generally be considered as attackers, they may all pose privacy threats (depending on the context) because they are able to observe, collect, process, and transfer privacy-relevant data. """ The cambridge dictionnary [2] provides for threat "A threat of rain is in today=E2=80=99s forecast." and I do not see any intention of being pejorati= ve as well. Comments regarding the content of the draft are more than welcome as usual! Yours, Daniel [1] https://tools.ietf.org/html/rfc6973#section-5.1.1 [2] https://dictionary.cambridge.org/dictionary/english/threat?q=3Dthreat+ On Wed, Nov 6, 2019 at 9:20 AM Stephen Farrell wrote: > > Hi Daniel, > > On 05/11/2019 20:40, Daniel Migault wrote: > > Please find an analysis on DoH and privacy. The intent is to provide an > > analysis. Any feed backs are welcome! > > My feedback: > > - I don't see how this adds to the discussion. ISTM this > is yet another one-sided description of the issues. What do > you think is the added benefit of having this text in an > Internet-draft? Honestly, I don't get it. > > - In particular, I don't think your "conclusion" that "the > overall picture of concentration shows that it represents > a threat to the end user's privacy" can be justified based > on the content. I'm assuming "represents a threat" is not > just weasel-wording for "might be" which is trivially > true. If you mean anything stronger than "might be" then > that's not justified IMO and if you mean "might be" or > anything weaker, then it looks like stretching to find > a pejorative way to describe things. > > Cheers, > S. > > PS: In saying the above, I do think there are dangers in > how DoH deployments might increase centralisation. But I > also think that one-sided descriptions of those dangers > make the conversations more, and not less, difficult. > > > > > Yours, > > Daniel > > ---------- Forwarded message --------- > > From: > > Date: Mon, Nov 4, 2019 at 11:20 AM > > Subject: New Version Notification for > > draft-mglt-abcd-doh-privacy-analysis-00.txt > > To: Daniel Migault > > > > > > > > A new version of I-D, draft-mglt-abcd-doh-privacy-analysis-00.txt > > has been successfully submitted by Daniel Migault and posted to the > > IETF repository. > > > > Name: draft-mglt-abcd-doh-privacy-analysis > > Revision: 00 > > Title: A privacy analysis on DoH deployment > > Document date: 2019-11-04 > > Group: Individual Submission > > Pages: 11 > > URL: > > > https://www.ietf.org/internet-drafts/draft-mglt-abcd-doh-privacy-analysis= -00.txt > > Status: > > https://datatracker.ietf.org/doc/draft-mglt-abcd-doh-privacy-analysis/ > > Htmlized: > > https://tools.ietf.org/html/draft-mglt-abcd-doh-privacy-analysis-00 > > Htmlized: > > > https://datatracker.ietf.org/doc/html/draft-mglt-abcd-doh-privacy-analysi= s > > > > > > Abstract: > > This document provides an analysis on DoH impact on privacy > > > > > > > > > > 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 > > > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000004415450596b4315d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stephen,

Thank you for the feed back and taking = the time to read the draft.

To answer to your question, the purpose= of this draft is to provide an analysis of the privacy impact of the deplo= yment of DoH. In that sense it addresses two of your concerns -- "this is yet an= other one-sided description of the issues."--, that is:
* 1) clari= fication of (potential) issues - and the context in which there may be issu= es. =C2=A0
* 2) misleading communications

It seems, at least to m= e, two valid reasons for having the analysis as an internet draft.

Regarding = your comment, as the author whose english is not his native language, I can guarant= ee there is no intention of carrying a pejorative meaning nor that the docu= ment being one sided. For instance, the term "threat" was used as= in a similar way as in RFC6973 [1].

"""
=C2=A0 = =C2=A0Although recipients, intermediaries, and enablers may not generally=C2=A0 =C2=A0be considered as attackers, they may all pose privacy threat= s
=C2=A0 =C2=A0(depending on the context) because they are able to obser= ve, collect,
=C2=A0 =C2=A0process, and transfer privacy-relevant data. <= br>"""
The cambridge dictionnary [2] provides for threat "A threat of ra= in is in today=E2=80=99s forecast." and I do not see any intention of = being pejorative as well.

Comments regarding the content of the dra= ft are more than welcome as usual!

Yours,
Daniel


[1] = https://tools.ietf.org/html/rfc6973#section-5.1.1
[2= ] https://dictionary.cambridge.org/dictionary/english/threat= ?q=3Dthreat+


On Wed, Nov 6, 2019 at 9:20 AM Stephen Farrell <stephen.farrell@cs.tcd.ie> = wrote:

Hi Daniel,

On 05/11/2019 20:40, Daniel Migault wrote:
> Please find an analysis on DoH and privacy. The intent is to provide a= n
> analysis. Any feed backs are welcome!

My feedback:

- I don't see how this adds to the discussion. ISTM this
is yet another one-sided description of the issues. What do
you think is the added benefit of having this text in an
Internet-draft? Honestly, I don't get it.

- In particular, I don't think your "conclusion" that "t= he
overall picture of concentration shows that it represents
a threat to the end user's privacy" can be justified based
on the content. I'm assuming "represents a threat" is not
just weasel-wording for "might be" which is trivially
true. If you mean anything stronger than "might be" then
that's not justified IMO and if you mean "might be" or
anything weaker, then it looks like stretching to find
a pejorative way to describe things.

Cheers,
S.

PS: In saying the above, I do think there are dangers in
how DoH deployments might increase centralisation. But I
also think that one-sided descriptions of those dangers
make the conversations more, and not less, difficult.

>
> Yours,
> Daniel
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Mon, Nov 4, 2019 at 11:20 AM
> Subject: New Version Notification for
> draft-mglt-abcd-doh-privacy-analysis-00.txt
> To: Daniel Migault <mglt.ietf@gmail.com>
>
>
>
> A new version of I-D, draft-mglt-abcd-doh-privacy-analysis-00.txt
> has been successfully submitted by Daniel Migault and posted to the > IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-mglt-abcd-doh-priv= acy-analysis
> Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 A privacy analysis on DoH dep= loyment
> Document date:=C2=A0 2019-11-04
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 11
> URL:
> https://www.iet= f.org/internet-drafts/draft-mglt-abcd-doh-privacy-analysis-00.txt
> Status:
> https://datatracker.ietf.= org/doc/draft-mglt-abcd-doh-privacy-analysis/
> Htmlized:
> https://tools.ietf.org/html/= draft-mglt-abcd-doh-privacy-analysis-00
> Htmlized:
> https://datatracker.i= etf.org/doc/html/draft-mglt-abcd-doh-privacy-analysis
>
>
> Abstract:
>=C2=A0 =C2=A0 This document provides an analysis on DoH impact on priva= cy
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>
>
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000004415450596b4315d-- From nobody Wed Nov 6 13:38:30 2019 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 36314120124 for ; Wed, 6 Nov 2019 13:38:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.467 X-Spam-Level: X-Spam-Status: No, score=-1.467 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeW7V9AmCMAw for ; Wed, 6 Nov 2019 13:38:26 -0800 (PST) Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (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 7A2561200FF for ; Wed, 6 Nov 2019 13:38:26 -0800 (PST) Received: by mail-vs1-f47.google.com with SMTP id 190so12526623vss.8 for ; Wed, 06 Nov 2019 13:38:26 -0800 (PST) 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=B6Y/KsCHRgdcy/T41x0sY8uymtCwNUQhude++miuyIg=; b=T3CMLjVzkOL0QDFE+9w++Ta018vd9A+xWcEGlLHisRJcAWCttBlL6hHBYXyMAzm/wI 3VyWc7rFl20m9/PXdcU3a+EfU8o8xhrzvxbIMsVLf6aIUTtNInof9RRnhAWQrUd839yv SVpXQD3yTgpXqfjFtKt84iFpPpT1uuO4/ZTMSBabSiLP1kq/GBD3Uct/pQnBPRwblkFE Sl7VFaWW8RQtNwMnO0n0dCYsuqVw++Zx5nHzX3Lc5jyju8+4CuJ816qfR3rLuORwwsCO ef2Im8Y9qid/Vdu86ozkVhcJhVF5pcFKA+oXLySXch2847CBP4zLme12oi5psxYpTYMm FaGQ== X-Gm-Message-State: APjAAAUBbcVDk42ObFJySBADtsxL/JW8aYetj+HHkCkDK4KkxGyV3LFy n8w59v/uFy3iKH8p7GUK8fc6XjJXdfvBol3myRI= X-Google-Smtp-Source: APXvYqxgZ6tdn3h3SuMq5K2qUIg7pjt2roLV9PZ6fPhkoY2YBu/M8TKSu8JSDZlQgveVw5ToGy0sJtKqhMC5HIckPaQ= X-Received: by 2002:a67:7a8d:: with SMTP id v135mr79291vsc.97.1573076305461; Wed, 06 Nov 2019 13:38:25 -0800 (PST) MIME-Version: 1.0 References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> In-Reply-To: From: Daniel Migault Date: Wed, 6 Nov 2019 16:38:14 -0500 Message-ID: To: Tommy Jensen Cc: Stephen Farrell , Daniel Migault , "add@ietf.org" Content-Type: multipart/alternative; boundary="0000000000006444fb0596b45edc" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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, 06 Nov 2019 21:38:29 -0000 --0000000000006444fb0596b45edc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Tommy, Thanks for the comment. Please see my response to Stephan for the goal of the document. I do not think the document states that DoH always means centralization. Second I do not see that the document points at web browser especially. The term "browser" is never mentioned - which suprises me as well - , the reason is that "DNS client" and "DNS resolver" were used to avoid this exact confusion. This remains true that the DNS client is inside the browser or not and in both case this is an application. I think what you are saying is that your OS DNS Client could use DoH as well. If so yes, I agree and the document does not try to say otherwise. This centralized OS resolver application is also where the system DNS policy is enforced. I think the draft details clearly that this may or may not represent the end user's DNS policy and in which cases the end user's policy is enforced. The ability to let the end user enforce his policy is a primary concern regarding privacy and doing otherwise represents a threat to privacy. That applications could already exfiltrate traffic and will do with or without DoH. These application were even trusted applications or malwares, not common applications. DoH provides the infrastructure for both of them. As always comments are welcome! Yours, Daniel On Wed, Nov 6, 2019 at 2:10 PM Tommy Jensen wrote: > Hey Daniel, > > Adding onto Stephen's comments (+1 to not sure what the goal of this > document is), I'll point out a reoccurrence of the common but false > assumption that DoH always means browsers and always means centralization= : > > draft>> DoH changes this paradigm in the way that an application can > circumvent the policy set by the end user, without the end user being awa= re > of it. Firstly, the encryption is performed by the application and as su= ch > does not provide any visibility to the operating system. > > DoH doesn't change this paradigm at all, as it isn't a protocol just for > apps (see the Adaptive DNS proposal for an example of a platform providin= g > DoH). This problem (apps doing their own DNS and circumventing system > configured policy) existed before and continues to exist with classic DNS= ; > it just so happened that the traffic was plain text so any network sniffi= ng > software could observe and possibly modify or block it. I consider that a= n > unfortunate side effect of plain text protocols, not a feature we should = be > working to preserve. It's not like apps doing their own DNS queries today > are visible to most users today, who don't know what packet inspection is= . > > I think if we drive widespread adoption of encrypted DNS protocols by > platforms and ISPs, we'll have better luck convincing well-behaved > applications to defer to platform configurations than any other approach. > After all, why build per-app experiences if the platform experience is > already "good" in the eyes of the privacy conscious? This will address th= e > concern of centralization of the DNS as well (which is not an inherent Do= H > problem, but an inherent "default provider for all customers of X > app/platform" problem). > > As far as ill-behaved applications go, they were going to do whatever the= y > wanted anyway, and pushing DoH adoption doesn't give them powers they > didn't already have. At some point, the problem becomes one of the user > needing to decide what apps they trust which we cannot help with via > protocol design. > > Thanks, > Tommy > ------------------------------ > *From:* Add on behalf of Stephen Farrell < > stephen.farrell@cs.tcd.ie> > *Sent:* Wednesday, November 6, 2019 6:20 AM > *To:* Daniel Migault ; > add@ietf.org > *Subject:* Re: [Add] Fwd: New Version Notification for > draft-mglt-abcd-doh-privacy-analysis-00.txt > > > Hi Daniel, > > On 05/11/2019 20:40, Daniel Migault wrote: > > Please find an analysis on DoH and privacy. The intent is to provide an > > analysis. Any feed backs are welcome! > > My feedback: > > - I don't see how this adds to the discussion. ISTM this > is yet another one-sided description of the issues. What do > you think is the added benefit of having this text in an > Internet-draft? Honestly, I don't get it. > > - In particular, I don't think your "conclusion" that "the > overall picture of concentration shows that it represents > a threat to the end user's privacy" can be justified based > on the content. I'm assuming "represents a threat" is not > just weasel-wording for "might be" which is trivially > true. If you mean anything stronger than "might be" then > that's not justified IMO and if you mean "might be" or > anything weaker, then it looks like stretching to find > a pejorative way to describe things. > > Cheers, > S. > > PS: In saying the above, I do think there are dangers in > how DoH deployments might increase centralisation. But I > also think that one-sided descriptions of those dangers > make the conversations more, and not less, difficult. > > > > > Yours, > > Daniel > > ---------- Forwarded message --------- > > From: > > Date: Mon, Nov 4, 2019 at 11:20 AM > > Subject: New Version Notification for > > draft-mglt-abcd-doh-privacy-analysis-00.txt > > To: Daniel Migault > > > > > > > > A new version of I-D, draft-mglt-abcd-doh-privacy-analysis-00.txt > > has been successfully submitted by Daniel Migault and posted to the > > IETF repository. > > > > Name: draft-mglt-abcd-doh-privacy-analysis > > Revision: 00 > > Title: A privacy analysis on DoH deployment > > Document date: 2019-11-04 > > Group: Individual Submission > > Pages: 11 > > URL: > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.i= etf.org%2Finternet-drafts%2Fdraft-mglt-abcd-doh-privacy-analysis-00.txt&= ;data=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d76= 2c47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&= ;sdata=3Dw7GwUhz%2BIVSB5VW%2BtyEKvAUjTTh%2BNhq12tpVbM5Zw0o%3D&reserved= =3D0 > > Status: > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fdraft-mglt-abcd-doh-privacy-analysis%2F&data=3D= 02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%= 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&sdata= =3DXmWL4PabqWROpOd1YmGsKfQ9ucjP16tanC5PnTuewAw%3D&reserved=3D0 > > Htmlized: > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools= .ietf.org%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis-00&data=3D02%7C= 01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%7C72f= 988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&sdata=3DtpXD= CA5qibyJU0%2FBcvkCHxRoKhWTZYi9s4fln0MQLx8%3D&reserved=3D0 > > Htmlized: > > > https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatat= racker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis&dat= a=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47= bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&sda= ta=3Dl4GflUzS14Z68kdSWxLzCjIYKoHWtY%2BwxFxCO5FY%2FEY%3D&reserved=3D0 > > > > > > Abstract: > > This document provides an analysis on DoH impact on privacy > > > > > > > > > > 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 > > > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000006444fb0596b45edc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tommy,

Thanks for the comment. Please see my re= sponse to Stephan for the goal of the document.

I do not think the = document states that DoH always means centralization. Second I do not see that the = document points at web browser especially. The term "browser" is = never mentioned - which suprises me as well - , the reason is that=C2=A0 &q= uot;DNS cl= ient" and "DNS resolver" were used to avoid this exact confusion. Th= is remains true that the DNS client is inside the browser or not and in both case thi= s is an application. I think what you are saying is that your OS DNS Client could use= DoH as we= ll. If so yes, I agree and the document does not try to say otherwise.
=
This centralized OS resolver application is also where the system DNS policy is e= nforced. I think the draft details clearly that this may or may not represe= nt the end user's DNS policy and in which cases the end user's policy is enf= orced. The ability to let the end user enforce his policy is a primary conc= ern regarding privacy and doing otherwise represents a threat to privacy. = =C2=A0

That applications could already exfiltrate traffic and will do with or= without=C2=A0Do= H. These application were even trusted applications or malwares, not common= applications. DoH provides the infrastructure for both of them.=C2=A0=C2= =A0

As always comments are welcome!

Yours,
Da= niel

On Wed, Nov 6, 2019 at 2:10 PM Tommy Jensen <Jensen.Thom= as=3D40microsoft.com@dmar= c.ietf.org> wrote:
Hey Daniel,

Adding onto Stephen's comments (+1 to not sure what the goal of this do= cument is), I'll point out a reoccurrence of the common but false assum= ption that DoH always means browsers and always means centralization:

draft>>=C2=A0DoH changes this paradigm in the way that an application= can circumvent the policy set by the end user, without the end user being = aware of it.=C2=A0 Firstly, the encryption is performed by the application = and as such does not provide any visibility to the operating system.

DoH doesn't change this paradigm at all, as it isn't a protocol jus= t for apps (see the Adaptive DNS proposal for an example of a platform prov= iding DoH). This problem (apps doing their own DNS and circumventing system= configured policy) existed before and continues to exist with classic DNS; it just so happened that the traffic was plain = text so any network sniffing software could observe and possibly modify or = block it. I consider that an unfortunate side effect of plain text protocol= s, not a feature we should be working to preserve. It's not like apps doing their own DNS queries today are = visible to most users today, who don't know what packet inspection is.<= /div>

I think if we drive widespread adoption of encrypted DNS protocols by platf= orms and ISPs, we'll have better luck convincing well-behaved applicati= ons to defer to platform configurations than any other approach. After all,= why build per-app experiences if the platform experience is already "good" in the eyes of the privacy= conscious? This will address the concern of centralization of the DNS as w= ell (which is not an inherent DoH problem, but an inherent "default pr= ovider for all customers of X app/platform" problem).

As far as ill-behaved applications go, they were going to do whatever they = wanted anyway, and pushing DoH adoption doesn't give them powers they d= idn't already have. At some point, the problem becomes one of the user = needing to decide what apps they trust which we cannot help with via protocol design.

Thanks,
Tommy
From= : Add <add= -bounces@ietf.org> on behalf of Stephen Farrell <stephen.farrell@cs.tcd.ie>
Sent: Wednesday, November 6, 2019 6:20 AM
To: Daniel Migault <daniel.migault=3D40ericsson.com@dmarc.ietf.org>= ;; add@ietf.org <<= a href=3D"mailto:add@ietf.org" target=3D"_blank">add@ietf.org>
Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd= -doh-privacy-analysis-00.txt
=C2=A0

Hi Daniel,

On 05/11/2019 20:40, Daniel Migault wrote:
> Please find an analysis on DoH and privacy. The intent is to provide a= n
> analysis. Any feed backs are welcome!

My feedback:

- I don't see how this adds to the discussion. ISTM this
is yet another one-sided description of the issues. What do
you think is the added benefit of having this text in an
Internet-draft? Honestly, I don't get it.

- In particular, I don't think your "conclusion" that "t= he
overall picture of concentration shows that it represents
a threat to the end user's privacy" can be justified based
on the content. I'm assuming "represents a threat" is not
just weasel-wording for "might be" which is trivially
true. If you mean anything stronger than "might be" then
that's not justified IMO and if you mean "might be" or
anything weaker, then it looks like stretching to find
a pejorative way to describe things.

Cheers,
S.

PS: In saying the above, I do think there are dangers in
how DoH deployments might increase centralisation. But I
also think that one-sided descriptions of those dangers
make the conversations more, and not less, difficult.

>
> Yours,
> Daniel
> ---------- Forwarded message ---------
> From: <internet-drafts@ietf.org>
> Date: Mon, Nov 4, 2019 at 11:20 AM
> Subject: New Version Notification for
> draft-mglt-abcd-doh-privacy-analysis-00.txt
> To: Daniel Migault <mglt.ietf@gmail.com>
>
>
>
> A new version of I-D, draft-mglt-abcd-doh-privacy-analysis-00.txt
> has been successfully submitted by Daniel Migault and posted to the > IETF repository.
>
> Name:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 draf= t-mglt-abcd-doh-privacy-analysis
> Revision:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 00
> Title:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 A privacy= analysis on DoH deployment
> Document date:=C2=A0 2019-11-04
> Group:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Individua= l Submission
> Pages:=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 11
> URL:
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Finternet-drafts%2Fdraft-mglt-abcd-doh-privacy-analysis-00.txt&a= mp;data=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d= 762c47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&a= mp;amp;sdata=3Dw7GwUhz%2BIVSB5VW%2BtyEKvAUjTTh%2BNhq12tpVbM5Zw0o%3D&amp= ;reserved=3D0
> Status:
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fdraft-mglt-abcd-doh-privacy-analysis%2F&amp;data= =3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47b= cc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&amp;= sdata=3DXmWL4PabqWROpOd1YmGsKfQ9ucjP16tanC5PnTuewAw%3D&amp;reserved=3D0=
> Htmlized:
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Ftools.i= etf.org%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis-00&amp;data=3D02%= 7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c47bcc%7C7= 2f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&amp;sdata= =3DtpXDCA5qibyJU0%2FBcvkCHxRoKhWTZYi9s4fln0MQLx8%3D&amp;reserved=3D0
> Htmlized:
> https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fdatatra= cker.ietf.org%2Fdoc%2Fhtml%2Fdraft-mglt-abcd-doh-privacy-analysis&amp;d= ata=3D02%7C01%7CJensen.Thomas%40microsoft.com%7Ce85f2b5a2eec4a50d4de08d762c= 47bcc%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637086471402836031&a= mp;sdata=3Dl4GflUzS14Z68kdSWxLzCjIYKoHWtY%2BwxFxCO5FY%2FEY%3D&amp;reser= ved=3D0
>
>
> Abstract:
>=C2=A0=C2=A0=C2=A0 This document provides an analysis on DoH impact on = privacy
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>
>
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000006444fb0596b45edc-- From nobody Wed Nov 6 13:46:06 2019 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 AD12A120145 for ; Wed, 6 Nov 2019 13:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.567 X-Spam-Level: X-Spam-Status: No, score=-1.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LH8CrKj8F7Cm for ; Wed, 6 Nov 2019 13:46:03 -0800 (PST) Received: from mail-vs1-f49.google.com (mail-vs1-f49.google.com [209.85.217.49]) (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 E1F6512010E for ; Wed, 6 Nov 2019 13:46:02 -0800 (PST) Received: by mail-vs1-f49.google.com with SMTP id a143so17062767vsd.9 for ; Wed, 06 Nov 2019 13:46:02 -0800 (PST) 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=CFSXyIswMNlCM8wzpek6efAZ3uVv1zXnBwSeXqhOGRM=; b=q+jYegTcySyE5zizNnXGO98xiB2lgDGsRKZEgrDDujLrtiAVACPHHeO9lUO0zg7YmV FYZtrjqrlJK7BSS8XoxE1t+6TjYzBpPROiMhDjS9xMKhSIFFitj6BJcmUvYyOjxAg8Wq 46804TkkSW6rpojBYeTsW3aOkuUhg4ycOF+VGImcZYLuuOLpPa6+msZE1tuN4A6I0yVd 4QZAArO9cnMNmp3dDM040i7hR96REG5xwDybEtU3MsY3HLshFcvIeh1NjN/NlesQi8ul wzw17TPyxcH5fkxKrJl09w0IOXg/K5wDlYgwpUH3sXstNPgY0wuzWBF8EsVFVl9NXAQj piPg== X-Gm-Message-State: APjAAAV3vIOaw1vRL63gLpSaLQp/Er/F7K6U2pZXYLdh/GUhkBYl9SxR Q4Lcs3W1RFywllK2j8ro0V4llvwqArTxz1a8WUg= X-Google-Smtp-Source: APXvYqxNo6CgpB4hIe1TUHQjgVOnSI/3ZNDBMr5Sgu8XG4HjpzGDCfdR4QF3g3aaR+2Q/e3Vxsjm/TJCNaVL3ziurwI= X-Received: by 2002:a05:6102:810:: with SMTP id g16mr118642vsb.69.1573076761794; Wed, 06 Nov 2019 13:46:01 -0800 (PST) MIME-Version: 1.0 References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> <1030648680.29401.1573073455702@appsuite-gw1.open-xchange.com> In-Reply-To: <1030648680.29401.1573073455702@appsuite-gw1.open-xchange.com> From: Daniel Migault Date: Wed, 6 Nov 2019 16:45:50 -0500 Message-ID: To: Vittorio Bertola Cc: Bob Harold , "add@ietf.org" , Daniel Migault Content-Type: multipart/alternative; boundary="000000000000975ed10596b479a2" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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, 06 Nov 2019 21:46:05 -0000 --000000000000975ed10596b479a2 Content-Type: text/plain; charset="UTF-8" Hi Vittorio, I agree that it will be hard to have a general statement as DoH brings more or less privacy. As you mention "it depends". However, I believe it should documented, so the end user can understand in which context he is and what to do. Yours, Daniel On Wed, Nov 6, 2019 at 3:51 PM Vittorio Bertola wrote: > > Il 6 novembre 2019 20:35 Bob Harold ha scritto: > > > > On Wed, Nov 6, 2019 at 2:10 PM Tommy Jensen 40microsoft.com@dmarc.ietf.org> wrote: > > As far as ill-behaved applications go, they were going to do whatever they > wanted anyway, and pushing DoH adoption doesn't give them powers they > didn't already have. At some point, the problem becomes one of the user > needing to decide what apps they trust which we cannot help with via > protocol design. > > > I agree with most of your points - but here you say "pushing DoH adoption > doesn't give them powers they didn't already have". One concern is IF some > major web service enables DoH on a major web server, then that does make it > very easy for apps to hide their DNS in a way they could not easily do > before. > > More generally, applications could already do their own > DNS-over-whatever-type-of-encryption-and-obfuscation-protocol, but they > would have to develop it on their own and also develop and run the related > server. After standardizing DoH and getting it widely adopted, applications > that want to reach that objective just need to deploy a readily available > Web client library and use any of the many public servers - something that > any script kiddie can do. > > Note that this is less true of DoT, since DoT towards out-of-perimeter > servers would more easily be detectable and blockable. This is why I have > heard some cybersecurity people suggest that the industry should promote > DoT rather than DoH, as they see it less likely that DoT will circumvent > national cybersecurity practices and law enforcement mechanisms. > > Regarding Daniel's draft, I appreciate the effort and I partly tried to do > this and other analyses in my draft for Prague, but I then realized that > there are people here that will never consent to such a document becoming > an agreed standard, even if informational. So I suggest that we should > focus on a few technical developments for interoperability purposes that we > can agree upon, such as standardized ways for the local network to > advertise their own Do* service and their use of it for local policy > enforcement, and give up discussions on deployment models and human rights > assessments. I don't think we could ever get to agreement here on whether > DoH brings more privacy and freedom or less of it, as the answer is really > "it depends". > > -- > > 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 > --000000000000975ed10596b479a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Vittorio,=C2=A0

I agree that it will= be hard to have a general statement as DoH brings more or less privacy. As= you mention "it depends". However, I believe it=C2=A0should=C2= =A0documented, so the end user can understand in which context he is and wh= at to do.

Yours,=C2=A0
Daniel=C2=A0

On Wed, Nov 6, 2019 at 3:51 PM Vittorio Bertola <vittorio.bertola=3D40open-xchange.com@dmarc.= ietf.org> wrote:
=20 =20 =20

Il 6 novembre 2019 20:35 Bob Harold <rharolde@umich.edu> ha scritto:



On Wed, Nov 6, 2019 at 2:10 PM Tommy Jensen <Jensen.Thomas=3D 4= 0microsoft.com@dmarc.ietf.org> wrote:
As far as ill-behaved applications go, they were going to do whatev= er they wanted anyway, and pushing DoH adoption doesn't give them power= s they didn't already have. At some point, the problem becomes one of t= he user needing to decide what apps they trust which we cannot help with vi= a protocol design.

I agree with most of your points - but here you say "pushing DoH= adoption doesn't give them powers they didn't already have".= =C2=A0 One concern is IF some major web service enables DoH on a major web = server, then that does make it very easy for apps to hide their DNS in a wa= y they could not easily do before.
More generally, applications could already do their own DNS-over-whateve= r-type-of-encryption-and-obfuscation-protocol, but they would have to devel= op it on their own and also develop and run the related server. After stand= ardizing DoH and getting it widely adopted, applications that want to reach= that objective just need to deploy a readily available Web client library = and use any of the many public servers - something that any script kiddie c= an do.

Note that this is less true of DoT, since DoT towards out-of-perimeter s= ervers would more easily be detectable and blockable. This is why I have he= ard some cybersecurity people suggest that the industry should promote DoT = rather than DoH, as they see it less likely that DoT will circumvent nation= al cybersecurity practices and law enforcement mechanisms.

Regarding Daniel's draft, I appreciate the effort and I partly tried= to do this and other analyses in my draft for Prague, but I then realized = that there are people here that will never consent to such a document becom= ing an agreed standard, even if informational. So I suggest that we should = focus on a few technical developments for interoperability purposes that we= can agree upon, such as standardized ways for the local network to adverti= se their own Do* service and their use of it for local policy enforcement, = and give up discussions on deployment models and human rights assessments. = I don't think we could ever get to agreement here on whether DoH brings= more privacy and freedom or less of it, as the answer is really "it d= epends".

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchangevit=
torio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torin=
o, Italy
=20
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000975ed10596b479a2-- From nobody Wed Nov 6 15:37:24 2019 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 BB9401200A4 for ; Wed, 6 Nov 2019 15:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 Q9FMjRtFzaxX for ; Wed, 6 Nov 2019 15:37:21 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 9D2D8120052 for ; Wed, 6 Nov 2019 15:37:18 -0800 (PST) Received: from xse112.mail2web.com ([66.113.196.112] helo=xse.mail2web.com) by mx3.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iSUrB-0008NN-TX for add@ietf.org; Thu, 07 Nov 2019 00:37:08 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 477jXw0r0Sz6pXr for ; Wed, 6 Nov 2019 15:34:08 -0800 (PST) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iSUoS-000704-08 for add@ietf.org; Wed, 06 Nov 2019 15:34:08 -0800 Received: (qmail 8139 invoked from network); 6 Nov 2019 23:34:07 -0000 Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.58.43.152]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 6 Nov 2019 23:34:07 -0000 To: Vittorio Bertola , Bob Harold Cc: "add@ietf.org" , Daniel Migault References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> <1030648680.29401.1573073455702@appsuite-gw1.open-xchange.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <3ef66a79-3b18-8f42-b21a-653c4e19a9cc@huitema.net> Date: Wed, 6 Nov 2019 15:34:07 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: <1030648680.29401.1573073455702@appsuite-gw1.open-xchange.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.112 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.112/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.112/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0T9zDZOvA8ND4p2eQxdfzLSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDNzOpszOkW3faMySFwG163+fH zJ6mVE7ewsipSVIfs4Z/Wf+PAmZ1Y/rAnb0A1IyRgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cQQhZSeJ8jeX+/kepX1HHyIRFsicyJMEhQFtD8PLoinqRXC8R0jJlQpL+O8efQpgSip/+w zjuHtjdobcvrk7ssrdg1SRrHBwMVNLEidt64F8Z402BwMrJcZDa2ihhGrGxmgXyiGH9bdc8dtMYg LN+lK34oRmH8l+0JTL2l7MgE6xSw+lznxW4b4RTKAAkKNYOWB41mTq6pv8sGfKX7Wgabg7Mfc4Wg xT6TydOIX0aacqQGTyBVRmXoU6H7TsfBldIYFBl6VX84fRovDGikEvLuwH0r+197ykuYmDR9wbL2 DBEuqNMl4E+tMKMsv/A3u4xFRxF9LSHNsZFl22lrRRn/H0knlMgOQTVp+x1fo2EPm2HbJjFIz+wU pq20toWhA4cN5u1dXNK2RnkSbn9ilXsXLKPvWn9GxGU5BYNVd41/UAeYUOp7A73HI6oJg7w/Voeh 7DxBq1ddbO1TMfLqf5gHXNl2PZeaHdj4N+5hPjCDVF1677oPXF7r5zsW33ZNliqzwES3a0ULUNAa F84x6Jj3e34TY+s3lj/RgDQoaICKQ9Q84QG89JN6MvpNdzLqW7ocmsaGawDMjyOK4SZ06/LZHHAS JNUmoOHSoqgqxfHmWRWcrRhLeB34s3hUb32GO+1Kr28l+APxrqdcADZneb4D08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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, 06 Nov 2019 23:37:23 -0000 On 11/6/2019 12:50 PM, Vittorio Bertola wrote: > Regarding Daniel's draft, I appreciate the effort and I partly tried > to do this and other analyses in my draft for Prague, but I then > realized that there are people here that will never consent to such a > document becoming an agreed standard, even if informational. So I > suggest that we should focus on a few technical developments for > interoperability purposes that we can agree upon, such as standardized > ways for the local network to advertise their own Do* service and > their use of it for local policy enforcement, and give up discussions > on deployment models and human rights assessments. I don't think we > could ever get to agreement here on whether DoH brings more privacy > and freedom or less of it, as the answer is really "it depends".=20 Daniel's draft is certainly biased towards Daniel's opinions. For example, I don't buy his assertion that replacing the OS defaults by app decisions is always unfriendly to privacy. It is very easy to find counter-examples. But there are a couple of facts that we should acknowledge: 1) In general, the local network can retrieve the name of the server by looking at the traffic. This is obvious when the communication happens in clear text. It is also true if the traffic is encrypted using TLS versions 1.2 or lower, because the server certificate is carried in plain text. And it is still true if using TLS 1.3 but the SNI is not encrypted. 2) Because of that, in general, sending the DNS request to a third party resolver can only result in a loss of privacy. Even if the third party resolver has a virtuous approach to privacy, the fact remains that in general information that was present in just one place is now present in two, and that cannot be described as a gain. 3) But of course there are exceptions to this general rule, specifically when the traffic uses TLS 1.3 and ESNI. That's where Daniel's draft is a bit weak. It develops the arguments (1) and (2), but stops there and does not recognize the exceptions. One first exception happens when the DNS requests to the local resolver are not encrypted. This does not create a privacy leak against passive attackers, because the passive attacker that sees the DNS traffic most likely also sees the data traffic, as discussed in (1). However, encryption also protects against active attacks in which the attacker sends spoofed DNS responses. Using a third party encrypted server in this scenario is a trade-off between security and slightly worse privacy (point 2). Another exception happens when the traffic uses TLS 1.3 and ESNI. In that case, traffic analysis only reveals a communication with the fronting server, while DNS queries reveal the hidden server. Resolving the ESNI record through a trusted third party resolver will hide the hidden service name from the local network, and that is indeed a gain in privacy. It is possible to extend this privacy advantage in two ways: 1) The client could obtain the ESNI record (or equivalent HTTPSVC record) through other paths than the DNS, e.g. during prior connections with the hidden service. 2) If the client has cached the content of the ESNI record (or equivalent HTTPSVC record), it knows in advance the name of the fronting server. If the client has not also cached the address, it will get better privacy by looking up the fronting server name through the local resolver. That will prevent providing the third party service with information about timing of connections from the client. -- Christian Huitema From nobody Thu Nov 7 10:23:07 2019 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 2664612087B for ; Thu, 7 Nov 2019 10:23:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.566 X-Spam-Level: X-Spam-Status: No, score=-1.566 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.082, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DR93ZnxqvaCY for ; Thu, 7 Nov 2019 10:23:03 -0800 (PST) Received: from mail-vs1-f54.google.com (mail-vs1-f54.google.com [209.85.217.54]) (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 981321200B9 for ; Thu, 7 Nov 2019 10:23:03 -0800 (PST) Received: by mail-vs1-f54.google.com with SMTP id l5so1932953vsh.12 for ; Thu, 07 Nov 2019 10:23:03 -0800 (PST) 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=K2JRydQhcvT1EyQ8OCTdfeOZZHYB8GZjuP1lPgGMylg=; b=Myi7ByIsCqIudRBjdlfI6E/RC4WKwoq6rWgNtgXfup+uBrCxaiEaxX5WnrQUkYwxxD g3//veai9EilfRXmxTOfweN7mBTEhHKoKNk2fouj//98+k1YDhxghEyBKdmURiB3pjnA FlRcsmmbgYIC9EqQCV2kye6Z9USx6bdC3DHnMA9Ise3MRJez2IbKpC+8+WuoAaPpyVPV f4f8TvtZSaClUH2wFiCKf6isOlIA0ZvWe0bqzQW72JT7vx1xV0WPxTyHQdHob03TkNXI ucmKpN+mrArnAOae5FYDtAZa5ABVHzjtwByBOSzhZAt6Uy9mAFywTbawhmNNEZzLfAug c0mw== X-Gm-Message-State: APjAAAX3P9q6NG7M1KNvaABg2W2R4xVYP8Li5ozLVJTutdI7q67+V4Qr vEtba/yq7zBSFg0J/o9+iHgpUlNFYIO1VhBHKdLH/0CK X-Google-Smtp-Source: APXvYqwlr347Mx3tGQQvy4PBmO95A7mCQ66LQPUiUM+JS43OjbIq147uH5WM6HsIfWl4CXYJAnL7saCXQ5gdZD+ZsQU= X-Received: by 2002:a67:e2d7:: with SMTP id i23mr3692638vsm.31.1573150982601; Thu, 07 Nov 2019 10:23:02 -0800 (PST) MIME-Version: 1.0 References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> <1030648680.29401.1573073455702@appsuite-gw1.open-xchange.com> <3ef66a79-3b18-8f42-b21a-653c4e19a9cc@huitema.net> In-Reply-To: <3ef66a79-3b18-8f42-b21a-653c4e19a9cc@huitema.net> From: Daniel Migault Date: Thu, 7 Nov 2019 13:22:51 -0500 Message-ID: To: Christian Huitema Cc: Vittorio Bertola , Bob Harold , "add@ietf.org" , Daniel Migault Content-Type: multipart/alternative; boundary="0000000000007f01560596c5c173" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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: Thu, 07 Nov 2019 18:23:05 -0000 --0000000000007f01560596c5c173 Content-Type: text/plain; charset="UTF-8" Hi Christian, Thank you for taking time to review the draft. The current version of the draft does not consider active attacks. It does not either analyse how additional privacy can be leveraged from esni. These will be included in the next version. Thank you for the feed back, that is very well appreciated. Yours, Daniel On Wed, Nov 6, 2019 at 6:37 PM Christian Huitema wrote: > On 11/6/2019 12:50 PM, Vittorio Bertola wrote: > > > Regarding Daniel's draft, I appreciate the effort and I partly tried > > to do this and other analyses in my draft for Prague, but I then > > realized that there are people here that will never consent to such a > > document becoming an agreed standard, even if informational. So I > > suggest that we should focus on a few technical developments for > > interoperability purposes that we can agree upon, such as standardized > > ways for the local network to advertise their own Do* service and > > their use of it for local policy enforcement, and give up discussions > > on deployment models and human rights assessments. I don't think we > > could ever get to agreement here on whether DoH brings more privacy > > and freedom or less of it, as the answer is really "it depends". > > > Daniel's draft is certainly biased towards Daniel's opinions. For > example, I don't buy his assertion that replacing the OS defaults by app > decisions is always unfriendly to privacy. It is very easy to find > counter-examples. But there are a couple of facts that we should > acknowledge: > > 1) In general, the local network can retrieve the name of the server by > looking at the traffic. This is obvious when the communication happens > in clear text. It is also true if the traffic is encrypted using TLS > versions 1.2 or lower, because the server certificate is carried in > plain text. And it is still true if using TLS 1.3 but the SNI is not > encrypted. > > 2) Because of that, in general, sending the DNS request to a third party > resolver can only result in a loss of privacy. Even if the third party > resolver has a virtuous approach to privacy, the fact remains that in > general information that was present in just one place is now present in > two, and that cannot be described as a gain. > > 3) But of course there are exceptions to this general rule, specifically > when the traffic uses TLS 1.3 and ESNI. That's where Daniel's draft is a > bit weak. It develops the arguments (1) and (2), but stops there and > does not recognize the exceptions. > > One first exception happens when the DNS requests to the local resolver > are not encrypted. This does not create a privacy leak against passive > attackers, because the passive attacker that sees the DNS traffic most > likely also sees the data traffic, as discussed in (1). However, > encryption also protects against active attacks in which the attacker > sends spoofed DNS responses. Using a third party encrypted server in > this scenario is a trade-off between security and slightly worse privacy > (point 2). > > Another exception happens when the traffic uses TLS 1.3 and ESNI. In > that case, traffic analysis only reveals a communication with the > fronting server, while DNS queries reveal the hidden server. Resolving > the ESNI record through a trusted third party resolver will hide the > hidden service name from the local network, and that is indeed a gain in > privacy. > > It is possible to extend this privacy advantage in two ways: > > 1) The client could obtain the ESNI record (or equivalent HTTPSVC > record) through other paths than the DNS, e.g. during prior connections > with the hidden service. > > 2) If the client has cached the content of the ESNI record (or > equivalent HTTPSVC record), it knows in advance the name of the fronting > server. If the client has not also cached the address, it will get > better privacy by looking up the fronting server name through the local > resolver. That will prevent providing the third party service with > information about timing of connections from the client. > > -- Christian Huitema > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000007f01560596c5c173 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0 Christian,=C2=A0

Thank you for= taking time to review the draft. The current version of the draft=C2=A0doe= s not consider active attacks. It does not either=C2=A0analyse how addition= al privacy can be leveraged from esni. These will be included in the next v= ersion. Thank you for the feed back, that is very well appreciated.

Yours,=C2=A0
Daniel=C2=A0=C2=A0

<= /div>


On Wed, Nov 6, 2019 at 6:37 PM Christian Huitema <huitema@huitema.net> wrote:
=
On 11/6/2019 12:50 = PM, Vittorio Bertola wrote:

> Regarding Daniel's draft, I appreciate the effort and I partly tri= ed
> to do this and other analyses in my draft for Prague, but I then
> realized that there are people here that will never consent to such a<= br> > document becoming an agreed standard, even if informational. So I
> suggest that we should focus on a few technical developments for
> interoperability purposes that we can agree upon, such as standardized=
> ways for the local network to advertise their own Do* service and
> their use of it for local policy enforcement, and give up discussions<= br> > on deployment models and human rights assessments. I don't think w= e
> could ever get to agreement here on whether DoH brings more privacy > and freedom or less of it, as the answer is really "it depends&qu= ot;.


Daniel's draft is certainly biased towards Daniel's opinions. For example, I don't buy his assertion that replacing the OS defaults by ap= p
decisions is always unfriendly to privacy. It is very easy to find
counter-examples. But there are a couple of facts that we should
acknowledge:

1) In general, the local network can retrieve the name of the server by
looking at the traffic. This is obvious when the communication happens
in clear text. It is also true if the traffic is encrypted using TLS
versions 1.2 or lower, because the server certificate is carried in
plain text. And it is still true if using TLS 1.3 but the SNI is not
encrypted.

2) Because of that, in general, sending the DNS request to a third party resolver can only result in a loss of privacy. Even if the third party
resolver has a virtuous approach to privacy, the fact remains that in
general information that was present in just one place is now present in two, and that cannot be described as a gain.

3) But of course there are exceptions to this general rule, specifically when the traffic uses TLS 1.3 and ESNI. That's where Daniel's draft= is a
bit weak. It develops the arguments (1) and (2), but stops there and
does not recognize the exceptions.

One first exception happens when the DNS requests to the local resolver
are not encrypted. This does not create a privacy leak against passive
attackers, because the passive attacker that sees the DNS traffic most
likely also sees the data traffic, as discussed in (1). However,
encryption also protects against active attacks in which the attacker
sends spoofed DNS responses. Using a third party encrypted server in
this scenario is a trade-off between security and slightly worse privacy (point 2).

Another exception happens when the traffic uses TLS 1.3 and ESNI. In
that case, traffic analysis only reveals a communication with the
fronting server, while DNS queries reveal the hidden server. Resolving
the ESNI record through a trusted third party resolver will hide the
hidden service name from the local network, and that is indeed a gain in privacy.

It is possible to extend this privacy advantage in two ways:

1) The client could obtain the ESNI record (or equivalent HTTPSVC
record) through other paths than the DNS, e.g. during prior connections
with the hidden service.

2) If the client has cached the content of the ESNI record (or
equivalent HTTPSVC record), it knows in advance the name of the fronting server. If the client has not also cached the address, it will get
better privacy by looking up the fronting server name through the local
resolver. That will prevent providing the third party service with
information about timing of connections from the client.

-- Christian Huitema

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000007f01560596c5c173-- From nobody Thu Nov 7 10:47:42 2019 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 6C96A120942 for ; Thu, 7 Nov 2019 10:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 tGNQkHRFcwJS for ; Thu, 7 Nov 2019 10:47:38 -0800 (PST) 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 C0128120915 for ; Thu, 7 Nov 2019 10:47:38 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id c6so3414314ioo.13 for ; Thu, 07 Nov 2019 10:47:38 -0800 (PST) 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=FtBRTjgE1VQOSMQFvfV2+bFyVNiw41qFLNNi/Pw249U=; b=p0eXaHo/4UZrtF/I9tdkRIzaJC/2SwQg+aLDGAlalkWH8CsxGJhClUc/XuwV80HHrc VQAeTV0ALMA4Ds6CZA61hTy/PszdSNalieFLmHlvyCPYi6335QvyQOlnSr8G2jJf/dGe sgn956U0hAvPlb+0Q51vcXtB8Q4M+EdZvCV+JTDgYF8fQm7HR25NQA0qSkPVRkMyypg0 9xzVCZQx7bibe1u4VKUNUir7aizyt/8aGF2ZJogONXT0jliH5JeUzhqvMJRy58uDDU6v ylq871Dy2DIEx995tjeCUUEPTu8nsiAlX7j3gayATaDDgpec4Y4GMxUkFO9zqxr8yiT+ 6tOA== 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=FtBRTjgE1VQOSMQFvfV2+bFyVNiw41qFLNNi/Pw249U=; b=kIdgNGvTyuuRxzVrNPONEFZAnHi182WEDgHETSAYdXPCy8Vu5EK8xasgcgBsXdalyo KTqx9C1oA0uWsJksZBVgS902w3DWIMOXw6eZJJupwokqDlxEhgsrc3x1IrZ5/18XN0UX xSbzlJWcP4rsRVtewjvaZfcT0Pb2P7xhMcGqGtrcdf5XLaxIVvjWGHyDUOtWHecEUu/F Lztb7ucAyK4RTwNvaIEoCZyDq3+IwoCsLts9mmFAxrfoHaABfuNCUEXrd0ZVVzYRzyII Q4LUlGXbZMNiOVvvMnZXyhwBVWtJYvQDJVeWN+bmp+IFKQ9+KJzl04FTQGZoo7g/H2BO Vtmg== X-Gm-Message-State: APjAAAXzHDkr80YkMga0Lnff5p5VC3eEZP055HaUZaAn/r3w8R9GYiO4 7gKOZyocogYoSyx3FTKrmrP8Dlv75jqNNI0p9uA= X-Google-Smtp-Source: APXvYqxkjPTqjoiStxJpJWqDCznAS7kI1Fz2M/pyny5DtYla8zXd+D0cCmNgfqvwMfxKBpLlg4rCjMHEAU31VJvUX+c= X-Received: by 2002:a6b:c705:: with SMTP id x5mr4897639iof.189.1573152457943; Thu, 07 Nov 2019 10:47:37 -0800 (PST) MIME-Version: 1.0 References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> <1030648680.29401.1573073455702@appsuite-gw1.open-xchange.com> <3ef66a79-3b18-8f42-b21a-653c4e19a9cc@huitema.net> In-Reply-To: <3ef66a79-3b18-8f42-b21a-653c4e19a9cc@huitema.net> From: Rob Sayre Date: Thu, 7 Nov 2019 10:47:26 -0800 Message-ID: To: Christian Huitema Cc: Vittorio Bertola , Bob Harold , "add@ietf.org" , Daniel Migault Content-Type: multipart/alternative; boundary="0000000000006ef07a0596c619a4" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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: Thu, 07 Nov 2019 18:47:41 -0000 --0000000000006ef07a0596c619a4 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 6, 2019 at 3:37 PM Christian Huitema wrote: > 3) But of course there are exceptions to this general rule, specifically > when the traffic uses TLS 1.3 and ESNI. That's where Daniel's draft is a > bit weak. It develops the arguments (1) and (2), but stops there and > does not recognize the exceptions. > > One first exception happens when the DNS requests to the local resolver > ... Another exception happens when the traffic uses TLS 1.3 and ESNI. > There are other exceptions. For example, the SNI might not match the Host header in encrypted HTTP traffic. It could be something completely mismatched, or it could be a more specific subdomain of the host given in the SNI. thanks, Rob --0000000000006ef07a0596c619a4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 6, 2019 at 3:37 PM Christian = Huitema <huitema@huitema.net&= gt; wrote:
3) But of course there are exceptions to this general rule, specifically when the traffic uses TLS 1.3 and ESNI. That's where Daniel's draft= is a
bit weak. It develops the arguments (1) and (2), but stops there and
does not recognize the exceptions.

One first exception happens when the DNS requests to the local resolver
=
=C2=A0
...

Another exception happens when the traffic uses TLS 1.3 and ESNI.

There are other exceptions. For example, the SNI= might not match the Host header in encrypted HTTP traffic.

<= /div>
It could be something completely mismatched, or it could be a mor= e specific subdomain of the host given in the SNI.

thanks,
Rob
--0000000000006ef07a0596c619a4-- From nobody Thu Nov 7 11:40:02 2019 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 530011200F5 for ; Thu, 7 Nov 2019 11:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ojmh8oEfi4jX for ; Thu, 7 Nov 2019 11:39:59 -0800 (PST) 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 E555212099C for ; Thu, 7 Nov 2019 11:39:58 -0800 (PST) Received: from xse502.mail2web.com ([66.113.197.248] helo=xse.mail2web.com) by mx120.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iSndI-000gh9-QP for add@ietf.org; Thu, 07 Nov 2019 20:39:56 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 478DDC4FzHz2Db4 for ; Thu, 7 Nov 2019 11:36:27 -0800 (PST) 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 1iSnZz-0001YB-F6 for add@ietf.org; Thu, 07 Nov 2019 11:36:27 -0800 Received: (qmail 9996 invoked from network); 7 Nov 2019 19:36:27 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.58.43.113]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Nov 2019 19:36:26 -0000 To: Rob Sayre Cc: Bob Harold , Vittorio Bertola , "add@ietf.org" , Daniel Migault References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> <1030648680.29401.1573073455702@appsuite-gw1.open-xchange.com> <3ef66a79-3b18-8f42-b21a-653c4e19a9cc@huitema.net> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Thu, 7 Nov 2019 11:36:23 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------B628116703FC722863418217" Content-Language: en-US X-Originating-IP: 66.113.197.248 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/gcnlw0T9zDZOvA8ND4p2eQxdfzLSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDNzOpszOkW3faMySFwG163+fH zJ6mVE7ewsipSVIfs4bkV2YobRjWW2k7FbGJz7ZEgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+ef7heanb/rBmrs7JMJfZdi6k/ICmf4myKtZN20xbt8wI6jSvfpO+1kZkomjtjB6X5Q5Q9f RUeIpTIC2ySfqvnqLwoxlgatmaBb0rBiK9xbkDrUqzcKIief90MVLZY9LbIZh9+IQ1oS9LBn3VIP 95Jz7ujRlJ9wSMlhvaudJXZ9EIBG/qaR+8r9SKFMmPJLf850OvZYsmoVQuOIhwKLK6IKBNB4LZ0v UHHKTzJX7b1JhLSQQ4vSj0QEim26t/Moy0UPX5E73H1QfrH/5kkrV/Cr0bm2vWdo8usP65i82q1C dZgGrpL44wdx9eXqjQjbvUopOMQJvQ/Ck3iiU+4DQAj3fuQgzT3K9JUHTNiGwfwAm1iez9GB/vVI PBTzV+UYoQ474YJBS4keABKHbqTRsEiZQnC4PFuk0Sm7LdJWJwWuZvjWdoVMGao6rv4CQEmmwwbv 5pWb82qAoDl3ILGSF0vmDvI0DEihOd7XzCAIcFZdY11677oPXF7r5zsW33ZNlirOC6HI6/h+rh4v 4bH4tTkskye6uEH7Y2FUSOL4rzI+g9Q84QG89JN6MvpNdzLqW7pKqXt6nMuf90vEVJYNXf/bHHAS JNUmoOHSoqgqxfHmWRWcrRhLeB34s3hUb32GO+2Md7su8D5tk1XCFQVBYwDj08QV3No+S2msRDep v5w/kkG0v17AmegcpQ0tml/sN9lmMy/o83jVXTcfb9k0nLWblJy7uxV6dw8jzlsaNZe6hynMJcjx DydxsJEju76A7X1QIVydqXpZ6MHhiKws9Iiut28r9wo4SqUIg8Yh9hAM0n3LLzx/F2gT3wl8JQJv Bho= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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: Thu, 07 Nov 2019 19:40:00 -0000 This is a multi-part message in MIME format. --------------B628116703FC722863418217 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/7/2019 10:47 AM, Rob Sayre wrote: > On Wed, Nov 6, 2019 at 3:37 PM Christian Huitema > wrote: > > 3) But of course there are exceptions to this general rule, > specifically > when the traffic uses TLS 1.3 and ESNI. That's where Daniel's > draft is a > bit weak. It develops the arguments (1) and (2), but stops there an= d > does not recognize the exceptions. > > One first exception happens when the DNS requests to the local > resolver > > =C2=A0 > ... > > Another exception happens when the traffic uses TLS 1.3 and ESNI. > > > There are other exceptions. For example, the SNI might not match the > Host header in encrypted HTTP traffic. > > It could be something completely mismatched, or it could be a more > specific subdomain of the host given in the SNI. There may very well be other exceptions. I think that we should document them, so we can properly discuss the various trade-off. As for the HTTP Host vs SNI scenario, that's of course one possible exception. Possible, because it depends whether the DNS lookup is for the SNI or the SNI host. If the former, then it is not an exception: doing a lookup for the SNI would not reveal anything that could not be inferred from looking at the traffic. But looking for the inner host in the DNS would indeed reveal that, in the same way that looking at the ESNI does. -- Christian Huitema --------------B628116703FC722863418217 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 11/7/2019 10:47 AM, Rob Sayre wrote:

On Wed, Nov 6, 2019 at 3:37 PM Christian Huitema <huitema@huitema.net> wrote:
3) But of course there are exceptions to this general rule, specifically
when the traffic uses TLS 1.3 and ESNI. That's where Daniel's draft is a
bit weak. It develops the arguments (1) and (2), but stops there and
does not recognize the exceptions.

One first exception happens when the DNS requests to the local resolver
 
...

Another exception happens when the traffic uses TLS 1.3 and ESNI.

There are other exceptions. For example, the SNI might not match the Host header in encrypted HTTP traffic.

It could be something completely mismatched, or it could be a more specific subdomain of the host given in the SNI.

There may very well be other exceptions. I think that we should document them, so we can properly discuss the various trade-off.

As for the HTTP Host vs SNI scenario, that's of course one possible exception. Possible, because it depends whether the DNS lookup is for the SNI or the SNI host. If the former, then it is not an exception: doing a lookup for the SNI would not reveal anything that could not be inferred from looking at the traffic. But looking for the inner host in the DNS would indeed reveal that, in the same way that looking at the ESNI does.

-- Christian Huitema

--------------B628116703FC722863418217-- From nobody Thu Nov 7 15:40:18 2019 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 A50F312002F for ; Thu, 7 Nov 2019 15:40:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 TFb4bZHHKI9h for ; Thu, 7 Nov 2019 15:40:14 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 39FEF1200D7 for ; Thu, 7 Nov 2019 15:40:14 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id c6so4263474ioo.13 for ; Thu, 07 Nov 2019 15:40:14 -0800 (PST) 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=yyUxqBBzGXdP+dO0uzHc3zlOOP0x/QP35TiHjmix0ms=; b=UUXr4QUfdHCd74kUYmLPo00AS9YzIJd0sDqsPyNqedJRiNtmZV+9fjOS/5GOQdko9i /3fPdjjD8o00BrfIjHuH1bGNf9GWyBRQ5We9OGG5LxlOx8+NO9m2MX/u9ON+OfKZeH89 k9jm4HCPq09r/vI+eHsPJEHhtYfxMaYB+ZgiCXmusV4vaWuJihe61u1PRA0tAc+cepUX psXts+TomIsNtuJLd2nQYyxREb0STf7kieOitSYhpEAoIeKi4aTT3kPzmuE9prPu88DF /4XeseEHQKTvqXdE02Bq+1QiBKQ+r02bDkB7ld5fyy3EOzoEbz3WAQbOaqvEHw1Fz+Pl 9GVA== 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=yyUxqBBzGXdP+dO0uzHc3zlOOP0x/QP35TiHjmix0ms=; b=hwob6OT2fVhfnx37evne06JUdj7/AtBky+KKUHAROvk0yCWp1Kgt0YW1vjwtVmse+V G688oeuklObCXp23Wmswdg9ZCi/8uXn3Vn0JJY30Qa4XFRzoTvm09Z5kfmUvOUF7wG5t QstKvi6tilwKKeXe0UGG5t6ESlBMIlP85lBtiLK3PcQOcEBVfHy9+Q5Z6vjKUlReRszb Th6d7e/rpaaBOuaKBqMMKJGRtGHC8KpaI07FfeODw8kThTKcjwOvpRJpd/VOD/TGhL2Y +aJd0MXFtxwjQHEC1Eblotg/fBbJMyfkR8+F8KcTUzHzk1iuVDpXH9WrG4VZtEJx+SMC XCFg== X-Gm-Message-State: APjAAAXdIjwqaUqSDg4ilr0clTQbtQpiccGB4wRNWSqC9Kvkp2Oi7kf0 i7v427I+phBIr9S91Dq0au6aLCD1QboBfDHG+fE= X-Google-Smtp-Source: APXvYqwZzlBOdBPhxCVD0xFOML5YoVMj7i6bH6llCpBOffl7zUwQ4lNwJOCPy98Jiju5ZkupkToeCppcxXBp+F0c2w8= X-Received: by 2002:a5d:9297:: with SMTP id s23mr4578507iom.49.1573170013375; Thu, 07 Nov 2019 15:40:13 -0800 (PST) MIME-Version: 1.0 References: <157288444149.16545.17250458995529707952.idtracker@ietfa.amsl.com> <2f52a096-ae14-a9f8-1dbf-8931e3204ec7@cs.tcd.ie> <1030648680.29401.1573073455702@appsuite-gw1.open-xchange.com> <3ef66a79-3b18-8f42-b21a-653c4e19a9cc@huitema.net> In-Reply-To: From: Rob Sayre Date: Thu, 7 Nov 2019 15:40:01 -0800 Message-ID: To: Christian Huitema Cc: Bob Harold , Vittorio Bertola , "add@ietf.org" , Daniel Migault Content-Type: multipart/alternative; boundary="000000000000d191fd0596ca2ffe" Archived-At: Subject: Re: [Add] Fwd: New Version Notification for draft-mglt-abcd-doh-privacy-analysis-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: Thu, 07 Nov 2019 23:40:17 -0000 --000000000000d191fd0596ca2ffe Content-Type: text/plain; charset="UTF-8" On Thu, Nov 7, 2019 at 11:40 AM Christian Huitema wrote: > There may very well be other exceptions. I think that we should document > them, so we can properly discuss the various trade-off. > I agree that discussions are fine, but I disagree that this document is close to being useful. I guess I think that a somewhat useful document will get very close to documenting the security properties of TLS and HTTPS themselves, with some mention of in-progress work, like ESNI and QUIC/HTTP3. thanks, Rob --000000000000d191fd0596ca2ffe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 7, 2019 at 11:40 AM Christian= Huitema <huitema@huitema.net= > wrote:

There may very well be other exceptions. I think that we should document them, so we can properly discuss the various trade-off.

<= /div>

I agree that discussions are fine, bu= t I disagree that this document is close to being useful. I guess I think t= hat a somewhat useful document will get very close to documenting the secur= ity properties of TLS and HTTPS themselves, with some mention of in-progres= s work, like ESNI and QUIC/HTTP3.

thanks,
Rob
--000000000000d191fd0596ca2ffe-- From nobody Tue Nov 12 18:33:03 2019 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 4C8F612003F for ; Tue, 12 Nov 2019 18:33:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2vaf4K0RmAiM for ; Tue, 12 Nov 2019 18:32:59 -0800 (PST) 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 35314120019 for ; Tue, 12 Nov 2019 18:32:59 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id s5so338447iln.4 for ; Tue, 12 Nov 2019 18:32:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=jArpoAzHnnO3MM9rjlXvOlK9poxvXuWphPNEMyBQvCs=; b=ry2sua7Donf3rpoD8yX2/clCltitlH3y8MA0Cgb6zdzZ5o1x0rLEtQClEBD4j6wnRI s5ptJ1W7T7D5XCfx9XLkRU4Ct+T3ElEcA8xYspodtpOTV4ucK4hhdIrDJKX9W7gOdJzD zZO4bt9AvcGgVG0yI9zxCCtySxFpJkOYXvhF/NB0/aiO0YAzBox8ykl3XTmm8P3mvkpb /Tcimgd4VcqcVzyh7peUpQzTQOHZ4+YreNtdAfpzPAA+PVjYjxmeH8pZDslcvZgHKnRx gO+qVbUQF7XUed7qvlGwl4em1JfWJ8G/8kz1871P3TIe9I+WLgn69Sy/J0FqEBd/8l9W H9tw== 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=jArpoAzHnnO3MM9rjlXvOlK9poxvXuWphPNEMyBQvCs=; b=NgkxJz561gf1Mr3apHCJskgiZzRnnkCuFehM4jRGb11j3J7eXa8uc26+pgZz+yANpO p1mAoF38TSXPfXXFYgxILSilslqdj/1Hia0nKkFIijQjt5cKGSdRpvgx80NWe5DloVJW 6y0QT9Ad/hKK8aic5tT8HaUiVPhlcKYoO0K3NJ+fjilAmo6N4Jmk8b/atR5q8Cr1Utc5 kg3tw4GnUmZWa5ILzo4wavp9jMz56pscOE6fus0TIoANG6Q1HUF2LfVCecL44WQSkZPn BiU+mrwvBeXPb1WqDIpGCqoS0YeWZH+O1u99/ge1kVteH1vJDm8NpBOjutjvPYzKCBWx LMkQ== X-Gm-Message-State: APjAAAXkKL1bhICmG/kne4VE4UGOXnrHbIaEXLA7FxHnVZ/UdF8roI+z c4rxkPuRD2tANuF7Pjm8V+m9LwAWPl43iG3DzgJucvie X-Google-Smtp-Source: APXvYqyuNMylyIHbsBAz0gVtk/DHak1kdxf9eBGTp9hjZlZG+k9L7T6P5xJo26k10NHdec674HOP/PdOWtFPaRS17n0= X-Received: by 2002:a92:9adb:: with SMTP id c88mr1221713ill.193.1573612377837; Tue, 12 Nov 2019 18:32:57 -0800 (PST) MIME-Version: 1.0 From: Ben Schwartz Date: Tue, 12 Nov 2019 21:32:46 -0500 Message-ID: To: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d5f9d10597312e6a" Archived-At: Subject: [Add] Agenda and Revised Charter for the ABCD BoF 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, 13 Nov 2019 02:33:01 -0000 --000000000000d5f9d10597312e6a Content-Type: multipart/alternative; boundary="000000000000cbeaa90597312e33" --000000000000cbeaa90597312e33 Content-Type: text/plain; charset="UTF-8" On behalf of the ABCD BoF chairs, I am writing to confirm that the draft agenda for the ABCD BoF has now been posted, along with a revised charter proposal. Agenda: https://datatracker.ietf.org/meeting/106/materials/agenda-106-abcd Proposed charter: https://datatracker.ietf.org/meeting/106/materials/slides-106-abcd-proposed-charter-text-revised We have significantly adjusted the proposed charter text, incorporating comments and suggestions from ADD participants. Most notably, the revised text attempts to ensure that disagreements on the most contentious questions will not impede valuable standards development in less controversial areas. Please review the agenda and proposed charter, and join us next week for a full discussion. --000000000000cbeaa90597312e33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On behalf of the ABCD B= oF chairs, I am writing to confirm that the draft agenda for the ABCD BoF h= as now been posted, along with a revised charter proposal.

Agenda:=C2=A0https://datatracke= r.ietf.org/meeting/106/materials/agenda-106-abcd

We have significa= ntly adjusted the proposed charter text, incorporating comments and suggest= ions from ADD participants.=C2=A0 Most notably, the revised text attempts t= o ensure that disagreements on the most contentious questions will not impe= de valuable standards development in less controversial areas.
Please review the agenda and proposed charter, and join us nex= t week for a full discussion.
--000000000000cbeaa90597312e33-- --000000000000d5f9d10597312e6a Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCCC7k0atWt3DiZCZ9CXuGxl 5SMPPSfFwhu/9vAxjJwEuTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTExMTMwMjMyNThaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAafPCW8AwYAAMaqOzX1r/9yL+NCUPGXS5Ud8MnRu1 3O8p+EJb1Zu7LgCFPL3ztyjLvm6JZAGsRof7dh9rmRLSXMXitY4+6AR8DgEYdSW4ZA60rQ+NPLmn BGvuVYr+VTyPvI5qbSlphQJNC2es7IAlCvZxixmRtBZmDWLdL730vrY/NzkLP6/Yca+vA3bGAcXM E38beXMEv+Y5YIGgHBDbZ0r2F+ZgEjTmpcpQ0DMQgFDV1aqXBYPJnvRDZBjvsdwsO8GmHJy8Js9l ItSHVzYIj+YmowhyaLVHW8WQd6D412ZVUxOwWcXyp8TLrXLDz6X1ALwFBS1qz7zMyOBhIPpbXQ== --000000000000d5f9d10597312e6a-- From nobody Tue Nov 12 18:55:33 2019 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 B85D51201EF for ; Tue, 12 Nov 2019 18:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 3hroKeXSlI6N for ; Tue, 12 Nov 2019 18:55:29 -0800 (PST) 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 DE492120130 for ; Tue, 12 Nov 2019 18:55:28 -0800 (PST) Received: by mail-il1-x135.google.com with SMTP id s75so381400ilc.3 for ; Tue, 12 Nov 2019 18:55:28 -0800 (PST) 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=ibNIV61yZyb0CPfcXv5lPigFoXq4j8q/d7qTHS/vxus=; b=c3jYbeS/GEvEovV2E5h+GyDRXWqkWWW0n92j9W4xocfpOOFrxyK/g40lkfv4wSONVv 9SiQJXoIr6a/o+vQr8d9HFVVn7OanM0M+vOjmLKD9qCQtFRPX17qFGU53oMdtXLlYU1B YApta2VKpP4Dw2Q9L3c0hfoED3b4HQ/+wc5LkAhELOXStMOwrsFP3LNVR74QVtE4qlUS moRScLM4EMc+I3jJzJPcSPqsHaST0w0zVLJFUGgiTIfpUZY22sIqNNnntoUnFYSnHxvU gKS/4ADpGO+VkmnzMohgGNTb4IMstpDRtvefVZ3rLeL/m0wz/qiVaCy2y4jnOBzVIuKX 1Xfg== 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=ibNIV61yZyb0CPfcXv5lPigFoXq4j8q/d7qTHS/vxus=; b=NO3dtqqY4ibEozgJop68ydtlEhMFNkFD7FPp24HmzQLlzpx+p5JdioRJBaK6BJ+RWv cVOYmvbvP79yCj7ReCTpU9ELu5Cy9s9GzaeKfXksNGm1J6zjFLieEIbzHwdYeNp3d3KZ TfELQ9kC+YhHD20S7W7d+7SuVWoPn6JH7FVbU0qTe1m2kZLXuedyC/ZLmheW74V3MqIq uzFzUb9WeZfCsgkUUjuJJShXOBddopyy2t1NVcdc+SifjoFmeO0a0rQ9hXVQrL3UAV13 c76tPcoZI+AtWH9cVqjlQoFyEAPIZr9pKG5trbaZssXNNb+V72cP8Q0IZG4x74VDvVtE feDA== X-Gm-Message-State: APjAAAXzv58HP6hoG0YfEGJLh17F+ztUsPN/d9Iwm+hXIpF87uoafs0r ikJmmsWUIv+TvNKXJqsEBfKMxbSFgYnWrx9G3mok/rRP7RQ= X-Google-Smtp-Source: APXvYqxDjpckYNgl1A8riJuMZPhnZExo3p4mMCvwCQfHBjJk3zHxBIgueW/b0LX2NnBfY2EMuPsQHUZtx9a8wN3STD8= X-Received: by 2002:a92:5d49:: with SMTP id r70mr1264829ilb.257.1573613728073; Tue, 12 Nov 2019 18:55:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Tue, 12 Nov 2019 18:55:16 -0800 Message-ID: To: Ben Schwartz Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000004691fa0597317f15" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 13 Nov 2019 02:55:31 -0000 --0000000000004691fa0597317f15 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 12, 2019 at 6:33 PM Ben Schwartz wrote: > On behalf of the ABCD BoF chairs, I am writing to confirm that the draft > agenda for the ABCD BoF has now been posted, along with a revised charter > proposal. > > Agenda: https://datatracker.ietf.org/meeting/106/materials/agenda-106-abcd > Proposed charter: > https://datatracker.ietf.org/meeting/106/materials/slides-106-abcd-proposed-charter-text-revised > > We have significantly adjusted the proposed charter text, incorporating > comments and suggestions from ADD participants. Most notably, the revised > text attempts to ensure that disagreements on the most contentious > questions will not impede valuable standards development in less > controversial areas. > > Please review the agenda and proposed charter, and join us next week for a > full discussion. > I think the document you've sent seems mostly reasonable. However, I must take issue with the idea that "- End-user privacy and pervasive surveillance" is an issue that requires consensus building. It's settled in RFC 7258: Pervasive Monitoring Is an Attack https://tools.ietf.org/html/rfc7258 There hasn't been any IETF activity questioning that position. thanks, Rob --0000000000004691fa0597317f15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 12, 2019 at 6:33 PM Ben Schwa= rtz <bemasc=3D40google.co= m@dmarc.ietf.org> wrote:
On behalf of the ABCD BoF chairs, I am writing to confi= rm that the draft agenda for the ABCD BoF has now been posted, along with a= revised charter proposal.


We have significantly adjusted the proposed chart= er text, incorporating comments and suggestions from ADD participants.=C2= =A0 Most notably, the revised text attempts to ensure that disagreements on= the most contentious questions will not impede valuable standards developm= ent in less controversial areas.

Please review the= agenda and proposed charter, and join us next week for a full discussion.<= /div>

I think the documen= t you've sent seems mostly reasonable. However, I must take issue with = the idea that

"- End-user privacy and pervasi= ve surveillance"=C2=A0

is an issue that requi= res consensus building. It's settled in RFC 7258:

<= div>Pervasive Monitoring Is an Attack
=
There hasn't been any IETF activity questioning that pos= ition.

thanks,
Rob

<= /div>
--0000000000004691fa0597317f15-- From nobody Tue Nov 12 21:08:45 2019 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 4503E120058 for ; Tue, 12 Nov 2019 21:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=CHjx8TBf; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Fx41g/4T 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 dQZbB6iO148g for ; Tue, 12 Nov 2019 21:08:38 -0800 (PST) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B98C120922 for ; Tue, 12 Nov 2019 21:08:35 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id C77306AD; Wed, 13 Nov 2019 00:08:34 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Wed, 13 Nov 2019 00:08:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=H Af7SlZ4X1ue1GYLIG7LCLSaMyYP1fV2fCZIbPkOzUc=; b=CHjx8TBfXx8WmDHy9 5u5BzB6ECEuGTb6PC0Aq0SZfSrqvpAdWuPPmCDFnMqeSJl9zDSKcmO8mF2RjSAKo 6fwQbI+lnElXg92mXrLdMROE4EDHS8il6ROHPoQN+6PtBlhKnh1v5UBqd0ceOas6 gCYvSoojm0zMikS3FScU9Dic/gthcipL2qk50K+Wj3ZSvZt3+E83n4+bG7rx6fOH PPEAeDFnuYM9TQMyCSBXEy8eL8Mj9zKycLbuiua+esle0CUY4lwIyLgPUggBvSSm CVB2lEcfbTXzvayxO/MPHUZnTBNAZD5NfykAkinGqy1A+mwMbJJ7tcK1wVal1Wra YTa3g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=HAf7SlZ4X1ue1GYLIG7LCLSaMyYP1fV2fCZIbPkOz Uc=; b=Fx41g/4TLdg01YWaUgwUeljdwZh89JqIWoz0beTqyD5oHkE5ddJJhpKuS 4SRAVyv2BAarztoMUrAOQgQtwSd2bIQjvqMKNjJ1q3g/FlsTu4XgOgRMTWKoprec rd91BlAfamarQOScYCmQLOZCsvuJc2csEUgmf/xfgY3nfHju11gnhzjwoFLDKg1u PcliOIasXugXHZfzCpt9zTaz7dyg+jxj7JbK93J1IVdRBX0JC4HiJIHqujNhJrZx Qo7ZgqhcmAYPtAhLBbeGkQ5uFFS1QDm6Yfo0HahJs6dfH74ZqacmMXz3fnr5OIzy bNlcmaorshiVHpdIYZLQn3AVPtzxQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeftddgkeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqh hmtdhhtddvnecuhfhrohhmpeforghrkhcupfhothhtihhnghhhrghmuceomhhnohhtsehm nhhothdrnhgvtheqnecuffhomhgrihhnpehivghtfhdrohhrghdpmhhnohhtrdhnvghtne cukfhppeduudelrddujedrudehkedrvdehudenucfrrghrrghmpehmrghilhhfrhhomhep mhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id B5FBF3060057; Wed, 13 Nov 2019 00:08:32 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Mark Nottingham In-Reply-To: Date: Wed, 13 Nov 2019 16:08:28 +1100 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> References: To: Ben Schwartz X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 13 Nov 2019 05:08:44 -0000 Hi Ben, > On 13 Nov 2019, at 1:32 pm, Ben Schwartz = wrote: >=20 > On behalf of the ABCD BoF chairs, I am writing to confirm that the = draft agenda for the ABCD BoF has now been posted, along with a revised = charter proposal. >=20 > Agenda: = https://datatracker.ietf.org/meeting/106/materials/agenda-106-abcd > Proposed charter: = https://datatracker.ietf.org/meeting/106/materials/slides-106-abcd-propose= d-charter-text-revised >=20 > We have significantly adjusted the proposed charter text, = incorporating comments and suggestions from ADD participants. Most = notably, the revised text attempts to ensure that disagreements on the = most contentious questions will not impede valuable standards = development in less controversial areas. >=20 > Please review the agenda and proposed charter, and join us next week = for a full discussion. At the end of the proposed charter, it says: """ The following topics are also relevant, but represent areas that are = significantly more challenging for consensus-building: - End-user privacy and pervasive surveillance - Detection and suppression of malware - Use of records from untrusted sources - Policy enforcement and control of the stub resolver configuration - Use and impacts of large recursive resolution services The working group will not attempt to resolve disagreements on these = topics, and will require full consensus on any statements regarding = these areas. """ However, earlier, it says: """ Some network operators have used DNS services for a variety of purposes = beyond simple query resolution, and have relied on DNS clients to send = queries to their recursive resolver or to transmit queries unencrypted. = Maintaining support for those uses, if they are retained, may require = new practices and protocols. """ This seems to imply that the Working Group will evaluate ways to support = those use cases -- and promptly run into a discussion of items 1, 2, and = 4 on the list above. What's the intent here? Also, what is "full consensus", and how do you achieve it if you can't = attempt to resolve disagreement on the topic that requires it? Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Nov 13 00:50:56 2019 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 660E61208A7 for ; Wed, 13 Nov 2019 00:50:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uvJqi62k2Dv9 for ; Wed, 13 Nov 2019 00:50:51 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B8C1208A8 for ; Wed, 13 Nov 2019 00:50:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 257F0BE2E; Wed, 13 Nov 2019 08:50:48 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlSPgo19IXTt; Wed, 13 Nov 2019 08:50:45 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 1B527BE24; Wed, 13 Nov 2019 08:50:45 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1573635045; bh=hpuiB5CGdOc0VWeKnJf+YDoGHIeNEuhVm810X3qKYAs=; h=Subject:To:References:From:Date:In-Reply-To:From; b=h3P9J0LJgSnC7e1v+vgc3l9SHB8r3UNhBs0TXMbVSja25WwrOKGhrD0HdhYhElI0E JC7z7tVA1M5XU3F768lskGU5bE8F6HXiEP2ZgRhElaejZuKwJuxuYxP03o5VaxeQJ2 ZNNVTX146OPGQ2/nuSCryuM/K3Y/vLrcst9Sxyug= To: Ben Schwartz , ADD Mailing list References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <20e1dc19-c567-5a48-c299-30e8866d229e@cs.tcd.ie> Date: Wed, 13 Nov 2019 08:50:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="PB6UfcvI5sIhlTFjWdDcbaLLaVRdNFFlm" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 13 Nov 2019 08:50:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --PB6UfcvI5sIhlTFjWdDcbaLLaVRdNFFlm Content-Type: multipart/mixed; boundary="yQU9S0C4SqxyQyMinMW51oMN69bCswEzs"; protected-headers="v1" From: Stephen Farrell To: Ben Schwartz , ADD Mailing list Message-ID: <20e1dc19-c567-5a48-c299-30e8866d229e@cs.tcd.ie> Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF References: In-Reply-To: --yQU9S0C4SqxyQyMinMW51oMN69bCswEzs Content-Type: multipart/mixed; boundary="------------9E824A8069EC491D87153691" Content-Language: en-US This is a multi-part message in MIME format. --------------9E824A8069EC491D87153691 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 13/11/2019 02:32, Ben Schwartz wrote: > On behalf of the ABCD BoF chairs, I am writing to confirm that the draf= t > agenda for the ABCD BoF has now been posted, along with a revised chart= er > proposal. >=20 > Agenda: https://datatracker.ietf.org/meeting/106/materials/agenda-106-a= bcd > Proposed charter: > https://datatracker.ietf.org/meeting/106/materials/slides-106-abcd-prop= osed-charter-text-revised >=20 > We have significantly adjusted the proposed charter text, incorporating= > comments and suggestions from ADD participants. Most notably, the revi= sed > text attempts to ensure that disagreements on the most contentious > questions will not impede valuable standards development in less > controversial areas. >=20 > Please review the agenda and proposed charter, and join us next week fo= r a > full discussion. >=20 Like Mark, I had a comment on this bit: " The following topics are also relevant, but represent areas that are significantly more challenging for consensus- building: - End-user privacy and pervasive surveillance - Detection and suppression of malware - Use of records from untrusted sources - Policy enforcement and control of the stub resolver configuration - Use and impacts of large recursive resolution services " I don't think the above is true, as written. I believe we do have consensus on the goodness or badness of items 1-3 but differ in how best to meet the relevant goals in this context. Items 4 & 5 also seem like different categories from 1-3. I suggest revising 1-5 so each bullet captures the actual area where there's a lack of consensus, e.g. replace "End-user privacy" with "End-user privacy impacts of DoT/DoH deployments can vary - even over the lifetime of one host as it moves between networks" or similar. That'll take more words but that's ok. I also think the sentence about "full consensus" needs fixing. (I don't believe we have a definition of that in any case, and I suspect this is not the right opportunity for defining such a concept:-) Cheers, S. --------------9E824A8069EC491D87153691 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------9E824A8069EC491D87153691-- --yQU9S0C4SqxyQyMinMW51oMN69bCswEzs-- --PB6UfcvI5sIhlTFjWdDcbaLLaVRdNFFlm Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3Lw+QACgkQWrL68XsX K+o4HhAAsss5g54X6UqVa7jvn+LQtCwKY3ALBSPWbDz7eYZudznbs9almCKQwx2O T4zk6l+WyZhq6OkNHW3EtpkU80ixLORbu87hgP4n6z1iiY2e8YEDVEz6oIGVpygL FqVEvCYGOt1DGCjB7ajjqEe4/R49C+3VA3RIAdqy6JrNuFV/vYD0iExxBeI7ZRQ/ ib3lx3qhBIC8be/CWQn+0DNdxxz2TBEeISJ6feQk4MVY3+C8TCsCXXmsKPUDY5UJ YnH46F03hStwR1K7AsaqzMFmSsNkPKbIO0iCuk9uzwrqKpqZb7lHxnFc4Q3sI8iI y9nvLiIgMQ+3pkL0c6jh4xf+4IsVQqi9vGwk7xpz3an/gbc3K8nv+rNDYGr9CN/j 2ErPCX85dabU2rQfIcM7clY1B9vD2wImD5ISGzGaHKIptXTHih13fiO0X5oQj8Mi hWSH2yEH0LFF9jg6Ruq9ep3t3aM3VhdrXe7iRGy0VY0R9zABUeZPmOv/GbeSt3BR C5zcklYk3FwDkOzfdpfiwgy7MTc8hgetjFMQxLj3ghCQ0MtHM/eeQ777yVhnNPqs 8Cq6XHaY/Eh8pKw0Qsf6EIvDoQkMzdl46ouKk65NOunlCBZ52MK13aOmk1wRVD2h qcMZWzkwWUmasp4u6+IohIfNxM/7fAymwEMLrJ4GGhr7kFezFwI= =AOoT -----END PGP SIGNATURE----- --PB6UfcvI5sIhlTFjWdDcbaLLaVRdNFFlm-- From nobody Wed Nov 13 02:55:18 2019 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 E56D012003F for ; Wed, 13 Nov 2019 02:55:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sky.uk 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 F2qo5azUXjQ2 for ; Wed, 13 Nov 2019 02:55:14 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70041.outbound.protection.outlook.com [40.107.7.41]) (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 7E453120072 for ; Wed, 13 Nov 2019 02:55:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QaHyMvBC5EfklMTLoinqY6xJfNG8rzQxe62kF35UnBHyvFViWZeYU3ComHk6R42sNvSAPKV8pZ5EbdQEYFK2SkjvLNMOP7As+1gD5zGm+rNuNzCZd1w9MpGLOyq9v9B/glFTztHwCPiPP/KIbLxJCSMBsVXfLGasBtLQDVOz6L3uOrLJBzYLUnSYDAxPKW1+wd3PvT7mDMRhzr4zf9s+dwRw+nFGbbuiM5dTn2p45fPz5ZL+WFAgLL4SnDfbheFtCacLYx70QU9ycmiLi4d0bqsl7nEVK/THSP71DMAyDpsKoDlc3sCooOkbEAE6Z6xITjkY7xz1csvapmwAXy4VGg== 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=jsQMZyS/AxUo7mhs5aLCYReNwYpM5fVOiOYrrvNkMrw=; b=VHFd8lqRf3NW+wKBfyFGKBD7zxyka18NJIZq3gYTAfu2hdxBxfoJ6jonzmpFVPlYfOwYBwLW0opaNSbcLbHjvN5f4FJG0wqdu8/OPJIxIk9a0DfBoQXYnI0NcD2C+iJQijlEJRC9Fz0U8btb5dnIpJGSNCnB6Ytrzk/S3+BZP3v+kEywGOliw5Bc7xFZq2Q0QM2+HsrQNEslTvcAe0PSdm+STV8y0/rQ/UpfRyViICEhjRWSdFi9hjgiuYHmMrr8+KZfCVdFgP/Q0rT5u8Ko7tLn0TXWwHcFNs0kFw9nDIhoui+R8dho3mAqkpTp7HcF0mD345D4buZm7pArR1fEHw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sky.uk; dmarc=pass action=none header.from=sky.uk; dkim=pass header.d=sky.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=jsQMZyS/AxUo7mhs5aLCYReNwYpM5fVOiOYrrvNkMrw=; b=lZRzb+NYz7IdDukbQQzDwkrwPIzBIf8NpaxVqypRmIZSr3IieT5E68rW2jY8CttRIVh2VausARb3thLBeJ+W7Io7XStktmF0hzEEmT3PWCRpfR5Y2TssrJ4oly2YKntxekFQB32rVvLGslJucTJKJ88d0QTAdk8RdGL+1oRAT1M= Received: from DB6PR0602MB2805.eurprd06.prod.outlook.com (10.172.248.15) by DB6PR0602MB3318.eurprd06.prod.outlook.com (10.170.211.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.22; Wed, 13 Nov 2019 10:55:11 +0000 Received: from DB6PR0602MB2805.eurprd06.prod.outlook.com ([fe80::99a5:cbea:5d41:ab2e]) by DB6PR0602MB2805.eurprd06.prod.outlook.com ([fe80::99a5:cbea:5d41:ab2e%5]) with mapi id 15.20.2451.023; Wed, 13 Nov 2019 10:55:11 +0000 From: "Dixon, Hugh" To: ADD Mailing list Thread-Topic: ABCD BoF agenda items, pervasive monitoring and privacy Thread-Index: AQHVmhDS96z9Z8gdakCqsARxecCtqA== Date: Wed, 13 Nov 2019 10:55:11 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191103 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hugh.Dixon@sky.uk; x-originating-ip: [151.230.28.108] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5c071b7-ed9b-4ddc-7b5e-08d76827f4fa x-ms-traffictypediagnostic: DB6PR0602MB3318: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(39860400002)(346002)(136003)(366004)(189003)(199004)(66446008)(66556008)(71190400001)(64756008)(3846002)(6512007)(476003)(186003)(6486002)(6116002)(2906002)(66946007)(14444005)(5024004)(256004)(91956017)(76116006)(66476007)(102836004)(33656002)(14454004)(478600001)(71200400001)(2616005)(6506007)(6436002)(26005)(36756003)(66066001)(58126008)(99286004)(25786009)(305945005)(316002)(486006)(7736002)(81156014)(81166006)(8936002)(5660300002)(8676002)(6916009)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0602MB3318; H:DB6PR0602MB2805.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:0; received-spf: None (protection.outlook.com: sky.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: APyYv95jQ0DpwwXeUSI2rzS9WiWtROIkAGv5u+9bZ+4Y9EGmlg3E3MWD3p9NzBGYkCLrm6eR7idAJRWUIPRjGPG0tNNN6kuLagqTykDBnZ8MdhjLyVwnCbTayK4i8hdkCM7c4lSJfJUrQZm8Tjc51JZKUYd1X4bkeKiUM62tpw5BEwEKZgon3fLJrsnjVMU8rr/rEWgt+PKy6TcoR82MzlQHi2Yv1n7Gbgaea/5XIBOKlc8muJb1KkByG0V7FGCox2sM5dZoCoEL2v+vNUzrveuMBz61khfm9gS5t6pcSzXPFSJ2gSVuFIhzr/GNFOg7gkcgBJz5CTHDIQiKRgezlardzMRKHAs4GNeuvuI5ifMXDUW2ZjZP9rgc5J/iRCB1kYLQ60knI2+yOelfTxjtY344jnkPD9WOSqXJlXrtKxT8+wcM6RTvH3YgiW1sHbzq x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-Network-Message-Id: e5c071b7-ed9b-4ddc-7b5e-08d76827f4fa X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2019 10:55:11.7964 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: uV4CCQMo0/F19k67rqLJnYQ4DLa1tUccYRhB1XHe1/esukCsfYfyDP+OXenS0qh/fqxCC3U1yRgSZRNjj+5/Pg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0602MB3318 Archived-At: Subject: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 13 Nov 2019 10:55:17 -0000 U29tZSBtaWdodCBsaWtlIHRvIHRoaW5rIHRoYXQgIlBlcnZhc2l2ZSBNb25pdG9yaW5nIiBpcyBj bGVhciBhbmQgYm9sZC4uLg0KDQogKGZyb20gUkZDNzI1OCk6DQoiUGVydmFzaXZlIE1vbml0b3Jp bmcgSXMgYW4gQXR0YWNrIg0KDQoiUGVydmFzaXZlIE1vbml0b3JpbmcgKFBNKSBpcyB3aWRlc3By ZWFkIChhbmQgb2Z0ZW4gY292ZXJ0KQ0KICAgc3VydmVpbGxhbmNlIHRocm91Z2ggaW50cnVzaXZl IGdhdGhlcmluZyBvZiBwcm90b2NvbCBhcnRlZmFjdHMsDQogICBpbmNsdWRpbmcgYXBwbGljYXRp b24gY29udGVudCwgb3IgcHJvdG9jb2wgbWV0YWRhdGEgc3VjaCBhcyBoZWFkZXJzLiINCg0KIiBX aGlsZSBQTSBpcyBhbiBhdHRhY2ssIG90aGVyIGZvcm1zIG9mIG1vbml0b3JpbmcgdGhhdCBtaWdo dCBmaXQgdGhlDQogICBkZWZpbml0aW9uIG9mIFBNIGNhbiBiZSBiZW5lZmljaWFsIGFuZCBub3Qg cGFydCBvZiBhbnkgYXR0YWNrLCBlLmcuLA0KICAgbmV0d29yayBtYW5hZ2VtZW50IGZ1bmN0aW9u cyBtb25pdG9yIHBhY2tldHMgb3IgZmxvd3MgYW5kIGFudGktc3BhbQ0KICAgbWVjaGFuaXNtcyBu ZWVkIHRvIHNlZSBtYWlsIG1lc3NhZ2UgY29udGVudCAiDQoNCg0KU28gLi4uDQpQTSBpcyBhbiBh dHRhY2suICBTb21lIFBNIGlzIG5vdCBhbiBhdHRhY2suDQoNCj8NCkgNCg0KSW5mb3JtYXRpb24g aW4gdGhpcyBlbWFpbCBpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzIG1heSBiZSBwcml2aWxlZ2Vk LCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGV4Y2x1c2l2ZWx5IGZvciB0aGUgYWRkcmVz c2VlLiBUaGUgdmlld3MgZXhwcmVzc2VkIG1heSBub3QgYmUgb2ZmaWNpYWwgcG9saWN5LCBidXQg dGhlIHBlcnNvbmFsIHZpZXdzIG9mIHRoZSBvcmlnaW5hdG9yLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCBpdCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwg YW5kIGRlbGV0ZSBpdCBmcm9tIHlvdXIgc3lzdGVtLiBZb3Ugc2hvdWxkIG5vdCByZXByb2R1Y2Us IGRpc3RyaWJ1dGUsIHN0b3JlLCByZXRyYW5zbWl0LCB1c2Ugb3IgZGlzY2xvc2UgaXRzIGNvbnRl bnRzIHRvIGFueW9uZS4gUGxlYXNlIG5vdGUgd2UgcmVzZXJ2ZSB0aGUgcmlnaHQgdG8gbW9uaXRv ciBhbGwgZS1tYWlsIGNvbW11bmljYXRpb24gdGhyb3VnaCBvdXIgaW50ZXJuYWwgYW5kIGV4dGVy bmFsIG5ldHdvcmtzLiBTS1kgYW5kIHRoZSBTS1kgbWFya3MgYXJlIHRyYWRlbWFya3Mgb2YgU2t5 IExpbWl0ZWQgYW5kIFNreSBJbnRlcm5hdGlvbmFsIEFHIGFuZCBhcmUgdXNlZCB1bmRlciBsaWNl bmNlLg0KDQpTa3kgVUsgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAyOTA2OTkxKSwgU2t5LUlu LUhvbWUgU2VydmljZSBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDIwNjcwNzUpLCBTa3kgU3Vi c2NyaWJlcnMgU2VydmljZXMgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiAyMzQwMTUwKSBhbmQg U2t5IENQIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gOTUxMzI1OSkgYXJlIGRpcmVjdCBvciBp bmRpcmVjdCBzdWJzaWRpYXJpZXMgb2YgU2t5IExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjI0 NzczNSkuIEFsbCBvZiB0aGUgY29tcGFuaWVzIG1lbnRpb25lZCBpbiB0aGlzIHBhcmFncmFwaCBh cmUgaW5jb3Jwb3JhdGVkIGluIEVuZ2xhbmQgYW5kIFdhbGVzIGFuZCBzaGFyZSB0aGUgc2FtZSBy ZWdpc3RlcmVkIG9mZmljZSBhdCBHcmFudCBXYXksIElzbGV3b3J0aCwgTWlkZGxlc2V4IFRXNyA1 UUQNCg== From nobody Wed Nov 13 02:56:40 2019 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 01C66120072 for ; Wed, 13 Nov 2019 02:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=isoc.org 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 eQTyA_1Aumte for ; Wed, 13 Nov 2019 02:56:35 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-eopbgr770070.outbound.protection.outlook.com [40.107.77.70]) (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 A452412003F for ; Wed, 13 Nov 2019 02:56:35 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hr2r5D+S5g6o/PV1QW+bpHLunq0b1F125U32o829CHfQkCI1wweUGMqt/xYKdkfb/Jd+NlawP5TjxoHDOqPTuMHolaE9CPyNz8DYDUeoCjAv1AtYtEZNIE2JZEksuLydKpqRG3VDULtTpGOIvLeGz2UY4BbG8NH6J/S88BDNFv6hJgWlKBVB6SvM6+SJwHrQ+Yjf8n/p/L8wsMXugAhaRAe45afLEq2twg0wmeniy9O0xJZDRZN+N5VCuKaWzCAKRpH++2VZouDQzLaH50Yn8GQCIcpyh2urv1634feUwbSZOUWtiN9CUSsyCelqOGBp5o0wY+nlWUAe7rvt2XqZRA== 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=+cgFwgsVb3ySs0PG8ZcJbh6tYJzz3MIOQ15/cXPn3c0=; b=PSU9tU45lBCZmWk8CWxMV2ypYfbt3Slga4UDvnW1+qwYs7snTGvh4/il293ywNx5T+MwMeHxIwiKttAGwMxOlaVt4f6ZwiLnKZMVNmys2bt3kRYFqOja2sH9Uf7tEJFmLafDaECdO1P06xpb1VnlCYJaSJiQinLHLvfKGLmLKzpR7BiLscvywSkFjOAtih/un4aBw2Ncup+W6naxtBBH4P/6UpL/WqiKGhPY5ZGi0ftQ8qconw0tcJiPcawNqQACc4bCJg+YTULUCuLirwRqaJWXTOL9LfMOzaqyHFZzTEgKAW5kyABUd9+kwGjqJgLet15nDSy3DOQ6uIy5Qo0eaQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+cgFwgsVb3ySs0PG8ZcJbh6tYJzz3MIOQ15/cXPn3c0=; b=otyaHy1ZGxt1qA1r+ThRB3nsCUwGtrxC4snR+VykxlzmBOn8Gua+1SKG+kEOHYLpLZ/ofBo2OKCLDHxS979Rk2Tu1BGSe9oyp3xNAXB4xKgnO8klRwa0sQVrCSaWFXPkUoRhJiupe1orQ0msSLuJAci+cIYAVryGlRYMRDoA1bQ= Received: from BN6PR06MB3300.namprd06.prod.outlook.com (10.174.234.151) by BN6PR06MB2339.namprd06.prod.outlook.com (10.173.18.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.24; Wed, 13 Nov 2019 10:56:32 +0000 Received: from BN6PR06MB3300.namprd06.prod.outlook.com ([fe80::b0c9:d497:e3ed:eb89]) by BN6PR06MB3300.namprd06.prod.outlook.com ([fe80::b0c9:d497:e3ed:eb89%7]) with mapi id 15.20.2430.027; Wed, 13 Nov 2019 10:56:32 +0000 From: Mat Ford To: Ben Schwartz CC: ADD Mailing list Thread-Topic: [Add] Agenda and Revised Charter for the ABCD BoF Thread-Index: AQHVmhECBFHZ1h8LXkOO3ENJWIJNvw== Date: Wed, 13 Nov 2019 10:56:32 +0000 Message-ID: <5D7CDD73-6CEE-4C32-822A-D49E48E60301@isoc.org> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-clientproxiedby: LO2P265CA0013.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:62::25) To BN6PR06MB3300.namprd06.prod.outlook.com (2603:10b6:405:45::23) authentication-results: spf=none (sender IP is ) smtp.mailfrom=ford@isoc.org; x-ms-exchange-messagesentrepresentingtype: 1 x-mailer: Apple Mail (2.3601.0.10) x-originating-ip: [2001:8b0:dcb:7d85:9039:9fbf:6c2f:c13a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6062b37e-3f55-45c2-0abf-08d7682824c6 x-ms-traffictypediagnostic: BN6PR06MB2339: x-ms-exchange-purlcount: 2 x-ms-exchange-transport-forked: True x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39840400004)(136003)(346002)(376002)(366004)(199004)(189003)(497574002)(6436002)(256004)(316002)(52116002)(6486002)(11346002)(2906002)(446003)(8676002)(36756003)(81166006)(6306002)(14444005)(81156014)(99286004)(76176011)(6116002)(186003)(50226002)(8936002)(229853002)(6512007)(6916009)(486006)(46003)(5660300002)(478600001)(2616005)(14454004)(66946007)(561944003)(102836004)(966005)(33656002)(476003)(386003)(64756008)(25786009)(66556008)(66446008)(66476007)(6506007)(86362001)(6246003)(71200400001)(7736002)(71190400001)(305945005)(4326008)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR06MB2339; H:BN6PR06MB3300.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Of8Su7TAAEN1IwOGOzdILAiyhy0+IC7Js4cOpDMUsA2Hr0blK1H61Gd4+P1gZmrR+m3SZOYKKfgpula1RDDGEH51gtaL7XFw6ihT1ALoIlUo0DTFJDW5qOOs5TynX4MIFLw2biTjfRNXBysSwpGF3WJLDYY82T85vAL+D1KjCNBULZvqbLs1ls9TovlZ+PrariOc52EL/bVNH52TQb4ouxi8bmWWCqfYjhvUI4V1VownfZ06VuRMWLYcdIkGk84DfsDi9GGtNFYyEhUmXrN9zheecIKlB4TtKbV/VWe1uu7ABT9/7FKb/KeBdnHcm73JsEGiV4e0/w/lV7pYqN+lNP8TIY0d1/WbVKG+aOmMb0IiAiN3LnL+bi6GUTSZViI9pXVLVwUAELeFYS5fqIy5JWz3ibZ/nmqeU4iMuaYuIZ/SBL4A7vNt5fsPNEfp3O5YcYQuHFJK/C0p2uU1kL3XHYLfYw6eD7IXPFy9KsArm7A= Content-Type: text/plain; charset="us-ascii" Content-ID: <68FEC115AD5C1C4FBC36253E93BD6098@namprd06.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 6062b37e-3f55-45c2-0abf-08d7682824c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2019 10:56:32.3222 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: f1R0CxNioXdwugOuBFg68Bv0sac275DjDwLpLP2HPBDd1TP5TqCDmbkpmWfh++/c X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR06MB2339 Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 13 Nov 2019 10:56:39 -0000 Hi Ben, [not speaking for anyone but myself] I also stumbled over this text in the proposed charter: > The working group will not attempt to resolve disagreements on these topi= cs, and will require full consensus on any statements regarding these areas= . I think we might want to say something stronger about not being a home for = discussions on these topics (because we don't expect to be able to resolve = noted disagreements). That then makes the point about 'statements regarding= these areas' moot (i.e. it can be removed, and then you don't need to get = into a definition of 'full consensus'). Mat > On 13 Nov 2019, at 02:32, Ben Schwartz wrote: >=20 > On behalf of the ABCD BoF chairs, I am writing to confirm that the draft = agenda for the ABCD BoF has now been posted, along with a revised charter p= roposal. >=20 > Agenda: https://datatracker.ietf.org/meeting/106/materials/agenda-106-abc= d > Proposed charter: https://datatracker.ietf.org/meeting/106/materials/slid= es-106-abcd-proposed-charter-text-revised >=20 > We have significantly adjusted the proposed charter text, incorporating c= omments and suggestions from ADD participants. Most notably, the revised t= ext attempts to ensure that disagreements on the most contentious questions= will not impede valuable standards development in less controversial areas= . >=20 > Please review the agenda and proposed charter, and join us next week for = a full discussion. From nobody Wed Nov 13 08:11:55 2019 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 898AA120832 for ; Wed, 13 Nov 2019 08:11:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMgDCmibVflG for ; Wed, 13 Nov 2019 08:11:51 -0800 (PST) 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 7A4C312082F for ; Wed, 13 Nov 2019 08:11:51 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id p6so3144210iod.7 for ; Wed, 13 Nov 2019 08:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IkvybNG5kVGudAWqJULv3j3im2TIS7Gqou4W/5PSH4E=; b=rXGKcbfae61HHZKim7ZSs56hvTbo6XrVFIYNsQAH+Zdsw3y3UbYQ4DTi5W6Sc5JJGM 4FNTj/um0OUoBbtBC0xWF9SA5vzIE2kBcNemfrmCO98azxVePDsiUa5o4nCUq/OABT67 nbC0uO8X8WkgzEgrySD2JizUyxxZCi4moNXaIfG9KMZbiisC8Hw9FaugXLgBC5P8xFTr 4Pq1BFfCqP4Yhfu3fIDvBQjKT4x+wV0YgSowBRltlsBEMDQAlaHKO5JufqQa2nTLWgIm 1mBKT9a/vs0MFyUQn2FWZP6xemnaJbdUuQyk3xO2JL/bDJT0s4l3dLTEVacctfC5Xaim nghg== 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=IkvybNG5kVGudAWqJULv3j3im2TIS7Gqou4W/5PSH4E=; b=oJ27RnVPJZaRVRxlJ9sV1BqSa0mNR2Oa4150Y+K8Nj9S+ixl+wIOgKYscOmCM9+jzt 2qUUVJQS/T5L16hb9QrvmHglpOe5W9udfnoCTd5K2BRkAVu150ymjM3WpXeuGFWdd0Ps o45GEPy+uKzx/65y6veev7Tq78s3xUfCoYIAfqF4CzQSHKktzOXeW95Ptq0MJIahgLBp WurJ9QaVWuH3GzWObqFtjv1tavSkfijfnNxBzgXSmH3JDz7PApKNbJnJfGqq1uH8RUCf nCZLx2QoMwrtRQuJZYlim9tf3tyCb8NPbSuX0kBgCcniIO/GH4Qs7DcT97FHzGujPqX9 xKBA== X-Gm-Message-State: APjAAAVeMnQnarZl+gpOQvbOuxa6KWSeWNI+BGkZPRZt1LbsgNwbeBwk 5Cnuui8WfGsYeL0HlGUgjapi47wzcm6a+bXL7FhvLYjL9sA= X-Google-Smtp-Source: APXvYqzMOPyUqGcNGYAH2UQ69S16SSqlVOqzX24Lv99prgr8+VRaOVWFCxEYPw1kI1GcPiAC2OWnPEEI3PcL97gMGN4= X-Received: by 2002:a5d:8b99:: with SMTP id p25mr4023902iol.41.1573661510284; Wed, 13 Nov 2019 08:11:50 -0800 (PST) MIME-Version: 1.0 References: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> In-Reply-To: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> From: Ben Schwartz Date: Wed, 13 Nov 2019 11:11:38 -0500 Message-ID: To: Mark Nottingham Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000005c8d0b05973c9fa6" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 13 Nov 2019 16:11:53 -0000 --0000000000005c8d0b05973c9fa6 Content-Type: multipart/alternative; boundary="00000000000051be9a05973c9fa0" --00000000000051be9a05973c9fa0 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 13, 2019 at 12:08 AM Mark Nottingham wrote: > Hi Ben, > > > On 13 Nov 2019, at 1:32 pm, Ben Schwartz 40google.com@dmarc.ietf.org> wrote: > > > > On behalf of the ABCD BoF chairs, I am writing to confirm that the draft > agenda for the ABCD BoF has now been posted, along with a revised charter > proposal. > > > > Agenda: > https://datatracker.ietf.org/meeting/106/materials/agenda-106-abcd > > Proposed charter: > https://datatracker.ietf.org/meeting/106/materials/slides-106-abcd-proposed-charter-text-revised > > > > We have significantly adjusted the proposed charter text, incorporating > comments and suggestions from ADD participants. Most notably, the revised > text attempts to ensure that disagreements on the most contentious > questions will not impede valuable standards development in less > controversial areas. > > > > Please review the agenda and proposed charter, and join us next week for > a full discussion. > > At the end of the proposed charter, it says: > > """ > The following topics are also relevant, but represent areas that are > significantly more challenging for consensus-building: > > - End-user privacy and pervasive surveillance > - Detection and suppression of malware > - Use of records from untrusted sources > - Policy enforcement and control of the stub resolver configuration > - Use and impacts of large recursive resolution services > > The working group will not attempt to resolve disagreements on these > topics, and will require full consensus on any statements regarding these > areas. > """ > > However, earlier, it says: > > """ > Some network operators have used DNS services for a variety of purposes > beyond simple query resolution, and have relied on DNS clients to send > queries to their recursive resolver or to transmit queries unencrypted. > Maintaining support for those uses, if they are retained, may require new > practices and protocols. > """ > > This seems to imply that the Working Group will evaluate ways to support > those use cases -- and promptly run into a discussion of items 1, 2, and 4 > on the list above. What's the intent here? > In response to the initial charter draft, some ADD participants cheered the opportunity to address the thorniest questions, while others declared these topics to be intractable and asked for them to be excluded. I view this text an attempt to find a balance between these perspectives, by permitting the group to address a wide range of topics while avoiding divisive, time-consuming debates. Also, what is "full consensus", I would define "full consensus" as the absence of any stated objection. I think this requirement might foster a more congenial and productive working group environment, because (on the listed topics) participants can object without feeling pressure to emphasize or re-state their arguments. In my view, the disagreements in question are not principally "technical", so it doesn't make sense to ask the chairs to assess "technical consensus". and how do you achieve it if you can't attempt to resolve disagreement on > the topic that requires it? > I would suggest collaborating in public on less controversial work, which might strengthen relevant relationships, and discussing any deeper disagreements privately until you find common ground that can be presented jointly to the group. Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > --00000000000051be9a05973c9fa0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 13, 2019 at 12:08 AM Mark= Nottingham <mnot@mnot.net> wrot= e:
Hi Ben,

> On 13 Nov 2019, at 1:32 pm, Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.or= g> wrote:
>
> On behalf of the ABCD BoF chairs, I am writing to confirm that the dra= ft agenda for the ABCD BoF has now been posted, along with a revised charte= r proposal.
>
> Agenda: https://datatracker.i= etf.org/meeting/106/materials/agenda-106-abcd
> Proposed charter: https://datatracker.ietf.org/meeting/106/materials/slide= s-106-abcd-proposed-charter-text-revised
>
> We have significantly adjusted the proposed charter text, incorporatin= g comments and suggestions from ADD participants.=C2=A0 Most notably, the r= evised text attempts to ensure that disagreements on the most contentious q= uestions will not impede valuable standards development in less controversi= al areas.
>
> Please review the agenda and proposed charter, and join us next week f= or a full discussion.

At the end of the proposed charter, it says:

"""
The following topics are also relevant, but represent areas that are signif= icantly more challenging for consensus-building:

- End-user privacy and pervasive surveillance
- Detection and suppression of malware
- Use of records from untrusted sources
- Policy enforcement and control of the stub resolver configuration
- Use and impacts of large recursive resolution services

The working group will not attempt to resolve disagreements on these topics= , and will require full consensus on any statements regarding these areas.<= br> """

However, earlier, it says:

"""
Some network operators have used DNS services for a variety of purposes bey= ond simple query resolution, and have relied on DNS clients to send queries= to their recursive resolver or to transmit queries unencrypted. Maintainin= g support for those uses, if they are retained, may require new practices a= nd protocols.
"""

This seems to imply that the Working Group will evaluate ways to support th= ose use cases -- and promptly run into a discussion of items 1, 2, and 4 on= the list above. What's the intent here?

In response to the initial charter draft, some ADD participants cheer= ed the opportunity to address the thorniest questions, while others declare= d these topics to be intractable and asked for them to be excluded.=C2=A0 I= view this text an attempt to find a balance between these perspectives, by= permitting the group to address a wide range of topics while avoiding divi= sive, time-consuming debates.

Also, what is "full consensus",

I= would define "full consensus" as the absence of any stated objec= tion.=C2=A0 I think this requirement might foster a more congenial and prod= uctive working group environment, because (on the listed topics) participan= ts can object without feeling pressure to emphasize or re-state their argum= ents.=C2=A0 In my view, the disagreements in question are not principally &= quot;technical", so it doesn't make sense to ask the chairs to ass= ess "technical consensus".

and how do you achieve it if you can'= t attempt to resolve disagreement on the topic that requires it?

I would suggest collaborating in public on less c= ontroversial work, which might strengthen relevant relationships, and discu= ssing any deeper disagreements privately until you find common ground that = can be presented jointly to the group.

Cheers,

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/

--00000000000051be9a05973c9fa0-- --0000000000005c8d0b05973c9fa6 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCDumMSJfbBPpyFy/Y7W6HmK qa9SpyOwCuzyBbCUl+Q9ajAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTExMTMxNjExNTFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAK66fVXkDKqZdSeQ86mKwgb+2f2R0FBjV53T80Dsn NKUh3whoeBjulHArvnGPGCEdxhtyn8sYmbOHv/vRLmER/J1T1upXy//9kbfpW9JmfhaaWG+CRY+h nLb9DHIt+wO2EmiGLH+sn1aZTZhSWVYdS1obWlR8ogND42c+k2/zQRBteszc5OEykRS0u1P5/Hjk 3970lDLq3XB4zjeul/3kDQ7+rfgkrqeY2zR93T2aBkkvRMzuiUCwXGBA7MRuv3ZcDgdR4ki0m1i/ bprT1gusd6UAZE2d8WVDee9f2EptHW0iUFQW9h4yNIKtxuPbmmU8GzOx7kzlqt1WYQa+ddEZOA== --0000000000005c8d0b05973c9fa6-- From nobody Wed Nov 13 08:21:55 2019 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 1EE931208E1 for ; Wed, 13 Nov 2019 08:21:54 -0800 (PST) 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 6PeO6ZzSyTrU for ; Wed, 13 Nov 2019 08:21:52 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FB91208E6 for ; Wed, 13 Nov 2019 08:21:52 -0800 (PST) Received: from dhcp-3.rfc1035.com (hutch.rfc1035.com [195.54.233.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 13CAD2421173; Wed, 13 Nov 2019 16:21:49 +0000 (UTC) From: Jim Reid Message-Id: <9E50B9EB-A70C-43F9-8E3F-35A7101750BE@rfc1035.com> Content-Type: multipart/signed; boundary="Apple-Mail=_5B04489C-B200-4576-B456-BFD59C7316D1"; protocol="application/pgp-signature"; micalg=pgp-sha256 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Date: Wed, 13 Nov 2019 16:21:45 +0000 In-Reply-To: Cc: Mark Nottingham , ADD Mailing list To: Ben Schwartz References: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 13 Nov 2019 16:21:54 -0000 --Apple-Mail=_5B04489C-B200-4576-B456-BFD59C7316D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 13 Nov 2019, at 16:11, Ben Schwartz = wrote: >=20 > I would suggest collaborating in public on less controversial work, = which might strengthen relevant relationships, and discussing any deeper = disagreements privately until you find common ground that can be = presented jointly to the group. I wholeheartedly agree with this approach. There's work to be done in this area and IMO the draft charter gets that = balance right. I hope we can focus on the topics where progress can be = made. --Apple-Mail=_5B04489C-B200-4576-B456-BFD59C7316D1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEzBAEBCAAdFiEECqYQ4ZU4r6HCYB+s/1mQu0V56F8FAl3MLZkACgkQ/1mQu0V5 6F+vqwf/Sy4aBCx8fWnceni+bl8LTIUi7zzRZlKkXcV/sdBlsG1W0vaesfI8NMK2 I6zwiagcsDY+5x6ZYlI577TfwKFMSAS8SZf0dPX7BTjbxzI/DOodWTaGPICWkfVS FJapzj+1B6YifF/EblVgGYZluN3NeiJWgxe5CF1jn8cUEc94HYgqoXxpqKKtI/7H DH5uPJsZKm5E73tJ57TTmWGQyR36OtTuEi/pWtkmcF/tQgjaiQ9qCkBPofvUbQmN m+t0nwyhOf45dvrim9arun7AJLURGxn9BDDfaDqElPy47CLhGct8oPyqJTZx/qrS RGwLtDHZBu7vYbqtAhME63eXlRHS4g== =3ZfS -----END PGP SIGNATURE----- --Apple-Mail=_5B04489C-B200-4576-B456-BFD59C7316D1-- From nobody Wed Nov 13 10:24:26 2019 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 F0AD81208C6 for ; Wed, 13 Nov 2019 10:24:23 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=nomountain-net.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 SoaFT9UC02mg for ; Wed, 13 Nov 2019 10:24:20 -0800 (PST) Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (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 0951F120841 for ; Wed, 13 Nov 2019 10:24:20 -0800 (PST) Received: by mail-qk1-x733.google.com with SMTP id 205so2644981qkk.1 for ; Wed, 13 Nov 2019 10:24:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=NjG720vw7yjiNX65F4GYopXiFwZkEXcBdhUtOyf9aVg=; b=kYLjJAUR/umYC3oe99jqqd2iHLeCUXT5zxO9zeiBC9Gzk4HfLt+JM7yfy9/3lVfFxM AZpLF9mAXU5LQtaVVGKWSfVkLmFjy2Xt2ixIu60bbP0TFpnLY+FWfoHR4PLj9uDWlJLp IOuZmVM+7quyTYvnWJZ/S1NkOcEqWQIehf17ri33kSijOOA+LhoLvDgP0NL23d1Zr05h 0dr+wITU0qZOGam/BXmLIhQ+msyooKCMUPoeV00PRZXVm9aB95Lkna2sytcpeswD/J7D LW5ReI+K7AniXO5o6bJiKEOqf28qnQ3i/WPPKYy/oguhCpOyXLooC/Ia+6NMTG/eVG10 RclQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=NjG720vw7yjiNX65F4GYopXiFwZkEXcBdhUtOyf9aVg=; b=Zx98xM+jC08HP75KI/bKg1KNfuJtFGuNLmFOyM+R2u4ecNqgb2Ozvgg5B/wkNqMqvT 5/vZKQG25UHM1K1SyYvslFbfI2+GCsQeExvHBcoISqkP69KYnPVHMY7qJzepGSRbjudj oJ1s4ZSa5YXatRwT3O2VtNUmdMEjggpi8KSxPTes5elrL15Fa/4btoZMv5eKv4suVig9 TwIxAOJus5qmaXAnLuI0a2bKeWvoV2Rtrwnxxtp77OKI5NLb1/47xXAbplPn6Zl7/vi9 BiNoV4uKNHnijmdg4nTM3S/L53pjfBXLvGe6tYjTK2xoe4pAMehPP7ybphWc1QHUOoRK fQ5g== X-Gm-Message-State: APjAAAXAMEeZxz+QX3k+f+ciFu6eN81XYgERB0WDTz7+Xb+awbfhxzqJ E3OnMfY1dVL4YwukhGezWo6D3Qs5Pw== X-Google-Smtp-Source: APXvYqxjeUnoh354s8rVsuMdS0ODIRJoflDdVoiqgaSkWRpjMqOJoAz/58xmiwnHyEwB+KLABthOeA== X-Received: by 2002:a05:620a:a52:: with SMTP id j18mr3644511qka.385.1573669458619; Wed, 13 Nov 2019 10:24:18 -0800 (PST) Received: from Melindas-MacBook-Pro.local ([69.38.170.39]) by smtp.gmail.com with ESMTPSA id y33sm1853539qta.18.2019.11.13.10.24.17 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Nov 2019 10:24:17 -0800 (PST) To: add@ietf.org References: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: <275528bd-955d-5fe3-b093-d3d997f073fb@nomountain.net> Date: Wed, 13 Nov 2019 13:24:16 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="3VYbKj17DqAdO6vpnSq9KelGAKRaUwLK0" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 13 Nov 2019 18:24:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --3VYbKj17DqAdO6vpnSq9KelGAKRaUwLK0 Content-Type: multipart/mixed; boundary="dlIpCInr6kjmIrPkMFnSPFU9zhDWOeqJT"; protected-headers="v1" From: Melinda Shore To: add@ietf.org Message-ID: <275528bd-955d-5fe3-b093-d3d997f073fb@nomountain.net> Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF References: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> In-Reply-To: --dlIpCInr6kjmIrPkMFnSPFU9zhDWOeqJT Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/13/19 7:11 AM, Ben Schwartz wrote: > Also, what is "full consensus", I got stuck on this one, as well. > I would define "full consensus" as the absence of any stated objection.= =20 Well ... I think that, in general, as individuals we're pretty terrible about distinguishing between objections we can live with and objections we cannot, and organizationally we're not getting much guidance from chairs or ADs about this. Anyway, I'd be careful about getting into a situation in which people are working on something that's unlikely to progress, and the current charter text implies that a working group, if chartered, might do that. I could be wrong but I don't think I've seen any working group charter before that said "This is in scope and we might work on it, but maybe not." I think something a little crisper might help avoid getting into a frustrating situation in which a few folks are fighting to progress something that has little chance of success. Melinda --=20 Software longa, hardware brevis PGP key fingerprint 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F --dlIpCInr6kjmIrPkMFnSPFU9zhDWOeqJT-- --3VYbKj17DqAdO6vpnSq9KelGAKRaUwLK0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl3MSlAACgkQ37iRcpp2 24/L8RAAt9FD/Ic36sQqdXQzzkj904a4g4SJnwRi4BHbMxL8IXw0PVruZGDWTL4V T66jkzlLqLtYbr3YXg7JlB1GezEi3bCsbJmZvAzRv/oUbsIWwsJInNGfRuATLk2g miyVVDf5EEFQpfqwf7uKddrXFsmJhmxiiZ2FkgEPUzIbAAwPYlFhlnk4mIeG18vJ uiGCfbh4yRzYDXUjzvs7vGOvYqTzGITU0BrNvrZYAFr6C/jBtgwl84rW/llpvqgt Ax43WBzYkJBAN4LR6AkwuMYcGNvr4m492TZi3zgQsCWSardHpc+zOLAHsrYD44cN xnMhQPxoL+uAGCJKhHmWSaDJ7ETtueiD1ErHZMh14Ktvj4+gC3mtFem1gi/i2I0D eR5BICwMNBe2ssM5vDjW9953kHWMHQ16f0oXhEkHwr/0M5IACh2PBeoK9UZUPOQx yji5rsy4JKPaNGEoS4XxHy4O8zNLVWz1fteoLDlg+c1UPLnvzwRmxRsCeO/efnxm lddSUqNLuu8rWCuJH3X/Uufqjjzi023YRslCKZIMNA7YAkqn+zw+ZNcUEdibnq3D B9lGNbGTzs7BI3IbBkMaAyAl77UJvfLMJv6nud+ksIL0AHrebRR1mSeTIKoUJGEc LF83G6eoUTVMioAFw2BdkrUcBPERR8KKTfZTJEQgO/C2X+yBwsQ= =/DMJ -----END PGP SIGNATURE----- --3VYbKj17DqAdO6vpnSq9KelGAKRaUwLK0-- From nobody Wed Nov 13 11:52:53 2019 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 13749120273 for ; Wed, 13 Nov 2019 11:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 bozTaH-MeJQj for ; Wed, 13 Nov 2019 11:52:49 -0800 (PST) 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 A6CC812003E for ; Wed, 13 Nov 2019 11:52:49 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47CwJG0kGJzFkZ; Wed, 13 Nov 2019 20:52:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1573674766; bh=ocr5TH/Ag4iPwEa//pbBRPUpHcp0ayGgil1I/dTy3ds=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=LnRYWH5KdEBFDTXmqaHvz1vUOLpTVcaXfqGkntD7hjUbuls1AEq8juLsH13d1X9Ud djvpnRwNr/66rotrpKiuu39BzHUdTpVO3rW/Mb3BqfkUEHLkblfhoKyKj/4Lc8EJ9N tpclZ7xxDApWCUn37slS0c9fIWhfw/qVVUkAvNAA= 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 xtYmFkPrZVmd; Wed, 13 Nov 2019 20:52:44 +0100 (CET) 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, 13 Nov 2019 20:52:44 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6A651602980B; Wed, 13 Nov 2019 14:52:43 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 66AA282DF4; Wed, 13 Nov 2019 14:52:43 -0500 (EST) Date: Wed, 13 Nov 2019 14:52:43 -0500 (EST) From: Paul Wouters To: Melinda Shore cc: add@ietf.org In-Reply-To: <275528bd-955d-5fe3-b093-d3d997f073fb@nomountain.net> Message-ID: References: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> <275528bd-955d-5fe3-b093-d3d997f073fb@nomountain.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 13 Nov 2019 19:52:51 -0000 On Wed, 13 Nov 2019, Melinda Shore wrote: > Anyway, I'd be careful about getting into a situation in which people > are working on something that's unlikely to progress, and the current > charter text implies that a working group, if chartered, might do that. Yes, there is a huge chance nothing will come out of a WG. After all, the IETF work for provding the alternative solutions has been done already. We have DoT and DoH. How, when and if people will use this seems mostly out of scope for IETF. There are some API aspects, but I feel this charter is more likely to just re-open the DoH vs Dot discussion, which like the TLS 1.3 pervasive monitoring situation, will never be resolved as its puts the end-to-end camp against the enterprise camp. Paul From nobody Wed Nov 13 14:51:27 2019 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 17828120142 for ; Wed, 13 Nov 2019 14:51:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 q6ZWhXf2TX1M for ; Wed, 13 Nov 2019 14:51:22 -0800 (PST) Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (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 E8E2F120096 for ; Wed, 13 Nov 2019 14:51:19 -0800 (PST) Received: by mail-vs1-xe32.google.com with SMTP id x21so2530036vsp.6 for ; Wed, 13 Nov 2019 14:51:19 -0800 (PST) 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=RJp0QIeMwMACIOwlpVGkX8hiV1k/+hnJbL42uGwH3Is=; b=CWUtXG5AHQxZITNpLebRlDoc3rhv6lE8tfQIIWa62b6A2eGVjrWN6BadG4mBMKOnYu 2aPvKIX/ISPjNPK5iokLefNDoyNBDUYsuf2wJvrT7aqKG0cbKxyJ07fbud/Bx8Bg0jXa 5XCrAFGxBTgED9E7jisAGUjHqI4P476ERWhrdV1b25uvzxh5OAzbzWDsSm6r+nVxkC2Y JGj5V3YGfXi0lO0UM8buZL8LML3EPv2rhMWxhXN8Qjz1zf8FXulKGz3BgUnYf0PO3h4a JKuAHZHe9a2XC8kx2GoUrwD2rn4xlywONPou+iV30SNPsQydbKrX84yhfU40Q8bX90WH xN+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=RJp0QIeMwMACIOwlpVGkX8hiV1k/+hnJbL42uGwH3Is=; b=MNv+K8kAdpaV8fBTaK+NZA+GjS58pJQZDM8PZ0RBFqGVrhfWO27+Xh7LNYiRWAYdlh q4Ulwi6UWG33ZMpUfuIwkqiK1sjQdce9IczTmYxYbEmyIQnB3P1HjkLA0YjrbEk5j6s+ GRd/waiJdyeIB9NZKdTecYz6i+VI1B4LKwCWeA4Cs1i4Zg7SIyuUZKCE/XhJ5YxhC0fU jQ0rzJ7SRag9i6yZEGDooSVmfUodMym3bx92xsx8h/UpzcFMWjrMeVv7LkFd4QkIiqvt 7rm+ydSrB4uRlHVukpzAGtOpx/4y8CE/T1rvL/iJTb0nwVVld1QneDRwUlLuPpkKrxhB CMVw== X-Gm-Message-State: APjAAAXYpcAA9IeGDN001dmh1MEBhBeDo2/1MwYGIF0ymIEgKKA9T6IK gaqcfi60X/QWhwmtzljOO7jAz3nIKgWgQhXpOp7IuF8G X-Google-Smtp-Source: APXvYqwgUN1tD0iM+R4hEfDu53JkxWlPuSOkjxgChqvxnRqedHZB7enzHzqTuOa3Bk1Y6/ems9p7uIhdf38rlVT5do0= X-Received: by 2002:a67:fb50:: with SMTP id e16mr593768vsr.75.1573685478907; Wed, 13 Nov 2019 14:51:18 -0800 (PST) MIME-Version: 1.0 References: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> <275528bd-955d-5fe3-b093-d3d997f073fb@nomountain.net> In-Reply-To: <275528bd-955d-5fe3-b093-d3d997f073fb@nomountain.net> From: Brian Dickson Date: Wed, 13 Nov 2019 14:51:07 -0800 Message-ID: To: Melinda Shore Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000f56377059742332b" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 13 Nov 2019 22:51:26 -0000 --000000000000f56377059742332b Content-Type: text/plain; charset="UTF-8" On Wed, Nov 13, 2019 at 10:24 AM Melinda Shore wrote: > On 11/13/19 7:11 AM, Ben Schwartz wrote: > > Also, what is "full consensus", > > I got stuck on this one, as well. > > > I would define "full consensus" as the absence of any stated objection. > > Well ... I think that, in general, as individuals we're pretty terrible > about distinguishing between objections we can live with and objections > we cannot, and organizationally we're not getting much guidance from > chairs or ADs about this. > > I, too, have problems with this definition or understanding of the meaning. I was looking into where/how consensus is actually defined, if at all, in any of the relevant BCPs. (FYI, I see the relevant BCPs as BCP9, BCP25, BCP45, and BCP83.) The only place I could find that makes any specific distinction between "rough consensus" and absolute consensus is the Introduction of BCP83. There, it makes reference to "the lone voice of dissent", where it says: In other words, individual bad faith should not trump community goodwill. IMNSHO, any WG proposal should ensure it is consistent with this sentiment, regardless of how it is worded or how terms are defined. I also think it would be bad form to make assessments about what is or is not "bad faith", but rather stay consistent with how rough consensus is measured. (I.e. obstinance may not constitute bad faith, nor might philosophical objections, but either of those should not be allowed to trump significant levels of consensus.) The other things I noted in reading all those BCPs, is the areas of "professionalism", where the focus should be primary on technical issues. By its nature, some of these issues drift dangerously close to policy, but that does not mean that discussions regarding technical aspects of those should be off limits. We may disagree on policy, but those policy questions do need to be informed by the underlying technical issues, and settling the technical issues in some cases may make policy questions moot. Mootness should always be uncovered, so as to reduce the degree of contention. Anyway, that's the main thing I see as being relevant to the proposal. Brian P.S. I think that, prior to WG adoption, discussions about whether IDs might be suitable for adoption or relevant or ready, are perhaps not only premature, but inappropriate. My suggestion is to refrain from that area of discussion on an ID until the authors request adoption, at least on-list. Private off list feedback is always appropriate, of course. Anyway, I'd be careful about getting into a situation in which people > are working on something that's unlikely to progress, and the current > charter text implies that a working group, if chartered, might do that. > I could be wrong but I don't think I've seen any working group charter > before that said "This is in scope and we might work on it, but maybe > not." I think something a little crisper might help avoid getting into > a frustrating situation in which a few folks are fighting to progress > something that has little chance of success. > > Melinda > -- > Software longa, hardware brevis > > PGP key fingerprint 4F68 2D93 2A17 96F8 20F2 > 34C0 DFB8 9172 9A76 DB8F > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000f56377059742332b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 13, 2019 at 10:24 AM Meli= nda Shore <melinda.shore= @nomountain.net> wrote:
On 11/13/19 7:11 AM, Ben Schwartz wrote:
>=C2=A0 =C2=A0 =C2=A0Also, what is "full consensus",

I got stuck on this one, as well.

> I would define "full consensus" as the absence of any stated= objection.

Well ...=C2=A0 I think that, in general, as individuals we're pretty te= rrible
about distinguishing between objections we can live with and objections
we cannot, and organizationally we're not getting much guidance from chairs or ADs about this.


I, too, have problems with this defini= tion or understanding of the meaning.

I was lookin= g into where/how consensus is actually defined, if at all, in any of the re= levant BCPs.
(FYI, I see the relevant BCPs as BCP9, BCP25, BCP45,= and BCP83.)

The only place I could find that make= s any specific distinction between "rough consensus" and absolute= consensus is the Introduction of BCP83.
There, it makes referenc= e to "the lone voice of dissent", where it says:
In othe=
r words, individual bad faith should not trump
 =
  community goodwill.

IMNSHO, any WG proposal should ensure it is consist= ent with this sentiment, regardless of how it is worded or how terms are de= fined.=C2=A0
I also think it would be bad form to make assessment= s about what is or is not "bad faith", but rather stay consistent= with how rough consensus is measured.
(I.e. obstinance may not c= onstitute bad faith, nor might philosophical objections, but either of thos= e should not be allowed to trump significant levels of consensus.)

The other things I noted in reading all those BCPs, is the= areas of "professionalism", where the focus should be primary on= technical issues.
By its nature, some of these issues drift dang= erously close to policy, but that does not mean that discussions regarding = technical aspects of those should be off limits.

W= e may disagree on policy, but those policy questions do need to be informed= by the underlying technical issues, and settling the technical issues in s= ome cases may make policy questions moot.

Mootness= should always be uncovered, so as to reduce the degree of contention.

Anyway, that's the main thing I see as being relev= ant to the proposal.

Brian
P.S. I think = that, prior to WG adoption, discussions about whether IDs might be suitable= for adoption or relevant or ready, are perhaps not only premature, but ina= ppropriate. My suggestion is to refrain from that area of discussion on an = ID until the authors request adoption, at least on-list. Private off list f= eedback is always appropriate, of course.

Anyway, I'd be careful about getting into a situation in which people are working on something that's unlikely to progress, and the current charter text implies that a working group, if chartered, might do that.
I could be wrong but I don't think I've seen any working group char= ter
before that said "This is in scope and we might work on it, but maybe<= br> not."=C2=A0 I think something a little crisper might help avoid gettin= g into
a frustrating situation in which a few folks are fighting to progress
something that has little chance of success.

Melinda
--
Software longa, hardware brevis

PGP key fingerprint=C2=A0 4F68 2D93 2A17 96F8 20F2
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A034C0 DFB8 9172 9A76 DB8F

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000f56377059742332b-- From nobody Wed Nov 13 14:52:49 2019 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 754A7120096 for ; Wed, 13 Nov 2019 14:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Rc8teW0g; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oUc2Ewtc 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 y8m5eeLZlD9i for ; Wed, 13 Nov 2019 14:52:45 -0800 (PST) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C336120127 for ; Wed, 13 Nov 2019 14:52:45 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C087321240; Wed, 13 Nov 2019 17:52:44 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Wed, 13 Nov 2019 17:52:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=R 98EEteszQX9RU23O1YQwZQlmS8kdHalBCa5+Lp8Bio=; b=Rc8teW0gNNf8KcVJk aEnYlYg6AShjtvdPsjS0PFgAiWKmVK/070pmKWpNM4vT7KddxJv2TGd7XhSPxyVX UdNY8rR/40AnuAvIHhbrICoE+bdfp/kUNqzbA5ho7UgPYc6/Gftesskvr1U31eRw zXxKt2jaXJ37sTCIss+4w3Ow/sd+agtZR9yl+/79CWUz3bvkQe5SYvE4AIcsNAKC B2cb2Kh/tck9lwlJQDaxDxZAMp56YQLSr/VIVZcVbKsFYNL+Tlap/+FRwDJ2QJ/i Ge2alNIWGIyf1iIYxnCzrml+u0zgpJ/AwrIn0MAvKmqy28s05nq9XrMuWYrHJKFn E5/+A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=fm1; bh=R98EEteszQX9RU23O1YQwZQlmS8kdHalBCa5+Lp8B io=; b=oUc2EwtctAklCIqGauqYRfUvgwj7umW+NI3FFSL9pGZhhivlbYq5ytgAw J7YyDiWIYI9obUXC00mAHsOmxkdbys20VYTIKUjLUPEhWFc4OKUaaRSz1SYKvIE7 FS1owjYYBE08gaqZ9fFrsLNSq3orUVSPef9J25keNWkkcha7mc0QlrCys0B77RLC Aj6RNdZgo1VOtaQ5dS25c/wGfT7zQOtOfo9KoCh+VQ0jrrvoIUIyYc+z1bge7yKW qTtMgy3BRRPXGWZ7ZBZLgDEs3bW/NlXt/vRP17KhUPUOKUOmsgn21Q0f3ejv2ZCh 68r45U5kSJIwGLScSgRoojPhsm6cw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudefvddgtddvucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtvdenucfhrhhomhepofgrrhhk ucfpohhtthhinhhghhgrmhcuoehmnhhothesmhhnohhtrdhnvghtqeenucffohhmrghinh epmhhnohhtrdhnvghtnecukfhppeduudelrddujedrudehkedrvdehudenucfrrghrrghm pehmrghilhhfrhhomhepmhhnohhtsehmnhhothdrnhgvthenucevlhhushhtvghrufhiii gvpedt X-ME-Proxy: Received: from attitudadjuster.mnot.net (unknown [119.17.158.251]) by mail.messagingengine.com (Postfix) with ESMTPA id C76108005C; Wed, 13 Nov 2019 17:52:42 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) From: Mark Nottingham In-Reply-To: Date: Thu, 14 Nov 2019 09:52:39 +1100 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> References: To: "Dixon, Hugh" X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 13 Nov 2019 22:52:49 -0000 > On 13 Nov 2019, at 9:55 pm, Dixon, Hugh = wrote: >=20 > Some might like to think that "Pervasive Monitoring" is clear and = bold... >=20 > (from RFC7258): > "Pervasive Monitoring Is an Attack" >=20 > "Pervasive Monitoring (PM) is widespread (and often covert) > surveillance through intrusive gathering of protocol artefacts, > including application content, or protocol metadata such as = headers." >=20 > " While PM is an attack, other forms of monitoring that might fit the > definition of PM can be beneficial and not part of any attack, e.g., > network management functions monitor packets or flows and anti-spam > mechanisms need to see mail message content " >=20 > So ... > PM is an attack. Some PM is not an attack. PM is an attack. Other things might use the same mechanisms as PM for = benign purposes.=20 In an ideal world we'd disallow PM and allow benign purposes -- but in = many cases we can't distinguish them from an attack. We can find other = ways to achieve those goals using alternative mechanisms, but we can't = say "we won't protect against PM because doing so disables some useful = things." Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Nov 13 15:01:31 2019 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 4289A120831 for ; Wed, 13 Nov 2019 15:01:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 QCbRB4gMDwuC for ; Wed, 13 Nov 2019 15:01:27 -0800 (PST) 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 020C7120127 for ; Wed, 13 Nov 2019 15:01:27 -0800 (PST) Received: by mail-vs1-xe2e.google.com with SMTP id x21so2546213vsp.6 for ; Wed, 13 Nov 2019 15:01:26 -0800 (PST) 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=JMLeLoCG6Y4bfKjfiyPKrieBhK57Sk17dVL6jKl16sk=; b=AyXScrMWLzBkqG/oQ4A9V/wvSEVRsSmcsbwO5nfcDKzM3XspZSZBGrrNZHlDmRapzN m4LUOd0MAWscCdTUvaJxPo2ZviyMCFx4OwShE3aInsdL2TKIhkBPeNB0y11T/e7KSeyh MzAz4uCcH7fId0vzoc40ps3YY3q/i1wdUgZcUD6l0BJBSNiDa/Ueokcb5rvJevZqCZNA t/BkEMBBWNIl+czjPVXxGYs4cxZaBVncJMiMRVPudzyTE+F5rU01kqK107v5HHCf3T/w SIiJYDPXPoF+NY2FHfYhkgSlhKVXLUoi+1gRVgvqrYOGLVb+BMjCGkVAPCizN4ww5K1t I3cg== 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=JMLeLoCG6Y4bfKjfiyPKrieBhK57Sk17dVL6jKl16sk=; b=QA93fOLdD1QSP2/K0olBMO2ls75sJkjlLiLBL7YKzL4ng1EQFzOhJkkrb6zGhx7kIr 7aQjjyWAzi6mwxK93u+fDKxzRcOWgS1wbcqM7XQF26m2LHcxfYWy8wlJE34ftiVO7L7O ZDXkvBi535QxSykiYP/2/7Ih87TxmGk2SeJDbl8plFJpQE1ZZpKU7ZD2cpzBzdTkGuZQ UGZr5Yk0GPZDJw3pFIb82cCNvJrvK7jHm3cdwkK/nuQgAlHAoux3fB+6fgHLMZkwEA7N Ksbcin1ngzkK8pZa9JgHMPuPEvdB79eFCpv8/RW76AwvV4bm9DNC0e/6NJ8uPjGbtLIu sHSA== X-Gm-Message-State: APjAAAU1pgK9TqKPMwEemup7nJtu3Tx9k5KsNJEHVIDuzy+Bl1IbJPgh cvYsu7x7KMKN6dgxl/TyzkSbQ7sQQpDnJ3BtEkA= X-Google-Smtp-Source: APXvYqzUPVAmJa6oYgnCk/6kWGbkPq27efscqlpcNlRfUVbCGQLXQiu+OOboHWaKdXlhMMQt/R33mjDMC0VtEKyb/0c= X-Received: by 2002:a67:efd5:: with SMTP id s21mr3768657vsp.136.1573686085973; Wed, 13 Nov 2019 15:01:25 -0800 (PST) MIME-Version: 1.0 References: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> In-Reply-To: From: Brian Dickson Date: Wed, 13 Nov 2019 15:01:14 -0800 Message-ID: To: Ben Schwartz Cc: Mark Nottingham , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000247bcd05974258b0" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 13 Nov 2019 23:01:29 -0000 --000000000000247bcd05974258b0 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 13, 2019 at 8:12 AM Ben Schwartz wrote: > >> - Use of records from untrusted sources >> > I think this really needs more concise language on what is meant by this bullet point. E.g. - Is this referring to DNS responses that are not validated? - Or is this referring to DNS *records* provided by some source (e.g. a web server) that is not the DNS resolver in use? IMHO, the former would probably be okay to place outside normal discussion. However, IMNSHO, the latter should specifically be listed as something akin to "must be excluded from any WG work, except as authorized by prior approval by DNSOP WG, WG chairs, and AD", as this would massively impact the entirety of the Domain Name System, including security model, security, scaling, non-repudiation, etc, etc. Brian --000000000000247bcd05974258b0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 13, 2019 at 8:12 AM Ben S= chwartz <bemasc=3D40googl= e.com@dmarc.ietf.org> wrote:

- Use of records from untrusted sources

I think this really needs more concise language o= n what is meant by this bullet point.
E.g.=C2=A0
    Is this referring to DNS responses that are not validated?=C2=A0
  • = Or is this referring to DNS records=C2=A0provided by some source (e.= g. a web server) that is not the DNS resolver in use?
IMHO, t= he former would probably be okay to place outside normal discussion.
<= /div>

However, IMNSHO, the latter should specifically be= listed as something akin to "must be excluded from any WG work, excep= t as authorized by prior approval by DNSOP WG, WG chairs, and AD", as = this would massively impact the entirety of the Domain Name System, includi= ng security model, security, scaling, non-repudiation, etc, etc.
=
Brian
--000000000000247bcd05974258b0-- From nobody Wed Nov 13 15:07:47 2019 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 2D78C120837 for ; Wed, 13 Nov 2019 15:07:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6OJdUNjkOyiM for ; Wed, 13 Nov 2019 15:07:44 -0800 (PST) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 608241207FB for ; Wed, 13 Nov 2019 15:07:44 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 09E193740155; Wed, 13 Nov 2019 15:07:44 -0800 (PST) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id D37EA194D58F; Wed, 13 Nov 2019 16:07:43 -0700 (MST) Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id D2E98194D58E; Wed, 13 Nov 2019 16:07:43 -0700 (MST) From: Paul Ebersman To: Mark Nottingham cc: "Dixon, Hugh" , ADD Mailing list In-reply-to: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> Comments: In-reply-to Mark Nottingham message dated "Thu, 14 Nov 2019 09:52:39 +1100." X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71647.1573686463.1@fafnir.local> Date: Wed, 13 Nov 2019 16:07:43 -0700 Message-Id: <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 13 Nov 2019 23:07:46 -0000 mnot> PM is an attack. Other things might use the same mechanisms as PM mnot> for benign purposes. My take from RFC 7258 is that the key differentiator is user knowledge and/or consent, i.e. if the user is not aware they are being monitored and/or has not consented explicitly to altered data (in this case DNS answers), that is what RFC 7258 considers an attack. In the use case of DNS filtering, if the user is both aware of the alteration of DNS answers (and why/how they might be altered) and has consented via opt-in, that is a *service*, not an attack. mnot> In an ideal world we'd disallow PM and allow benign purposes -- mnot> but in many cases we can't distinguish them from an attack. We can mnot> find other ways to achieve those goals using alternative mnot> mechanisms, but we can't say "we won't protect against PM because mnot> doing so disables some useful things." I would agree that we shouldn't disallow techniques that prevent PM. But we also shouldn't design techniques that users can't choose to disable. If we don't allow things like DNS filtering for users who actually have knowledge of and consent to, we become the authoritarians we're trying to protect users from. From nobody Wed Nov 13 15:09:00 2019 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 8FF48120831 for ; Wed, 13 Nov 2019 15:08:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 AJGvctTbXndp for ; Wed, 13 Nov 2019 15:08:54 -0800 (PST) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 93EA91207FB for ; Wed, 13 Nov 2019 15:08:54 -0800 (PST) Received: by mail-ua1-x936.google.com with SMTP id l38so1260303uad.4 for ; Wed, 13 Nov 2019 15:08:54 -0800 (PST) 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=gJqmcotYo/OWK+y5qZKbnyAkLV281PxpJTtB1ba8YPg=; b=mg/A9sJn6mQBIgbWjqYdxLSpEjvTLVFxS/56rd0lFQAzYRGnL96MRJRuadgXFZwAGd JIQ935kOjxYbzgrz6s0zaZxAebS8YvY99GLQg7StJ+NOEb3uxlceEjjlia7mFbuXDrNJ TUi43cLME3OkR1LojuREMjBg95kcRHrogNkYAYhQMcla3Y8G23689MALFYqHZn44D0K3 CGrTAKaS6AW511LPRmvsGr3DGGY6tYQoTRBP8YVxSsgUqWW5Se0rPiY8JaNhitff2uQZ KOjvs+XmaMAgEt0LAY/ACtRPgeiw4suwFt1t1cZlG2LCar+EfQ05GHv+lv746/s2tLqx QBYw== 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=gJqmcotYo/OWK+y5qZKbnyAkLV281PxpJTtB1ba8YPg=; b=bRxd+D2lWAsPlJY8qqC4HwEWeJhfQBuX8YEbypis0XhR0vdRebM3aSb7OVlVUkYSI+ uys4Rwrf1gFizEOcohzUePfEEMIx0EWBV37I1iW8CUQC0ZDlPx+5JyaU7fc7W+xSXLiW WJzqW66aI0R8YYndmAcv535mnJPlp2ifUZAwL0gFJm2NnriBSQckGP8kx6Ymwey17jLU spQyBZozEab6dLsYgwIG9YjnHHCL+bEArKZRHPtlkQuBj2wn16t2zm5nwqeQvRSyCQTV 2QRTjGhLA7AXvkw3X3fhFPpg97EYz2dKT09fMvaZp0iHtw436gWtN4L0I5TxRfHGBRNJ ba3A== X-Gm-Message-State: APjAAAVtcm8+tmQaozJ/cwJBynKrje36jA1EIwXEy1ChGVkg81UXKRvN 9MUhewFXYK5NrnRcsZMfuy77YgGVdKqzg9LZ9co= X-Google-Smtp-Source: APXvYqzvP7vupkGPnrEy7zeNSvpOc5wsj+NqWRFO9U+Q6fItqEXG22nKuy9w2P1JZ4os8XxOGUc2Wmd1oJKTyEFUtQ0= X-Received: by 2002:a9f:376b:: with SMTP id a40mr3719140uae.48.1573686533397; Wed, 13 Nov 2019 15:08:53 -0800 (PST) MIME-Version: 1.0 References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> In-Reply-To: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> From: Brian Dickson Date: Wed, 13 Nov 2019 15:08:42 -0800 Message-ID: To: Mark Nottingham Cc: "Dixon, Hugh" , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000cfa150059742726f" Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 13 Nov 2019 23:08:58 -0000 --000000000000cfa150059742726f Content-Type: text/plain; charset="UTF-8" On Wed, Nov 13, 2019 at 2:52 PM Mark Nottingham wrote: > > > > On 13 Nov 2019, at 9:55 pm, Dixon, Hugh 40sky.uk@dmarc.ietf.org> wrote: > > > > Some might like to think that "Pervasive Monitoring" is clear and bold... > > > > (from RFC7258): > > "Pervasive Monitoring Is an Attack" > > > > "Pervasive Monitoring (PM) is widespread (and often covert) > > surveillance through intrusive gathering of protocol artefacts, > > including application content, or protocol metadata such as headers." > > > > " While PM is an attack, other forms of monitoring that might fit the > > definition of PM can be beneficial and not part of any attack, e.g., > > network management functions monitor packets or flows and anti-spam > > mechanisms need to see mail message content " > > > > So ... > > PM is an attack. Some PM is not an attack. > > PM is an attack. Other things might use the same mechanisms as PM for > benign purposes. > > In an ideal world we'd disallow PM and allow benign purposes -- but in > many cases we can't distinguish them from an attack. We can find other ways > to achieve those goals using alternative mechanisms, but we can't say "we > won't protect against PM because doing so disables some useful things." > > I think there is an enormous difference between saying "We won't protect against PM", and "We won't do X as a way to protect against PM". In other words, the argument regarding "PM or benign" should not be sufficient, by itself, to justify the specific choice(s) of how to avoid PM. If either of X or Y protect against PM, if we all agree that protection against PM is a core requirement, then reaching rough consensus on X vs Y should be done on technical merits, in a professional manner. We can agree on protection against PM, even if we disagree on the mechanisms. We should all agree up front, that disagreeing on the "how" with no quarter given in the disagreement, would have the unwanted consequence of not allowing adoption of any method of avoiding PM, and as such, should inform discussion and consensus-reaching. Brian --000000000000cfa150059742726f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 13, 2019 at 2:52 PM Mark = Nottingham <mnot@mnot.net> wrote= :


> On 13 Nov 2019, at 9:55 pm, Dixon, Hugh <Hugh.Dixon=3D40sky.uk@dmarc.ietf.org= > wrote:
>
> Some might like to think that "Pervasive Monitoring" is clea= r and bold...
>
> (from RFC7258):
> "Pervasive Monitoring Is an Attack"
>
> "Pervasive Monitoring (PM) is widespread (and often covert)
>=C2=A0 =C2=A0surveillance through intrusive gathering of protocol artef= acts,
>=C2=A0 =C2=A0including application content, or protocol metadata such a= s headers."
>
> " While PM is an attack, other forms of monitoring that might fit= the
>=C2=A0 =C2=A0definition of PM can be beneficial and not part of any att= ack, e.g.,
>=C2=A0 =C2=A0network management functions monitor packets or flows and = anti-spam
>=C2=A0 =C2=A0mechanisms need to see mail message content "
>
> So ...
> PM is an attack.=C2=A0 Some PM is not an attack.

PM is an attack. Other things might use the same mechanisms as PM for benig= n purposes.

In an ideal world we'd disallow PM and allow benign purposes -- but in = many cases we can't distinguish them from an attack. We can find other = ways to achieve those goals using alternative mechanisms, but we can't = say "we won't protect against PM because doing so disables some us= eful things."


I think there is= an enormous difference between saying "We won't protect against P= M", and "We won't do X as a way to protect against PM".<= /div>

In other words, the argument regarding "PM or= benign" should not be sufficient, by itself, to justify the specific = choice(s) of how to avoid PM. If either of X or Y protect against PM, if we= all agree that protection against PM is a core requirement, then reaching = rough consensus on X vs Y should be done on technical merits, in a professi= onal manner.

We can agree on protection against PM= , even if we disagree on the mechanisms. We should all agree up front, that= disagreeing on the "how" with no quarter given in the disagreeme= nt, would have the unwanted consequence of not allowing adoption of any met= hod of avoiding PM, and as such, should inform discussion and consensus-rea= ching.

Brian=C2=A0
--000000000000cfa150059742726f-- From nobody Wed Nov 13 15:14:26 2019 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 5AFF6120837 for ; Wed, 13 Nov 2019 15:14:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 JdzFaiMh_tMK for ; Wed, 13 Nov 2019 15:14:21 -0800 (PST) Received: from NAM06-BL2-obe.outbound.protection.outlook.com (mail-eopbgr650101.outbound.protection.outlook.com [40.107.65.101]) (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 0AED512004E for ; Wed, 13 Nov 2019 15:14:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ffawXnauduoTVh4mrcBhpPzXgBPGQHIHtgfcOuly4SoGWRp/hRWBZmATVpNV2oaReWvHSAFjKyfU+2NJoz012ZKF88mPYTgGSgUafFqJdBZmyx4uC/W+8/lc26XkFPe9QGnRH7aA391EmP9LcEMFzRCbYmlLr69trLMmg9CfdugtTK7U9mzoIbD3y3q/iwZKlm4VBUVBpsovnVuWMXfs8NEDU+asSx7D0GaR+up++Oi85nVhfzlpEb94h74A44RzdO0VCtNJZgafXbyAThLiJCcqV7lFm5OZru/r/odxbtLeJRC7vqAsNPJTb0T2kWeUsVzEOLqZWJaqngaU2z019A== 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=KN+XMEfNr7GBpm1iM+U71n4dounuT86uixj6rHOBBqw=; b=Cr5bi1470uQPLyMPVbrrdnvPB56yeOgkZ2aDxxjzl0MgoNSdsLo6Na2ybElDQwmPnelb7VkdAICCdhefd/ta5lLnDinun/hDgRvhG3caTNSkL6rrt/TJEXSZMFtB66/uh93frDCrWuxh0eSes/THtRsYBfM1Uvazid3mLA4ljbtvDYsFWoXbh5vWXfSGPWBWfZueVAsbioH0wlAr3v+Fex6DldKe+/LmuGstAifIQK32snB+LknXp6wM59giJsbR1mOHk116zAUcw8Xhx0A3BCUxRbRJYFP2FvX7cHKK7BEaDUmMn6DQ//qrb+IA/xkVotqD6i1TMIbG9W+jC+zBZQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KN+XMEfNr7GBpm1iM+U71n4dounuT86uixj6rHOBBqw=; b=StXbkwakea50Qne2SZrXwIf3yE/5jmw6CV272ebXk4MRmTIhNPfGrO1hv62CrvMbalJyaRxZHSR+NRUwnXImQdZwuqOVG4sahtv9p4+8FzaSkWwH6D/6AaVufwUyxnHYxmWmdEKotIN6d4uK4TgZhYAlrCEkhlHmBTMKFFN2leE= Received: from SN2PR00MB0080.namprd00.prod.outlook.com (10.167.20.148) by SN2PR00MB0191.namprd00.prod.outlook.com (10.167.18.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2485.0; Wed, 13 Nov 2019 23:14:18 +0000 Received: from SN2PR00MB0080.namprd00.prod.outlook.com ([fe80::5c81:d470:1548:4765]) by SN2PR00MB0080.namprd00.prod.outlook.com ([fe80::5c81:d470:1548:4765%3]) with mapi id 15.20.2491.000; Wed, 13 Nov 2019 23:14:18 +0000 From: Tommy Jensen To: Paul Ebersman , Mark Nottingham CC: "Dixon, Hugh" , ADD Mailing list Thread-Topic: [Add] ABCD BoF agenda items, pervasive monitoring and privacy Thread-Index: AQHVmhDS96z9Z8gdakCqsARxecCtqKeJtfeAgAAENoCAAACxmA== Date: Wed, 13 Nov 2019 23:14:18 +0000 Message-ID: References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net>, <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> In-Reply-To: <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-11-13T23:14:17.219Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jensen.Thomas@microsoft.com; x-originating-ip: [2001:4898:80e8:f:8991:1ed8:848c:7985] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 4f4fc790-82f3-4140-c082-08d7688f3598 x-ms-traffictypediagnostic: SN2PR00MB0191: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0220D4B98D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(136003)(39860400002)(366004)(199004)(189003)(86362001)(2906002)(8676002)(99286004)(66446008)(236005)(22452003)(81156014)(10090500001)(81166006)(55016002)(52536014)(476003)(11346002)(8936002)(25786009)(606006)(4326008)(446003)(6306002)(105004)(6436002)(66556008)(64756008)(5660300002)(71190400001)(54896002)(256004)(66476007)(71200400001)(9686003)(76116006)(229853002)(6116002)(53546011)(6506007)(7696005)(10290500003)(486006)(8990500004)(102836004)(46003)(186003)(6246003)(74316002)(478600001)(966005)(7736002)(110136005)(76176011)(66946007)(54906003)(19627405001)(33656002)(14454004)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN2PR00MB0191; H:SN2PR00MB0080.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: IIfUTZIaBmzvqRuoLnUvB2Q/4NIIvIhiQSGLI3pDmZ4ke0n0DaUWHztM0NHLK2pitDPBVRm/MbADkO3Tx9jbz5lBpyncjxxQ18KpiN6zld/LSrzkzHiFi1tVE+7sXkvqPhREvBMVYYq/LMrey4gY1x8tGqjYuoyvb90UINHHINR8f4GJBx52+2CXhaNFwQDc8381v2ZKgqloLuiC+fGECELvlTrHhHe7SurgMj20TmY+7ei3YTd5X1j8S+uGx/73xqNSKB2nbAcSbE7yMpV3iNtGfq+8ALeaGtkksyHfX5WyOtJWd80z1ZCIZlwLh0xNfDc2h8zwjIEOFXCnuP3ts2RDPmhL8/UBMXTizAGvQqE7IfYKGw1eHy1yzP0fSM0S8PIqKuuBtRbQZAI1EVv1vKaj3f7eP0ZfTmJiPspIEEA4CF0Isqau/bhtQTAYBpZY x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_SN2PR00MB00805E5BFAF8AD92C7815FCAFA760SN2PR00MB0080namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f4fc790-82f3-4140-c082-08d7688f3598 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2019 23:14:18.3090 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: F6RqkEVAZWWV3gv8NVzOBB6AB/1rhhRsICT7W6fQlnjYy1Zlj9wvqIR1OFCQjSmSOusoVX52KbT+6ejOvYRs3A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN2PR00MB0191 Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 13 Nov 2019 23:14:24 -0000 --_000_SN2PR00MB00805E5BFAF8AD92C7815FCAFA760SN2PR00MB0080namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable paul> I would agree that we shouldn't disallow techniques that prevent PM. = But we also shouldn't design techniques that users can't choose to disable. If we don't allow things like DNS filtering for users who actually have knowledge of and consent to, we become the authoritarians we're trying to protect users from. I agree. This to me leads us to transparency and configuration requirements= for apps and platforms offering DNS services rather than requirements on t= he protocols apps and platforms use to perform DNS queries. Not sure if it'= s within scope of this WG or not (nor do I care to wade those waters), but = it seems the question of "how do we ensure we're not preventing users from = having control over their DNS traffic?" should be answered at the device le= vel and not the network level because of the point made earlier: once bits = are on the wire, it's impossible to distinguish between an attack and "appr= oved administration" when those bits are manipulated. Better to emit bits i= n the manner the user intended in the first place. Thanks, Tommy ________________________________ From: Add on behalf of Paul Ebersman Sent: Wednesday, November 13, 2019 3:07 PM To: Mark Nottingham Cc: Dixon, Hugh ; ADD Mailing list Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy mnot> PM is an attack. Other things might use the same mechanisms as PM mnot> for benign purposes. My take from RFC 7258 is that the key differentiator is user knowledge and/or consent, i.e. if the user is not aware they are being monitored and/or has not consented explicitly to altered data (in this case DNS answers), that is what RFC 7258 considers an attack. In the use case of DNS filtering, if the user is both aware of the alteration of DNS answers (and why/how they might be altered) and has consented via opt-in, that is a *service*, not an attack. mnot> In an ideal world we'd disallow PM and allow benign purposes -- mnot> but in many cases we can't distinguish them from an attack. We can mnot> find other ways to achieve those goals using alternative mnot> mechanisms, but we can't say "we won't protect against PM because mnot> doing so disables some useful things." I would agree that we shouldn't disallow techniques that prevent PM. But we also shouldn't design techniques that users can't choose to disable. If we don't allow things like DNS filtering for users who actually have knowledge of and consent to, we become the authoritarians we're trying to protect users from. -- Add mailing list Add@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fadd&data=3D02%7C01%7CJensen.Thomas%40micro= soft.com%7C8fac04dc07c5437deecf08d7688e4f63%7C72f988bf86f141af91ab2d7cd011d= b47%7C1%7C0%7C637092832744031387&sdata=3DCjr3cpbLgvnSGwQyE9P2IQkOOYb3L8= hjYgLpHqtzPJ4%3D&reserved=3D0 --_000_SN2PR00MB00805E5BFAF8AD92C7815FCAFA760SN2PR00MB0080namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
paul> I would agree that we shouldn't disallow techniques that prevent PM. But
we also shouldn't design techniques that users can't choose to
disable. If we don't allow things like DNS filtering for users who
actually have knowledge of and consent to, we become the authoritarians
we're trying to protect users from.

I agree. This to me leads us to transparency and configuration requirements = for apps and platforms offering DNS services rather than requirements on th= e protocols apps and platforms use to perform DNS queries. Not sure if it's= within scope of this WG or not (nor do I care to wade those waters), but it seems the question of "h= ow do we ensure we're not preventing users from having control over their D= NS traffic?" should be answered at the device level and not the networ= k level because of the point made earlier: once bits are on the wire, it's impossible to distinguish between an attac= k and "approved administration" when those bits are manipulated. = Better to emit bits in the manner the user intended in the first place.

Thanks,
Tommy
 
From: Add <add-bounces@i= etf.org> on behalf of Paul Ebersman <list-add@dragon.net>
Sent: Wednesday, November 13, 2019 3:07 PM
To: Mark Nottingham <mnot@mnot.net>
Cc: Dixon, Hugh <Hugh.Dixon=3D40sky.uk@dmarc.ietf.org>; ADD Ma= iling list <add@ietf.org>
Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and p= rivacy
 
mnot> PM is an attack. Other things might use t= he same mechanisms as PM
mnot> for benign purposes.

My take from RFC 7258 is that the key differentiator is user knowledge
and/or consent, i.e. if the user is not aware they are being monitored
and/or has not consented explicitly to altered data (in this case DNS
answers), that is what RFC 7258 considers an attack.

In the use case of DNS filtering, if the user is both aware of the
alteration of DNS answers (and why/how they might be altered) and has
consented via opt-in, that is a *service*, not an attack.

mnot> In an ideal world we'd disallow PM and allow benign purposes -- mnot> but in many cases we can't distinguish them from an attack. We can=
mnot> find other ways to achieve those goals using alternative
mnot> mechanisms, but we can't say "we won't protect against PM bec= ause
mnot> doing so disables some useful things."

I would agree that we shouldn't disallow techniques that prevent PM. But we also shouldn't design techniques that users can't choose to
disable. If we don't allow things like DNS filtering for users who
actually have knowledge of and consent to, we become the authoritarians
we're trying to protect users from.

--
Add mailing list
Add@ietf.org
https://nam06.saf= elinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmailman%2= Flistinfo%2Fadd&amp;data=3D02%7C01%7CJensen.Thomas%40microsoft.com%7C8f= ac04dc07c5437deecf08d7688e4f63%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7= C637092832744031387&amp;sdata=3DCjr3cpbLgvnSGwQyE9P2IQkOOYb3L8hjYgLpHqt= zPJ4%3D&amp;reserved=3D0
--_000_SN2PR00MB00805E5BFAF8AD92C7815FCAFA760SN2PR00MB0080namp_-- From nobody Wed Nov 13 15:32:30 2019 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 48DA8120842 for ; Wed, 13 Nov 2019 15:32:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhKwalPyTSid for ; Wed, 13 Nov 2019 15:32:26 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 82C1A120837 for ; Wed, 13 Nov 2019 15:32:26 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EC9ABBE39; Wed, 13 Nov 2019 23:32:22 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LULsptCUymq8; Wed, 13 Nov 2019 23:32:21 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 6A111BE2E; Wed, 13 Nov 2019 23:32:21 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1573687941; bh=CQmrGl0uryAeBRh7eIAdEsGxE07x/mLEO72JwLfhLVE=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=uQjbNHrxzfIsZrICNDg2T1bRQUnzbP3r5g3MOV7LcZkADl6BQ7aYWT2XFvanHoKfv +yW6ssXHLdPRebSlXBYnxLo2tE6BlJm+1UZRO77/n1/UAa5pp5TMVixt6OEtaCScBc 3cjxAA5Z3kMhFwmYBXqHpI2BxALGCVAwTP3aM+qM= To: Paul Ebersman , Mark Nottingham Cc: "Dixon, Hugh" , ADD Mailing list References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: <66b22db0-dd35-e0c0-14c4-c7bd7cbb7a0d@cs.tcd.ie> Date: Wed, 13 Nov 2019 23:32:20 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="kGFxEIj6FpEiI2pM652x2oKrLZu7ZnqoD" Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 13 Nov 2019 23:32:28 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kGFxEIj6FpEiI2pM652x2oKrLZu7ZnqoD Content-Type: multipart/mixed; boundary="cm4drlofbtc3QwPYVZCp7JM92zdM5vrt6"; protected-headers="v1" From: Stephen Farrell To: Paul Ebersman , Mark Nottingham Cc: "Dixon, Hugh" , ADD Mailing list Message-ID: <66b22db0-dd35-e0c0-14c4-c7bd7cbb7a0d@cs.tcd.ie> Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> In-Reply-To: <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> --cm4drlofbtc3QwPYVZCp7JM92zdM5vrt6 Content-Type: multipart/mixed; boundary="------------78EB46DF3E880BE01640CC92" Content-Language: en-US This is a multi-part message in MIME format. --------------78EB46DF3E880BE01640CC92 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 13/11/2019 23:07, Paul Ebersman wrote: > My take from RFC 7258 is that the key differentiator is user knowledge > and/or consent, i.e. if the user is not aware they are being monitored > and/or has not consented explicitly to altered data (in this case DNS > answers), that is what RFC 7258 considers an attack. FWIW, I don't agree. First, what passes for "consent" in computing in general is not what I would call consent, as understood in more mature fields such as medicine, so I would not myself accept so-called "consent" as a get out of jail card in this nor any other Internet context. I don't claim that everyone would agree with that but that's ok, because... Second, the term "consent" doesn't occur in 7258. So I don't think you have any real basis claim that 7258 is anything to do with that risible (as used in computing) abuse of terminology. (IIRC there are about 1000 mails in the archive of ietf@ietf discussing the draft that became 7258, so feel free to delve into those to see if you find some backing for what you say above, but TBH I don't recall that being discussed particularly.) Thirdly, user knowledge does not make PM a non-attack. We know that PM is being done still, but it remains an attack. Cheers, S. PS: The above says nothing about whether net-nanny type DNS stuff is good nor bad, I'm only disagreeing with your characterisation of PM and 7258. --------------78EB46DF3E880BE01640CC92 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------78EB46DF3E880BE01640CC92-- --cm4drlofbtc3QwPYVZCp7JM92zdM5vrt6-- --kGFxEIj6FpEiI2pM652x2oKrLZu7ZnqoD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3MkoQACgkQWrL68XsX K+pSBg/+Orjn3/jbrgXuoJ6B7Oav6I3hpCYY5Ka/iYwVJh7kg+HBqPrsFrTQU29M M1Q9ipBrmR6XPo4fa7O4nvI+moXT06Go30EVJz3P2IOc1tTXncHKJUXuAGcCktEe MAOHyyDkbHUayseJPX2j/JFYDg900vdLVAAnwvi9f3xl+owXWdKpVkIDyOfnVP2p 0RJZYGWKR6UT90Z6fe/R7NMvMpirESoiQEX76ai5p8MQqCjlbaOIy2SOQGnqdKZ6 rBt7KG/udzeumSPMZz3iI6btgz7v1ZOBvgINNTSYBHV0Yky6xIdPwsI+MS4tegko 4EaTFM/UGQXiwPE2yr16EewMN8QRgO1eRwpyhxFcN4zXToiRVcseObxhOQsUcKml Swn7YBaJMqTJAQQFWVIXAt8kbyr7cwJrOzDugBJ/G3x4NbW/Z/uyRaN888wbejG9 jf+B6vCRMbYjHqmMWy3jWTln1TkIoii+K52TfRcq+Tu+mjlO4WS/LrZIq7DjWX+/ iYvukKiRfscQEc+z0Q/Ue54nRk8833TCfX5f/7CkaWoQ16NCOwAfqOBg7EtvYti/ rrBxQk55IaTLjUlqrFX/HR1ZwQjxZkHiQai1Cg/mErACJKCWkftKKkB/6VT2MZV8 moFLa2sFuPXHo6ORpH/iFry/7BL559v/LRU2zKAAUWydXZK0wLw= =4b8c -----END PGP SIGNATURE----- --kGFxEIj6FpEiI2pM652x2oKrLZu7ZnqoD-- From nobody Wed Nov 13 15:33:47 2019 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 386AF120837 for ; Wed, 13 Nov 2019 15:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 F3aDQnnR8Jlb for ; Wed, 13 Nov 2019 15:33:43 -0800 (PST) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A506A120089 for ; Wed, 13 Nov 2019 15:33:43 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 721B93740155; Wed, 13 Nov 2019 15:33:43 -0800 (PST) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 45F63194D856; Wed, 13 Nov 2019 16:33:43 -0700 (MST) Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 4529A194D855; Wed, 13 Nov 2019 16:33:43 -0700 (MST) From: Paul Ebersman To: Tommy Jensen cc: ADD Mailing list In-reply-to: References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net>, <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> Comments: In-reply-to Tommy Jensen message dated "Wed, 13 Nov 2019 23:14:18 +0000." X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72230.1573688023.1@fafnir.local> Date: Wed, 13 Nov 2019 16:33:43 -0700 Message-Id: <20191113233343.45F63194D856@fafnir.remote.dragon.net> Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 13 Nov 2019 23:33:45 -0000 tjensen> I agree. This to me leads us to transparency and configuration tjensen> requirements for apps and platforms offering DNS services tjensen> rather than requirements on the protocols apps and platforms tjensen> use to perform DNS queries. Not sure if it's within scope of tjensen> this WG or not (nor do I care to wade those waters), but it tjensen> seems the question of "how do we ensure we're not preventing tjensen> users from having control over their DNS traffic?" should be tjensen> answered at the device level and not the network level because tjensen> of the point made earlier: once bits are on the wire, it's tjensen> impossible to distinguish between an attack and "approved tjensen> administration" when those bits are manipulated. Better to emit tjensen> bits in the manner the user intended in the first place. Agreed. Intent (particularly user intent) is most easily discerned in the end user device. I'm far more worried about my OS and applications leaking things than the network I'm on, as I have less options to see or control OS/app (other than not using them). This seems like something worth discussing in docs in this WG. From nobody Wed Nov 13 15:41:00 2019 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 43047120848 for ; Wed, 13 Nov 2019 15:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GBsI7iBRD0nl for ; Wed, 13 Nov 2019 15:40:53 -0800 (PST) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65CEA12004E for ; Wed, 13 Nov 2019 15:40:53 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id D04BF3740155; Wed, 13 Nov 2019 15:40:52 -0800 (PST) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id A7D14194D8ED; Wed, 13 Nov 2019 16:40:52 -0700 (MST) Received: from fafnir.local (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id A740B194D8EC; Wed, 13 Nov 2019 16:40:52 -0700 (MST) From: Paul Ebersman To: Stephen Farrell cc: ADD Mailing list In-reply-to: <66b22db0-dd35-e0c0-14c4-c7bd7cbb7a0d@cs.tcd.ie> References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> <66b22db0-dd35-e0c0-14c4-c7bd7cbb7a0d@cs.tcd.ie> Comments: In-reply-to Stephen Farrell message dated "Wed, 13 Nov 2019 23:32:20 +0000." X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <72476.1573688452.1@fafnir.local> Date: Wed, 13 Nov 2019 16:40:52 -0700 Message-Id: <20191113234052.A7D14194D8ED@fafnir.remote.dragon.net> Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 13 Nov 2019 23:40:55 -0000 sfarrell> First, what passes for "consent" in computing in general is sfarrell> not what I would call consent, as understood in more mature sfarrell> fields such as medicine, so I would not myself accept sfarrell> so-called "consent" as a get out of jail card in this nor any sfarrell> other Internet context. I don't claim that everyone would sfarrell> agree with that but that's ok, because... Will concede consent is a mess. Steve Bellovin's plenary was massively depressing in that regard, moreso if you delve into the references behind it. sfarrell> Thirdly, user knowledge does not make PM a non-attack. sfarrell> We know that PM is being done still, but it remains an sfarrell> attack. [...] sfarrell> PS: The above says nothing about whether net-nanny type sfarrell> DNS stuff is good nor bad, I'm only disagreeing with your sfarrell> characterisation of PM and 7258. Here I'll disagree. If I know something is happening and I want it to happen, it's not an attack. I'll take the clarification that it requires both, since knowledge without consent is still potentially an attack. If I remove a file from my hard disk and I do that deliberately, that's a "feature". If malware removes a file and I didn't want that to happen, that's an "attack". Calling anything that removes a file an attack is a sloppy problem statement. From nobody Wed Nov 13 15:43:03 2019 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 9B79E12087B for ; Wed, 13 Nov 2019 15:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 cFj3IH2fssA7 for ; Wed, 13 Nov 2019 15:42:58 -0800 (PST) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 094B612004E for ; Wed, 13 Nov 2019 15:42:58 -0800 (PST) Received: by mail-vk1-xa31.google.com with SMTP id l5so1027991vkb.4 for ; Wed, 13 Nov 2019 15:42:57 -0800 (PST) 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=WqRBvc/iGZQL537RJMrl/RSjsO2utMNMOHa9ASHJQaE=; b=MZ1F8jroxcPWbzgCmFFEs4RcVY38OGAq81z3iR2axar8frZgmI5ZY6RS4rDvlJkL15 7kZ6gBsTww3VzlAFSNREkCGwP7tc9pbkTjFx88xMcY6/uJ82YjqdXht0Y+fGRCvVj+aN 4e9uzSlp28Ep9HZfiGniTNIHUpNUi2FNhRC7UIBsi8oiTpLJ5AHq/Mzy+YZOFTilu3iZ u2cgIgtOaqrG1ew4/x0z9+Bv6s5rcgMOChpE/WcyWEs8F9olLjifphc86EqHge5941/e 53vkp4pXBllkRWChbhsEapjwcMB0N69tUdGukEu5J4+9AOr/t1gqXXZUH4YU3TXQ2us3 U8rw== 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=WqRBvc/iGZQL537RJMrl/RSjsO2utMNMOHa9ASHJQaE=; b=UTku8ZU0bzfvBP4b5XcI8yN3XglTYU0I69i4N4a6CH+rxJjrWrhc2vHStjnK/VTyKf ZF0N4d+g8D/lg/xCHvJTIYTJ5jActAp2n0pHRO2PM78CHE2Mnn7pLEy/TU44GqMD3i/g 1flJ+NvTAmxnp0RvySUyo02FJBWERTTl41StEYtNtp+I/JQbndD59Ics6efoKcNnQ1v5 /H8MAhM1lo4xYJ5TWGuLpxV/pHOsSatlBhbYPoVY55kzkxsT3yC7ToBlBvxgDBhzulYT lVkS+nvFMDkQ7PlhdDW01laNRxTOEDp+c/8LsR6FILZatO1hqu5mr85RR030tqEk0AJ0 yn6Q== X-Gm-Message-State: APjAAAVcQD5NOb8tf+ND7Hy1yFFm/hbZlS6gR1+P1u9z5qOkkJgdFxd1 FREDkS4J/UJWptA7oNqstmqHhbEVYgaDCPvinqnP2A== X-Google-Smtp-Source: APXvYqze3ILGUZTYjvc3PoCYrY3jTCJ4cy3/614zXFARqEM5rBZ6VsxhxtmyHRZhmeMk9yY1Ojrk5Xt4zZQ1uodb91g= X-Received: by 2002:a1f:5787:: with SMTP id l129mr3499235vkb.41.1573688576912; Wed, 13 Nov 2019 15:42:56 -0800 (PST) MIME-Version: 1.0 References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> In-Reply-To: From: Brian Dickson Date: Wed, 13 Nov 2019 15:42:45 -0800 Message-ID: To: Tommy Jensen Cc: Paul Ebersman , Mark Nottingham , "Dixon, Hugh" , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000009d3216059742ec9c" Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 13 Nov 2019 23:43:02 -0000 --0000000000009d3216059742ec9c Content-Type: text/plain; charset="UTF-8" On Wed, Nov 13, 2019 at 3:14 PM Tommy Jensen wrote: > paul> I would agree that we shouldn't disallow techniques that prevent > PM. But > we also shouldn't design techniques that users can't choose to > disable. If we don't allow things like DNS filtering for users who > actually have knowledge of and consent to, we become the authoritarians > we're trying to protect users from. > > I agree. This to me leads us to transparency and configuration > requirements for apps and platforms offering DNS services rather than > requirements on the protocols apps and platforms use to perform DNS queries. > > Not sure if it's within scope of this WG or not (nor do I care to wade > those waters), but it seems the question of "how do we ensure we're not > preventing users from having control over their DNS traffic?" should be > answered at the device level and not the network level because of the point > made earlier: once bits are on the wire, it's impossible to distinguish > between an attack and "approved administration" when those bits are > manipulated. Better to emit bits in the manner the user intended in the > first place. > We should be careful about distinguishing "what is currently the case" from "what is possible", and avoid ruling out entire paths of exploration/development based on possibly erroneous assumptions. Let me provide a hypothetical counter-example to the assertion that is not possible (to distinguish an attacker manipulating DNS responses, from a known party manipulating DNS responses). Suppose a known party, with whom the client has a relationship, uses DNSSEC (or other cryptographic signature mechanism) to sign the manipulated responses. Suppose the client has installed some manner of validating cryptographic object, such as a DNSSEC Trust Anchor. The nature of public key cryptography is that only the party that possesses the private key can generate such a signature. If the recipient has the corresponding public key, and trusts it, it is possible to distinguish the two situations, attacker vs known party. This does not specifically mandate a particular solution to the problem, but it DOES demonstrate that a solution to the problem is possible (and feasible and capable of being operated at scale, etc.) Brian --0000000000009d3216059742ec9c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 13, 2019 at 3:14 PM Tommy= Jensen <Jensen.Thomas=3D40microsoft.com@dmarc.ietf.org> wrote:
paul>=C2=A0I would agree that we shouldn't disallow techniques that prevent PM. But=
we also shouldn't design techniques that users can't choose to=
disable. If we don't allow things like DNS filtering for users who
actually have knowledge of and consent to, we become the authoritarians
we're trying to protect users from.

I agree. This to me leads us to transparency and configuration requirements = for apps and platforms offering DNS services rather than requirements on th= e protocols apps and platforms use to perform DNS queries.
=C2=A0
Not sure if it's within scope of this WG o= r not (nor do I care to wade those waters), but it seems the question of "h= ow do we ensure we're not preventing users from having control over the= ir DNS traffic?" should be answered at the device level and not the ne= twork level because of the point made earlier: once bits are on the wire, it's impossible to distinguish between an a= ttack and "approved administration" when those bits are manipulat= ed. Better to emit bits in the manner the user intended in the first place.=

We should be careful ab= out distinguishing "what is currently the case" from "what i= s possible", and avoid ruling out entire paths of exploration/developm= ent based on possibly erroneous assumptions.

Let m= e provide a hypothetical counter-example to the assertion that is not possi= ble (to distinguish an attacker manipulating DNS responses, from a known pa= rty manipulating DNS responses).

Suppose a known p= arty, with whom the client has a relationship, uses DNSSEC (or other crypto= graphic signature mechanism) to sign the manipulated responses.
S= uppose the client has installed some manner of validating cryptographic obj= ect, such as a DNSSEC Trust Anchor.

The nature of = public key cryptography is that only the party that possesses the private k= ey can generate such a signature.
If the recipient has the corres= ponding public key, and trusts it, it is possible to distinguish the two si= tuations, attacker vs known party.

This does not s= pecifically mandate a particular solution to the problem, but it DOES demon= strate that a solution to the problem is possible (and feasible and capable= of being operated at scale, etc.)

Brian=C2=A0
--0000000000009d3216059742ec9c-- From nobody Wed Nov 13 15:50:28 2019 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 81F7312010D for ; Wed, 13 Nov 2019 15:50:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LEO4HpUKOlWs for ; Wed, 13 Nov 2019 15:50:24 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A33B21200B9 for ; Wed, 13 Nov 2019 15:50:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 776BBBE39; Wed, 13 Nov 2019 23:50:23 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AmBA7lvL5d6C; Wed, 13 Nov 2019 23:50:22 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0916BBE2E; Wed, 13 Nov 2019 23:50:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1573689022; bh=tdbWZMv9fFR3+nvSVF1HecnPru1BVH+dcTzYgMB94Cg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=jObTRUM3pgHAHZJAygRWZ7ZMSs869ILt4xLnK5J9sHTc/LOsXwvildLGDmInb/CX5 1PM72awD0ANsFBZ1c1hXGKtb2/xWWewkTaXDpnLMWsiQzOZMlkD6Qa2PiXQbxeImKX OrBGIEsgblMPFa+x7eIeW+MCaoKveTitVlpQhOTA= To: Paul Ebersman Cc: ADD Mailing list References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> <66b22db0-dd35-e0c0-14c4-c7bd7cbb7a0d@cs.tcd.ie> <20191113234052.A7D14194D8ED@fafnir.remote.dragon.net> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Wed, 13 Nov 2019 23:50:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <20191113234052.A7D14194D8ED@fafnir.remote.dragon.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="QHk21eTkb2QVWhA9fM6LHKABUEFA6jPky" Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 13 Nov 2019 23:50:27 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --QHk21eTkb2QVWhA9fM6LHKABUEFA6jPky Content-Type: multipart/mixed; boundary="kjixNHBa4IMMPmm3MAEXIBYhuEwiufLn8"; protected-headers="v1" From: Stephen Farrell To: Paul Ebersman Cc: ADD Mailing list Message-ID: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> <66b22db0-dd35-e0c0-14c4-c7bd7cbb7a0d@cs.tcd.ie> <20191113234052.A7D14194D8ED@fafnir.remote.dragon.net> In-Reply-To: <20191113234052.A7D14194D8ED@fafnir.remote.dragon.net> --kjixNHBa4IMMPmm3MAEXIBYhuEwiufLn8 Content-Type: multipart/mixed; boundary="------------2F87C790631A1021814D26BC" Content-Language: en-US This is a multi-part message in MIME format. --------------2F87C790631A1021814D26BC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 13/11/2019 23:40, Paul Ebersman wrote: >=20 > Here I'll disagree. If I know something is happening and I want it > to happen, it's not an attack. The "it" involved in PM affects many people, not just you or I. And your opinion may depend on the identity of the putative PM attacker. That was all thoroughly discussed in the development of 7258. > I'll take the clarification that it requires both, since knowledge > without consent is still potentially an attack. See my earlier mail for my opinion of so-called "consent":-) S. --------------2F87C790631A1021814D26BC Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------2F87C790631A1021814D26BC-- --kjixNHBa4IMMPmm3MAEXIBYhuEwiufLn8-- --QHk21eTkb2QVWhA9fM6LHKABUEFA6jPky Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3Mlr0ACgkQWrL68XsX K+rBRQ//Y/N7aka+txFiPmeRdc3OmlQxPnDcf6vifO0OcYre/eAeacmby/ObbWrB aHpGHv+P0PqjAw5uykdTNT8yqbKSuN7HWjUND0CRnUhpgg/8TwosPnaWPMMeuDux UqHgQgj3V9D7twHzJ8Trqt+8WR6EL8WqZZI65JBWp479R0DY2C1drkPWmwLfcb+i Yf++lTMyMNKqpMc9EQWVsw9Bb6gb3t/LTifsYlYFzh/Un+Pxk4w/eJR0sX5OwaEI w2X+uW5y92ykj72UKLaYLN+8hk2jRiKQVV8Ns2Sye9Zq5mJExSfXsxs4mn0jUDm6 4bXzNRQ7bxZHfw3gzDoiMxomhgFO46YjwY3WN/Ka4ny7465KdsAtL+ktmhnlCCKr 8gzyoAiJToXjAGcSR3neoUq7IBhOzhUHqwUEeyiAlu5NgS8xmPmg8rJOr0pOoYiX Q7+frZ2GnM8Ioygoxc++f9tWZLjRyYqFolj2HuEl/JP1AmzEbhFThjIWmzD4Q7Kt L5kOaPGM9I/Kbo7SHmuycv/RXO/FiGTwVrtWPhlyVbK9Vqlqcri5abI2xSD///qq HZpDpG5/IphipjdVio9CnFWNiQ6IovlPazseNCICBUUNsrvL1xoQxkYgeDicNdzD 38CBwJiHsZ1XZ2Zsh0oItY8b4BTFvgeEYzsAd6FPQli1sTBw1v4= =l3+s -----END PGP SIGNATURE----- --QHk21eTkb2QVWhA9fM6LHKABUEFA6jPky-- From nobody Wed Nov 13 16:24:17 2019 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 ABEB7120018 for ; Wed, 13 Nov 2019 16:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 Tcl6dVHCvMtx for ; Wed, 13 Nov 2019 16:24:13 -0800 (PST) Received: from mail-vk1-xa2d.google.com (mail-vk1-xa2d.google.com [IPv6:2607:f8b0:4864:20::a2d]) (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 94F061200F8 for ; Wed, 13 Nov 2019 16:24:13 -0800 (PST) Received: by mail-vk1-xa2d.google.com with SMTP id 70so1045950vkz.8 for ; Wed, 13 Nov 2019 16:24:13 -0800 (PST) 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=9k2f6CkPa4tdRF/9hyrlA2b9h8CKOj8ie10Igt6Qdzk=; b=F/zkjJ05IbxPcHKLilxOvU6ccrng5OkGmJPueSSd7EkvzryyOfhQzes2mkWC8UTyYM L+w9njfCkR7yCepCAIgAKp4C6PHJthQ3HrtwOfJAJhHo8DZAGo/qyHb+hDi72ms1fEid zg7FrFu8LZ7BmyAtMai91KHlQQQI3kb7Ln5N94jPfW6OhWKOfC56Kaf4rPfqzuBOe6Yi iU9IvUV9AWadOj84khrqpyJ/LI0gZbO1JNYMUncQzwx7475geukYJynLufFCtiA9RMJe KAoRWZlHbZirT5A+8cmQgmu2kA23g4wfEKAwvUTrVhI805c56kAGvY22sDJ+dEM7qvZK EMOA== 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=9k2f6CkPa4tdRF/9hyrlA2b9h8CKOj8ie10Igt6Qdzk=; b=QqYeZsMW19B0lfzk830bMpRBOD5kEnRYrwIKJxfANpFRKjK0mMvKnzbA/Jvxx20QD2 JLyuu9QpSrvrytG/4HMJzH0SeKeaKdLNDMF3RLQhQ/gVElW7Yrlp/Ko5hMpX0qBMToCL eQGZrRddR8hKEsOzlHZOgJRSMkRHpSkZrSKlhjJX8sw5MVMef6xQcuN9vWfOC8Puh8OQ XZm387NSrBOWnMNMP0jaO2zTbTkvimM4G1DZhXC1Y4O+L/XBbYApt6gZ/E7kvjNuIN6K mQi0Uy6Ne+FkKJ79AXYBvxe8VaV1E8capEkB+ojTa/0rUBriFI2DyYcE2o51x/Mw0bnf 7BVA== X-Gm-Message-State: APjAAAVK08EEGyX13EVfphcowQp49RsTy0GtECiHfCWvl/sbKLW6Sow9 pBRwq/Qn0KcLMv+ZnIssr8q33dxb4No0pXwMH1k= X-Google-Smtp-Source: APXvYqwwPtRSmASlWDSgk6+yepNLaJ9y97Sk43EwL3esJneRu6fOy/JKsremZmfzoVyjoD4riYdrratS6LUS/gD4QBY= X-Received: by 2002:ac5:c399:: with SMTP id s25mr3643666vkk.65.1573691052494; Wed, 13 Nov 2019 16:24:12 -0800 (PST) MIME-Version: 1.0 References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> <66b22db0-dd35-e0c0-14c4-c7bd7cbb7a0d@cs.tcd.ie> In-Reply-To: <66b22db0-dd35-e0c0-14c4-c7bd7cbb7a0d@cs.tcd.ie> From: Brian Dickson Date: Wed, 13 Nov 2019 16:24:01 -0800 Message-ID: To: Stephen Farrell Cc: Paul Ebersman , Mark Nottingham , "Dixon, Hugh" , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000002b95a3059743802e" Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 14 Nov 2019 00:24:17 -0000 --0000000000002b95a3059743802e Content-Type: text/plain; charset="UTF-8" On Wed, Nov 13, 2019 at 3:32 PM Stephen Farrell wrote: > > Hiya, > > On 13/11/2019 23:07, Paul Ebersman wrote: > > My take from RFC 7258 is that the key differentiator is user knowledge > > and/or consent, i.e. if the user is not aware they are being monitored > > and/or has not consented explicitly to altered data (in this case DNS > > answers), that is what RFC 7258 considers an attack. > > FWIW, I don't agree. > > First, what passes for "consent" in computing in general > is not what I would call consent, as understood in more > mature fields such as medicine, so I would not myself > accept so-called "consent" as a get out of jail card in > this nor any other Internet context. I don't claim that > everyone would agree with that but that's ok, because... > > Second, the term "consent" doesn't occur in 7258. So I > don't think you have any real basis claim that 7258 is > anything to do with that risible (as used in computing) > abuse of terminology. > RFC 7258 references 6973, in its Section 4 (Security Considerations). Specifically, it says: More information about the relationship between security and privacy threats can be found in [RFC6973 ] However, in 6973, section 6.2 ( https://tools.ietf.org/html/rfc6973#section-6.2 ), talks specifically about User Participation. Quoting from that section: As a result, privacy regimes tend to include > > > Cooper, et al. Informational [Page 21] > > ------------------------------ > > RFC 6973 Privacy Considerations July 2013 > > > provisions to require informing individuals about data collection and > use and involving them in decisions about the treatment of their > data. In an engineering context, supporting the goal of user > participation usually means providing ways for users to control the > data that is shared about them. It may also mean providing ways for > users to signal how they expect their data to be used and shared. > > Basically, this directly refutes what you write about "consent", and is referenced by 7258 in a way that at least suggests it is more authoritative. It doesn't have to be labeled as "consent" to actually be consent, and this discussion of goals and methods, regarding informing users and providing control and signaling intent, seems to cover the issue very succinctly. No means no, but yes means yes. It does appear to imply the need for explicit consent, so I'd agree with excluding implied consent as an acceptable mechanism. But that is different from asserting that explicit consent isn't really possible. (If you didn't agree with what was in 6973, maybe you shouldn't have included a reference to it, or should maybe have called out the section on User Participation as a problem.) Respectfully, Brian --0000000000002b95a3059743802e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 13, 2019 at 3:32 PM Steph= en Farrell <stephen.farrell= @cs.tcd.ie> wrote:

Hiya,

On 13/11/2019 23:07, Paul Ebersman wrote:
> My take from RFC 7258 is that the key differentiator is user knowledge=
> and/or consent, i.e. if the user is not aware they are being monitored=
> and/or has not consented explicitly to altered data (in this case DNS<= br> > answers), that is what RFC 7258 considers an attack.

FWIW, I don't agree.

First, what passes for "consent" in computing in general
is not what I would call consent, as understood in more
mature fields such as medicine, so I would not myself
accept so-called "consent" as a get out of jail card in
this nor any other Internet context. I don't claim that
everyone would agree with that but that's ok, because...

Second, the term "consent" doesn't occur in 7258. So I
don't think you have any real basis claim that 7258 is
anything to do with that risible (as used in computing)
abuse of terminology.

RFC 7258 referenc= es 6973, in its Section 4 (Security Considerations).

Specifically, it says:
More information about the=C2=A0= relationship between s= ecurity and privacy threats can be found in=C2=A0[RFC6973]

However, in 6973, section 6.2 (https://tools.ietf.org/html/rfc6973#sectio= n-6.2=C2=A0), talks specifically about User Participation.
Quoting from that section:
As a result, privacy regimes tend to include



Cooper, et al. =
               Informational                    [Page 21]
 
RFC 6973<=
/a>                 Privacy Considerations                July 2013


   provisions to require informing individuals about data collection and
   use and involving them in decisions about the treatment of their
   data.  In an engineering context, supporting the goal of user
   participation usually means providing ways for users to control the
   data that is shared about them.  It may also mean providing ways for
   users to signal how they expect their data to be used and shared.
<= /blockquote>

Basically, this directly refu= tes what you write about "consent", and is referenced by 7258 in = a way that at least suggests it is more authoritative.

I= t doesn't have to be labeled as "consent" to actually be cons= ent, and this discussion of goals and methods, regarding informing users an= d providing control and signaling intent, seems to cover the issue very suc= cinctly. No means no, but yes means yes.

It does a= ppear to imply the need for explicit consent, so I'd agree with excludi= ng implied consent as an acceptable mechanism.

But= that is different from asserting that explicit consent isn't really po= ssible.

(If you didn't agree with what was in = 6973, maybe you shouldn't have included a reference to it, or should ma= ybe have called out the section on User Participation as a problem.)
<= div>
=
--0000000000002b95a3059743802e-- From nobody Wed Nov 13 16:51:51 2019 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 9484F1200F8 for ; Wed, 13 Nov 2019 16:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.965 X-Spam-Level: X-Spam-Status: No, score=-0.965 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q24JTIUQxbEN for ; Wed, 13 Nov 2019 16:51:48 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9337120122 for ; Wed, 13 Nov 2019 16:51:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 7B2ABBE39; Thu, 14 Nov 2019 00:51:45 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0BXiF2bT-JK; Thu, 14 Nov 2019 00:51:44 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id DE8EBBE2E; Thu, 14 Nov 2019 00:51:43 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1573692704; bh=sFmOQOLknH9t1rFVRjUjojowiLLGHVTji4E5tldMBR8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=1R6qCwYC8RtAEFVvA1E+/RFI8NhRZ1BYW93MlATXBejEVvoYzRvTqxVGwJVinSOwF Q3LFdw7rysf/OnuBPJ80pCC+uEZeEN3JF69lMzSTplGXkr7r2TmWpMJwL3Pn7tIYss JuT0Y2i8oBidnuwKIwBertQoIEqMpUFuUrFeL7LI= To: Brian Dickson Cc: Paul Ebersman , Mark Nottingham , "Dixon, Hugh" , ADD Mailing list References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> <66b22db0-dd35-e0c0-14c4-c7bd7cbb7a0d@cs.tcd.ie> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Thu, 14 Nov 2019 00:51:43 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="9HtmYCub1rSDSSNt5W1TJ1LL2Z2w9hKr9" Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 14 Nov 2019 00:51:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9HtmYCub1rSDSSNt5W1TJ1LL2Z2w9hKr9 Content-Type: multipart/mixed; boundary="HAOfm5qAJl2J1x4mTMBaJy5H5uL1m7kjp"; protected-headers="v1" From: Stephen Farrell To: Brian Dickson Cc: Paul Ebersman , Mark Nottingham , "Dixon, Hugh" , ADD Mailing list Message-ID: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> <66b22db0-dd35-e0c0-14c4-c7bd7cbb7a0d@cs.tcd.ie> In-Reply-To: --HAOfm5qAJl2J1x4mTMBaJy5H5uL1m7kjp Content-Type: multipart/mixed; boundary="------------7558B1139661DC2BBC2CCCF4" Content-Language: en-US This is a multi-part message in MIME format. --------------7558B1139661DC2BBC2CCCF4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 14/11/2019 00:24, Brian Dickson wrote: > Basically, this directly refutes what you write about "consent",=20 You are incorrect. So-called "consent" (as the term is abused in computing) rarely if ever has anything to do with how a user's data is treated. In approx. 100% of cases (counting say user actions) relevant to this discussion, so-called "consent" is an attempt to trick users into saying "yes" and really nothing more. > and is > referenced by 7258 in a way that at least suggests it is more authorita= tive. No. 7258 is a BCP with IETF consensus, 6793 is an IAB stream informational RFC and reflects the opinion of the IAB members at that time. (As it happens, I like most of the text, and think it'd be a fine thing if the IETF had a BCP on that subject.) >=20 > It doesn't have to be labeled as "consent" to actually be consent,=20 Perhaps. My point is different: I claim that what is termed "consent" in computing, the Internet and the web is really 99% a load of lawyerly obfuscatory crap and nothing to do with consent. > and this > discussion of goals and methods, regarding informing users and providin= g > control and signaling intent, seems to cover the issue very succinctly.= No > means no, but yes means yes. >=20 > It does appear to imply the need for explicit consent, so I'd agree wit= h > excluding implied consent as an acceptable mechanism. >=20 > But that is different from asserting that explicit consent isn't really= > possible. >=20 > (If you didn't agree with what was in 6973, maybe you shouldn't have > included a reference to it, or should maybe have called out the section= on > User Participation as a problem.) 7258 is not "my" document - I was the editor. But see above relating to the formalities. But I think we're wandering off topic now. Cheers, S. --------------7558B1139661DC2BBC2CCCF4 Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------7558B1139661DC2BBC2CCCF4-- --HAOfm5qAJl2J1x4mTMBaJy5H5uL1m7kjp-- --9HtmYCub1rSDSSNt5W1TJ1LL2Z2w9hKr9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3MpR8ACgkQWrL68XsX K+o5OQ//fS/A1BzSDjgMJ9sEp+4nBlhcyqSZ4x3exRPNkezKXCFSOJEsZqZHKLas 2Gmgj1COJmwkTFt33RBszKbst+HonvGGtm02Glp6IgwsgpUF+JJGhYK5S0Q2UM0y WL39rT4kUAY7uWrqzxeHfDlRULUqL2fwiz6+Mku/BhQArdPx21OzL+36b7CU92oa z+hvfqazDge7Jjud8ZPmEf9RST4kwur/M6KC1RhU+gtK3F+eohR6G6zonx81FelV hhwq5ju69J2JC2LvM6+sus0EmLIiDwiqTdz2Y8A6WTqeUNVz8NB4qUbJgnq8A2Gj MNgYgfxKrPGkXD93q0v7AVPayiOT8DKmSrcTK+uanDI2A26ZYMGTTwBGFufoT1Hb 5jw3nAKUl4mohGoZyeB4cF/IMHtnRnAR285EcrCONeaKVyLFjReBIKyTCz+XxumP s2BgQ79/fW5LAR1OEzlwpVz/mXZl7kAvPHTAnzJ0/V335fhO/fey/thd7eRHHGq4 0prMhaVvpXb022FXute1P4vp4elG9i8hWx2EPaHF+kobcApkfvxTpQELocaTtjW9 Y2fLpAVPxpu5Zn2NoxcSbG7kVlC3HRt6J+y0+3FOM8OK6q1/Gh94F3DlrX0NEgFt dSEmIPuOOlyfGIcessGoMSWIY7LcQUn3HOI0kubWjZmRKswAlDU= =DGIt -----END PGP SIGNATURE----- --9HtmYCub1rSDSSNt5W1TJ1LL2Z2w9hKr9-- From nobody Wed Nov 13 17:04:05 2019 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 7306F12011D for ; Wed, 13 Nov 2019 17:04:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVH90-Pj4q-l for ; Wed, 13 Nov 2019 17:04:02 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 30EC41200D8 for ; Wed, 13 Nov 2019 17:04:02 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id r144so4837878iod.8 for ; Wed, 13 Nov 2019 17:04:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9UY4oKm2cDdCpcWxKEpoWoyPfUZXRyjghmMqjqvgNEI=; b=pk0TO8Ok48EmEew1FmEArKEm09wjnRdWJBsvCoreV4xjwwVXy2qF7XVQnnteOrJxfU pMWMD1uZ6gq65t/08Srjr1Qa8yvsJCIbNaX5xQJeQuLz0whmR4l5UOp/J7tc/1utQu7+ OT0aH+EKP6KZML6bUNYlHB59t7Sqxsr5A7z1wGCinmzzw9XXc9bhHBRl+ql6dvq8y1Ll AKLs3zUkS+HHgncfo1GYoqOBLuoW5kUZaAK4P+AEMoLHh/dzcYbXbGgyGSTdKsoOtCc/ 6R4zPTmzS41zAVWWEFEaGarrGCQDW8qs+zXErARSGCBLGG+z0m3Sk9/D1e9GQnFZ2CL9 s2Ng== 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=9UY4oKm2cDdCpcWxKEpoWoyPfUZXRyjghmMqjqvgNEI=; b=pKXoqYCh5VikglAYtz9JuCG2fK+xj+8PjyGRK8aYArcyGyQv8ezPhq+XyfBIe7Dznr yaSUCsEFbNAXhcJ6cnf1NhCbVpAI7NWgONkd3CCGZXVPV1wSyWdIsFOE8bPcksWBp7eB xyDmHB8LeCSdCNW20fWdYvsfSCfztKYzeOVBWg5llmF0MymGdqPts0nFLVc/f04K9z/Q aIcujGkd2SIKMEkcUPZAvV7t2t/0S7t/rtjPqHGletCvRc9zJPzrSsmdQgKMz21pRel/ xDklvTVj7ehCY2Xzdox89nHSpcmWLelQZQyTMWWPmsc09wmutPUvn1ydmTCoki8OqdBZ aMJA== X-Gm-Message-State: APjAAAUSzOsY3wcHwsMOq+X44rFUBzBrT0hJB6EUv+UibGJWkMtDJQK5 eZTdIGx1qiBOfalymnm3UuTbigQ6QQG21kJgRPGccw== X-Google-Smtp-Source: APXvYqx6EjFS8eDDp86NgWNKyBOGogF/RUmK4d5ik6k03Edf7s39CApsd6GbB4IMjNrR59OAY6uy5nZJWPJ00GnypnE= X-Received: by 2002:a5d:8b99:: with SMTP id p25mr6183991iol.41.1573693440233; Wed, 13 Nov 2019 17:04:00 -0800 (PST) MIME-Version: 1.0 References: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> In-Reply-To: From: Ben Schwartz Date: Wed, 13 Nov 2019 20:03:48 -0500 Message-ID: To: Brian Dickson Cc: Mark Nottingham , ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000009277430597440e59" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 14 Nov 2019 01:04:05 -0000 --0000000000009277430597440e59 Content-Type: multipart/alternative; boundary="0000000000007e23580597440e63" --0000000000007e23580597440e63 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 13, 2019 at 6:01 PM Brian Dickson wrote: > > > On Wed, Nov 13, 2019 at 8:12 AM Ben Schwartz 40google.com@dmarc.ietf.org> wrote: > >> >>> - Use of records from untrusted sources >>> >> > I think this really needs more concise language on what is meant by this > bullet point. > E.g. > > - Is this referring to DNS responses that are not validated? > - Or is this referring to DNS *records* provided by some source (e.g. > a web server) that is not the DNS resolver in use? > > The latter. > IMHO, the former would probably be okay to place outside normal discussion. > > However, IMNSHO, the latter should specifically be listed as something > akin to "must be excluded from any WG work, except as authorized by prior > approval by DNSOP WG, WG chairs, and AD", as this would massively impact > the entirety of the Domain Name System, including security model, security, > scaling, non-repudiation, etc, etc. > Thank you for the clear statement of your view. Precisely because of the strong feelings that have been expressed on this topic, the proposed charter text lists it as an example of a category that is excluded from the group's work unless full consensus miraculously emerges. Insofar as DNSOP WG members also participate in this proposed WG, the restriction seems similar to the one you propose. > > Brian > --0000000000007e23580597440e63 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 13, 2019 at 6:01 PM Brian= Dickson <brian.peter.dickson@gmail.com> wrote:

--0000000000007e23580597440e63-- --0000000000009277430597440e59 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCBznVUg/zk1e4wadJt3Pgdz A9uXV3DIopux2BuwDps6njAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTExMTQwMTA0MDFaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAcNgR/0Tjmi4EN9bT9fcrrwSPkc0NVrkOfJlyY/Hy Luq3Cpx7LSDqVZA2UxS35dp3dyV9PJ/0eQF82gHTJDOeECxG1G+5fRo/LioKBOur9tk4jXSr/VXN E+05hYmndd0PGpMCLb3skykenMNZjFK2bZi+muuKwDrthHzStDhvle8ZhNdfVMWyoPRDL3tDvrUu VUz+XlsmYgyhPnaCSeJEXvZoXn/tJTKWo/rsVyTRQuPtUVzgerlI+iK2YdtMdcl1YNtUpGWExfec 1FtID6Lcbj4/PXOXrWz9bJ+XGGBs8WbgeBgP7p4+aekCEdYr2SrOME/7FlZym4UVC7EiPNlKiA== --0000000000009277430597440e59-- From nobody Wed Nov 13 21:03:49 2019 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 A4B3A120807 for ; Wed, 13 Nov 2019 21:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 Uhx4-HUb6-8i for ; Wed, 13 Nov 2019 21:03:45 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id B059412013B for ; Wed, 13 Nov 2019 21:03:45 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.79.0]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id xAE53Xub002688 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Nov 2019 21:03:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1573707824; x=1573794224; i=@elandsys.com; bh=BCDZOlV5NyKCOBIaZG0gPYkXCOpGImb3iUp/v67q/2U=; h=Date:To:From:Subject:In-Reply-To:References; b=QzSSzrIpT+OEIY6YWfs1YIsN9p4YaJ1x9B0h8ETzjKTPQJheN0koKLTlSvRikcnFl 95T+FnVWb4XJGKfPMD+T3nDKzThQsQ1iY2yon3HgGS/tMk4xd4KtKEk88Z35QhqkA8 baIkh4PGcUY1RtAlyEwTYlA5Bci0E5dT+ObB5ASM= Message-Id: <6.2.5.6.2.20191113204811.0df6e720@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Wed, 13 Nov 2019 21:02:50 -0800 To: Ben Schwartz , add@ietf.org From: S Moonesamy In-Reply-To: References: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 14 Nov 2019 05:03:47 -0000 Hi Ben, At 08:11 AM 13-11-2019, Ben Schwartz wrote: >I would define "full consensus" as the absence of any stated >objection. I think this requirement might foster a more congenial >and productive working group environment, because (on the listed >topics) participants can object without feeling pressure to >emphasize or re-state their arguments. In my view, the >disagreements in question are not principally "technical", so it >doesn't make sense to ask the chairs to assess "technical consensus". The usage of "full consensus" sets a very high bar for assessing agreement on any of the topics listed in the proposed charter. In my opinion, it is unrealistic to expect any discussion to fulfill the "full consensus on any statements" requirement. There is the following statement in the last paragraph of the proposed charter: "All last-call announcements will be copied to the relevant working groups to ensure thorough and careful review". Copying emails to other WG mailing lists does not ensure through and careful review; that is merely an announcement of the Last-Call. Regards, S. Moonesamy From nobody Thu Nov 14 01:02:48 2019 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 A30E81208A1 for ; Thu, 14 Nov 2019 01:02:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w578U2o1iJlj for ; Thu, 14 Nov 2019 01:02:44 -0800 (PST) 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 B6427120894 for ; Thu, 14 Nov 2019 01:02:44 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id i11so5902171iol.13 for ; Thu, 14 Nov 2019 01:02:44 -0800 (PST) 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=YOS2fbbIdfJ4dgOQdYMoVigsLbdfiRnW8XqtrXBn3lc=; b=o2sPoxSutHI7hS9vmH3bJDxFbgYKSsbaz0EOPcOu3kFN5Kc0AJzDutKCBKcEz36cJW lx75F6LvHacGkNgC+8wUGo9XCiDCBr3LyzeuqGXJE1UkEaAik1Cvw9iGu7vBoG8UDfBV PXIiHCMgZJlYKVlefVgqJNRI1pE817WM15Zk3WyivwJIYQLZvre0pH7w8ZfcS6XDQaiW 5qQF3ReF2BAzQJv4kQGa6T+mxtA4746Vhof+egxAjvZtq+hs61egAg470MalkY/QkKwD NZevnlC/C/ldYSQvCBB0E2eNwj9gFddK/SKc+Hk+83KjIoXNPL54wmEwaJrY6w5Y14tv 335Q== 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=YOS2fbbIdfJ4dgOQdYMoVigsLbdfiRnW8XqtrXBn3lc=; b=f4Pavh9lTXNhiGdCAOKL4hgiqFH0h6Lzrz9cGdTOhSpTR5W7aL1BOLBOJdKInrsIDp ef+7RCVseQFuqkDdlJX9YWDPOqTzMNLXvl2u5oGqLQbZNl1QOLhSMbSjnczVtgK+t0iS C4KFGo073Pmy7Ume65ywiOHgYUEbFhbpt0eqCpDffBLlAM4PYGFKsOSaGACp/HgfiZyR xXKhpW8LUGBaNuxJUaM4/kBFOjMyxqbErVl0v62tx1lAlJR1A14/zJgy0ObaSQLNHjDA sA2mrw/jG+HWNjEgojtev7ug8RCj7fcDYrTU9Km2bCpOgKXKMIoX5Wjra0pJ33MkZnEL srSA== X-Gm-Message-State: APjAAAUfo/cwi0UIXYHrdGqoLjRUc/oKfGFyDbVtXEl2ySD3KH5xNZ0f PJfPUkCfDU0LkMi4jnyo+dPs8pnQcDE46cgYNMOxgg== X-Google-Smtp-Source: APXvYqz7UaKUSXV5Bl/oWBE8k69rv93V6wRkqAkcl8WClQDOaaw3hDBPVSSgLx2HgDOS497DZsj8xJAtazM3A60DbRo= X-Received: by 2002:a05:6602:8c:: with SMTP id h12mr853576iob.254.1573722163904; Thu, 14 Nov 2019 01:02:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Thu, 14 Nov 2019 01:02:32 -0800 Message-ID: To: "Dixon, Hugh" Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000008e0b0805974abeec" Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 14 Nov 2019 09:02:47 -0000 --0000000000008e0b0805974abeec Content-Type: text/plain; charset="UTF-8" On Wed, Nov 13, 2019 at 2:55 AM Dixon, Hugh wrote: > Some might like to think that "Pervasive Monitoring" is clear and bold... > Yes, I think it's pretty clear and bold. :) > Information in this email including any attachments may be privileged, > confidential and is intended exclusively for the addressee. The views > expressed may not be official policy, but the personal views of the > originator. If you have received it in error, please notify the sender by > return e-mail and delete it from your system. You should not reproduce, > distribute, store, retransmit, use or disclose its contents to anyone. I believe I may have received this message in error, but I'm not sure what to do about that, since it's a public message. I'm happy to delete it. > Please note we reserve the right to monitor all e-mail communication > through our internal and external networks. > ... thanks, Rob --0000000000008e0b0805974abeec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Some might like to = think that "Pervasive Monitoring" is clear and bold...

Yes, I think it's pretty clear and bold. :)
=C2=A0
Information in this email including any attachments may be privileged, conf= idential and is intended exclusively for the addressee. The views expressed= may not be official policy, but the personal views of the originator. If y= ou have received it in error, please notify the sender by return e-mail and= delete it from your system. You should not reproduce, distribute, store, r= etransmit, use or disclose its contents to anyone.

I believe I may have received this message in error, but I'm no= t sure what to=C2=A0do about that, since it's a public message. I'm= happy to delete it.
=C2=A0
Please note we reserve the right to monitor all e-mail co= mmunication through our internal and external networks.

=C2=A0...

thanks,
Rob
--0000000000008e0b0805974abeec-- From nobody Thu Nov 14 04:42:40 2019 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 29B15120846 for ; Thu, 14 Nov 2019 04:42:38 -0800 (PST) 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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnLrNpngboux for ; Thu, 14 Nov 2019 04:42:34 -0800 (PST) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id C1CAA120824 for ; Thu, 14 Nov 2019 04:42:34 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id 74F9B5F40DCE; Thu, 14 Nov 2019 13:42:33 +0100 (CET) Received: from [172.19.80.133] (unknown [38.98.37.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 812FE5F402C0; Thu, 14 Nov 2019 13:42:19 +0100 (CET) From: "Ralf Weber" To: "Ben Schwartz" Cc: "ADD Mailing list" Date: Thu, 14 Nov 2019 12:41:55 +0000 X-Mailer: MailMate (1.13r5655) Message-ID: <254AEFB0-F930-466B-8BB6-707D5CE72657@fl1ger.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 14 Nov 2019 12:42:38 -0000 Moin! On 13 Nov 2019, at 2:32, Ben Schwartz wrote: > Please review the agenda and proposed charter, and join us next week > for a > full discussion. From the proposed charter: > This working group will consider technical drafts on DNS client > configuration, especially with a focus on the following items where > technical consensus seems obtainable: > > - Communicating configuration between the network, operating system, > and > applications > - Discovery of resolvers and their capabilities and behaviors > - Query routing in a multi-resolver environment This is ambiguous. If it describes the current /etc/resolv.conf that’s fine, but I fear that it describes something where you ask “resolver A” for example.com and “resolver B” for example.net. I don’t think that there is consensus for such an approach. > - Multiple non-equivalent query paths, such as split-horizon DNS or > geo-sensitive answers > - Local DNS caches (e.g. partitioning, use of stale records) > - Resilience and fault-tolerance (e.g. single points of failure) > - Support for debugging and analysis > - DNS Push (accepting responses to queries that have not yet been > issued) Same thing I don’t think that there is consensus on this. I personally think it is a bad idea, but I seem to recall from earlier discussions that others agreed with me. IMHO this belongs in the relevant, but more challenging for consensus building category. So long -Ralf —-- Ralf Weber From nobody Thu Nov 14 04:47:12 2019 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 39D37120853 for ; Thu, 14 Nov 2019 04:47:10 -0800 (PST) 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 3ga5R1Klz8y0 for ; Thu, 14 Nov 2019 04:47:09 -0800 (PST) Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 07EC9120846 for ; Thu, 14 Nov 2019 04:47:09 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id 6973B5F40DF9; Thu, 14 Nov 2019 13:47:08 +0100 (CET) Received: from [172.19.80.133] (unknown [38.98.37.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id AF48B5F40350; Thu, 14 Nov 2019 13:46:54 +0100 (CET) From: "Ralf Weber" To: "Paul Wouters" Cc: "Melinda Shore" , add@ietf.org Date: Thu, 14 Nov 2019 12:46:30 +0000 X-Mailer: MailMate (1.13r5655) Message-ID: In-Reply-To: References: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> <275528bd-955d-5fe3-b093-d3d997f073fb@nomountain.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 14 Nov 2019 12:47:10 -0000 Moin! On 13 Nov 2019, at 19:52, Paul Wouters wrote: > On Wed, 13 Nov 2019, Melinda Shore wrote: > >> Anyway, I'd be careful about getting into a situation in which people >> are working on something that's unlikely to progress, and the current >> charter text implies that a working group, if chartered, might do that. > > Yes, there is a huge chance nothing will come out of a WG. After all, > the IETF work for provding the alternative solutions has been done > already. We have DoT and DoH. How, when and if people will use this > seems mostly out of scope for IETF. I disagree. We have lots of groups and efforts in the IETF that discuss deployment of Internet standards. If we don’t do this the actual deployments will diverge and not be consistent (see NAT). So long -Ralf —-- Ralf Weber From nobody Thu Nov 14 05:02:42 2019 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 46E8012085B for ; Thu, 14 Nov 2019 05:02:40 -0800 (PST) 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=unavailable autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EU6JF_RXK4bN for ; Thu, 14 Nov 2019 05:02:37 -0800 (PST) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 3F48612012E for ; Thu, 14 Nov 2019 05:02:37 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id E88E45F40E1A; Thu, 14 Nov 2019 14:02:35 +0100 (CET) Received: from [172.19.80.133] (unknown [38.98.37.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 1A2345F4036E; Thu, 14 Nov 2019 14:02:03 +0100 (CET) From: "Ralf Weber" To: "Tommy Jensen" Cc: "Paul Ebersman" , "Mark Nottingham" , "Dixon, Hugh" , "ADD Mailing list" Date: Thu, 14 Nov 2019 13:01:35 +0000 X-Mailer: MailMate (1.13r5655) Message-ID: <99B3F484-0C0B-40F0-9E97-E7807AC61FA5@fl1ger.de> In-Reply-To: References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 14 Nov 2019 13:02:40 -0000 Moin! On 13 Nov 2019, at 23:14, Tommy Jensen wrote: > I agree. This to me leads us to transparency and configuration > requirements for apps and platforms offering DNS services rather than > requirements on the protocols apps and platforms use to perform DNS > queries. Not sure if it's within scope of this WG or not (nor do I > care to wade those waters), but it seems the question of "how do we > ensure we're not preventing users from having control over their DNS > traffic?" should be answered at the device level and not the network > level because of the point made earlier: once bits are on the wire, > it's impossible to distinguish between an attack and "approved > administration" when those bits are manipulated. While this is possible for well behaved clients, it’s hardly possible for devices that attack my network, like hacked IoT devices. We have to give the network some means to defend against this. To achieve this the proper behaviour of well defined client must be predictable and follow what the network offers. If attack and regular traffic look the same defending against attack traffic gets much harder. So long -Ralf —-- Ralf Weber From nobody Thu Nov 14 05:13:32 2019 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 0AE2012086A for ; Thu, 14 Nov 2019 05:13:31 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 x99Unj2iBbvM for ; Thu, 14 Nov 2019 05:13:27 -0800 (PST) Received: from mail-qk1-x730.google.com (mail-qk1-x730.google.com [IPv6:2607:f8b0:4864:20::730]) (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 544AA12012E for ; Thu, 14 Nov 2019 05:13:27 -0800 (PST) Received: by mail-qk1-x730.google.com with SMTP id e2so4897015qkn.5 for ; Thu, 14 Nov 2019 05:13:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=G4FbvTzOZ1VIpNllXwAWEUq7eucf5+XB9fJP5feYcJE=; b=xn+/nOeT2WnfQYfCGRaUa1tJb91LoTEQUns6ldEfVpxlPHMUOXOe68y+dYCoYgSQZm 5sI0xGeMDZmOU9bV0Siy3kzax0HLgLv4XoMOhnWY1EPTTpVAJSJicmSXKUy43FyjvY3F A22bqsDT81YeULUgA+wuqag9r7gEqOJJPSE9bRXDQlL8Qi8oPG/dPVbTxLg+eT1TCLrl uBR8Bu0PzDE869Vpf/3/39mXZMGpjsvcYNWS2VGlF8rG4hZ3jcthwoj/WP8ekdzwAvmD 1G+jtsXFG19JLt8/D9H6qAzhHAy2cbMjqknFExvVHHHbr5KZuIYgeR63dguQRmeS2W1B c87Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=G4FbvTzOZ1VIpNllXwAWEUq7eucf5+XB9fJP5feYcJE=; b=lPc/UCh3ME5HHAEa+r9cQZFcs2CHXFhCSlIv6kn+RmsdcztHNudzZHRkYVL/9HWY/b ateB5CNISGvycquZ6ohgbrMkCevHyHEa3jBnS3Wpyc8edCTo4X8nPyy8M7/YoSFJgpS+ h2xZlToWbOwUSplKvMN0OXHmCtmDaxkhkmQGUQO/Z+ZxSnjpzCx/VVJXmYF4jL0xOhCn Q164ALHQCshYqBHQgPjvMMpYMrdRG1Jq2P/2W6E1JcokqStTark9pAJPP7ofRO4NeAJw MQU8Acn3LqbMQO5PqLjxIWuZLkpaRiFGsCAk7ldaMPO1cf8IlOFw0owaUVXA+mpehT4Q X86g== X-Gm-Message-State: APjAAAXGRjNGLGcbyUiOZ+3DJCNhJMuyiXEmB5impVy/+Arx8Di3L15l kmy4zAO5pRX1aLD+Roxl0fHA7w== X-Google-Smtp-Source: APXvYqxszld7eQvY4gsE1e4CEFGq5SFBRW++KzPnfzGs/Dry0kGjdnaJT8uS1gKZpz1w36GrxQGKPg== X-Received: by 2002:a37:4e03:: with SMTP id c3mr2972241qkb.6.1573737206304; Thu, 14 Nov 2019 05:13:26 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:dd31:a1c0:e9f7:ee49? ([2601:18b:300:36ee:dd31:a1c0:e9f7:ee49]) by smtp.gmail.com with ESMTPSA id w15sm3199732qtk.43.2019.11.14.05.13.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 14 Nov 2019 05:13:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Thu, 14 Nov 2019 08:13:22 -0500 Message-Id: <44754CB6-1CED-4ADF-9521-1361DF4F75A6@fugue.com> References: <99B3F484-0C0B-40F0-9E97-E7807AC61FA5@fl1ger.de> Cc: Tommy Jensen , "Dixon, Hugh" , Mark Nottingham , Paul Ebersman , ADD Mailing list In-Reply-To: <99B3F484-0C0B-40F0-9E97-E7807AC61FA5@fl1ger.de> To: Ralf Weber X-Mailer: iPad Mail (17B84) Archived-At: Subject: Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy 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, 14 Nov 2019 13:13:31 -0000 Sent from my iPad On Nov 14, 2019, at 8:02 AM, Ralf Weber wrote: > While this is possible for well behaved clients, it=E2=80=99s hardly possi= ble for devices that attack my network, like hacked IoT devices. We have to g= ive the network some means to defend against this. To achieve this the prope= r behaviour of well defined client must be predictable and follow what the n= etwork offers. If attack and regular traffic look the same defending against= attack traffic gets much harder. Your IoT devices should not be able to communicate freely with all other dev= ices on your network (or off). They should be firewalled automatically usi= ng MUD. This is a much more effective strategy than filtering their DNS qu= eries, because it is a list of permitted connections rather than a list of e= xcluded connections. The permission list permits only those destinations the= IoT device should be talking to. An exclusion list allows the IoT device t= o talk to all unknown adversaries, and only blocks communication with known a= dversaries. So it=E2=80=99s perhaps marginally better than nothing, but st= ill mostly useless. From nobody Thu Nov 14 05:32:51 2019 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 389A01200EF for ; Thu, 14 Nov 2019 05:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 i496HuVhqsys for ; Thu, 14 Nov 2019 05:32:48 -0800 (PST) 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 3365C120059 for ; Thu, 14 Nov 2019 05:32:48 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47DMqL1WWWz366 for ; Thu, 14 Nov 2019 14:32:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1573738366; bh=h+9v4HAKXC3LWMnoidi0L6EBKYQh0dbWZo5rkkQAozY=; h=Date:From:To:Subject:In-Reply-To:References; b=KEg2wmCfjuEyEGdDTvQQsPLsXOceJwtB9C6ImEgCBKkiX0EDsj5iiK+OK8Pak9cqR qJPoSMklEXJbWyMjCey+SJdxMrJh+w4SIXvGw0W7dHDZuwhZrLwFLntSJKiAtS7sXU S3RQLjGQa6ZomXIt5eyilkbwLAiBJz1px6zw8KYA= 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 uyp2b_mr-DoS for ; Thu, 14 Nov 2019 14:32:45 +0100 (CET) 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 for ; Thu, 14 Nov 2019 14:32:45 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 1D0D0607CB7C; Thu, 14 Nov 2019 08:32:44 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 194C038568 for ; Thu, 14 Nov 2019 08:32:44 -0500 (EST) Date: Thu, 14 Nov 2019 08:32:43 -0500 (EST) From: Paul Wouters To: add@ietf.org In-Reply-To: Message-ID: References: <85E58149-F5F2-4F96-A7EC-C889DE7388EC@mnot.net> <275528bd-955d-5fe3-b093-d3d997f073fb@nomountain.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 14 Nov 2019 13:32:50 -0000 On Thu, 14 Nov 2019, Ralf Weber wrote: >> Yes, there is a huge chance nothing will come out of a WG. After all, >> the IETF work for provding the alternative solutions has been done >> already. We have DoT and DoH. How, when and if people will use this >> seems mostly out of scope for IETF. > I disagree. We have lots of groups and efforts in the IETF that discuss > deployment of Internet standards. If we don’t do this the actual > deployments will diverge and not be consistent (see NAT). I agree in general, but for a topic of end-to-end vs enterprise monitoring, there is simply not much left to say. There are two camps with different requirements that are not going to meet in the middle. So the best we can do is ensure support for both camps. Paul From nobody Thu Nov 14 05:41:26 2019 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 D4FB91200EC for ; Thu, 14 Nov 2019 05:41:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sky.uk 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 pkaWViJ5PaV7 for ; Thu, 14 Nov 2019 05:41:21 -0800 (PST) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (mail-ve1eur02on060d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe06::60d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 517A91200E5 for ; Thu, 14 Nov 2019 05:41:21 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fZnlsU+kMNBi4qHlKb69GgnAEGBxc1VdIGON/k/AfvzCGkcrP55FrzS9e622Vs6lNfCij6ggBSQWWhsJhN28yaFIQoJRt1CpMv3fvdVz4KNpDNPyWLVg+ffUHupEpiYc3yvuY3mXR+hznXUbQRviE5nHqgQV+k+9o8QJOTkLe7jl/CCT0KLDRTPvj12grYCQWAL0DBAYnhh17owzP+twAZApM4VYrkIcnBNtp+suOcSxHlibxFw9FyjlVY7XB6THywTdASTABChQApacl2av9akd3NV4nHbG3rT+Q05PKK4VqM0BK1HW63LKTBSJcNDoFwB7COvi+8BYCAWTrhvrpQ== 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=TkmW0ITDnE4v29OHxdbtcNeWqTeFU8ZkbPaTIGdAK4Y=; b=H60b+0o8tEN/+TV2wDesWGCSdCLLw3mGv522gAjYXVkBG7t641/mIDAFCd6s9yTG00nexpVe0hwKhBrRynwzWirddLj3s/eDw1TWtIWwOXIlHLyIQSeURTLM4ZfQghpcWHm/q3fHMivagTOxWZGpiVzejNysOK1np+xN0MtqDuhkCd8jbU/JCwXU/m3VKnDa4SJ0ZSJnK9xLY9k7QMoSWZr8dqkdo8Umc+BhLy6QrqrRR1JwYglMZjC+um+696BWS/FRDBWTYipWqKmwo11vx+15k2LYFe9xlfjzBrXIxSG6e9D8UYIpPLapLeNN2XDMpjVo6dimFIUGJAugJmyfSg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=sky.uk; dmarc=pass action=none header.from=sky.uk; dkim=pass header.d=sky.uk; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sky.uk; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TkmW0ITDnE4v29OHxdbtcNeWqTeFU8ZkbPaTIGdAK4Y=; b=NV33lad6XtPa5bsT0L0feW+/ix3kamM3xr/UpuqqImBGXBJFAQxFBeLeA/10TgHF0D8Dg9NeG7uMSYgms4+YAL4jh1w4PlLdBxqGC1QPqqdy8W6g/NhMUWcXBUBa6IhzqBFIGg5UCYEcQ8+aaP5yg7HlhXVLRmhjKhux5qkaV68= Received: from DB6PR0602MB2805.eurprd06.prod.outlook.com (10.172.248.15) by DB6PR0602MB2903.eurprd06.prod.outlook.com (10.172.250.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.22; Thu, 14 Nov 2019 13:41:17 +0000 Received: from DB6PR0602MB2805.eurprd06.prod.outlook.com ([fe80::99a5:cbea:5d41:ab2e]) by DB6PR0602MB2805.eurprd06.prod.outlook.com ([fe80::99a5:cbea:5d41:ab2e%5]) with mapi id 15.20.2451.027; Thu, 14 Nov 2019 13:41:17 +0000 From: "Dixon, Hugh" To: ADD Mailing list Thread-Topic: [EXTERNAL] Re: [Add] ABCD BoF agenda items, pervasive monitoring and privacy Thread-Index: AQHVmhDS96z9Z8gdakCqsARxecCtqKeJtfeAgAAENoCAAAbgAIAADnGAgAAHvYCAANcDAA== Date: Thu, 14 Nov 2019 13:41:17 +0000 Message-ID: <85D5CF5E-C15E-4DCD-A89F-09025DEA1CC1@sky.uk> References: <26198F0A-A492-40BF-8CC5-70BFBC946FA8@mnot.net> <20191113230743.D37EA194D58F@fafnir.remote.dragon.net> <66b22db0-dd35-e0c0-14c4-c7bd7cbb7a0d@cs.tcd.ie> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191103 authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hugh.Dixon@sky.uk; x-originating-ip: [90.216.134.196] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1a1ce855-6ea2-4610-cd6d-08d769085343 x-ms-traffictypediagnostic: DB6PR0602MB2903: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:3826; x-forefront-prvs: 02213C82F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(136003)(376002)(396003)(39860400002)(366004)(199004)(189003)(6506007)(6246003)(64756008)(99286004)(66556008)(66446008)(66476007)(66946007)(6512007)(7736002)(305945005)(66066001)(6916009)(3846002)(6116002)(11346002)(76116006)(91956017)(2616005)(476003)(66574012)(446003)(486006)(14444005)(8936002)(14454004)(25786009)(2906002)(76176011)(6486002)(478600001)(81166006)(6436002)(71200400001)(229853002)(256004)(26005)(81156014)(186003)(316002)(58126008)(5660300002)(86362001)(36756003)(102836004)(8676002)(5024004)(53546011)(71190400001)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR0602MB2903; H:DB6PR0602MB2805.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: sky.uk does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xJ9bKsHFcpbP7APwwP8nm1MBCz12SHXSJNGnMxnGIi8otpuINDQK7ctNMBGHwX+6LXz/0VPL/3gumtWIOGAT5wO8Mxz1H1gHxKKbLeY/608wsQ1pN93hRk5xOY6pSb8wsHUE6PIOUlr662+osd6PujXPRyNBb99S3McELxAOTLGCjWFMHpEZVnxQWnK0dYHyUHJKBXTVckxLU6eO+QjJoMX4GK8wGjByC2NEYvOx8l9oP227T3bR4b99q+kjGBPi/5uisshe4b8prsGMbiGzpckxuUNsN1m4Ezzg4IM+UCxTunD4RwtPwytZ9lp9IBARtudnXeiJa7drY0gn/dWSNea4QLGqQ/YQ+bSeiVWXS+2esmKSS/ck+0jGU8q/Xvx9FVF/MQR5P6bXGcAKa5NplZYLiJnKEZb3Cdc22/E9ktaavRc4+csOkk95IBiGdaDb x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: sky.uk X-MS-Exchange-CrossTenant-Network-Message-Id: 1a1ce855-6ea2-4610-cd6d-08d769085343 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2019 13:41:17.2402 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 68b865d5-cf18-4b2b-82a4-a4eddb9c5237 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: f6nf3/vOdmDMJAG2lKjzaNt8O9DxBpMtXLkLNQH4fVnTH7py8Z1LfD3ZujPBQikac0LY7wuLMr/G+JI3h/C35w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0602MB2903 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: ABCD BoF agenda items, pervasive monitoring and privacy 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, 14 Nov 2019 13:41:25 -0000 RHVja3MgYXJlIGJpcmRzDQpEdWNrcyBhcmUgZGVmaW5lZCB7dGh1c2x5fQ0KU29tZSB0aGluZ3Mg dGhhdCBtYXRjaCB7dGh1c2x5fSBhcmUgaW4gZmFjdCBub3QgZHVja3MuICBPciB0aGV5IGFyZSBk dWNrcyBidXQgdGhleSdyZSBub3QgYWN0dWFsbHkgYmlyZHMuDQotLS0NCkVpdGhlciB7dGh1c2x5 fSBpcyBpbnN1ZmZpY2llbnRseSBwcmVjaXNlLCBhbmQgaGVuY2Ugbm90IHVzZWZ1bCBmb3IgYW5p bWFsIHRheG9ub215LCBvciB0aGUgdGl0bGUgc2hvdWxkIGJlICJTb21lIGR1Y2tzIGFyZSBiaXJk cyINCg0KSA0KDQrvu79PbiAxNC8xMS8yMDE5LCAwMDo1MSwgIlN0ZXBoZW4gRmFycmVsbCIgPHN0 ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU+IHdyb3RlOg0KDQoNCiAgICBIaXlhLA0KDQogICAgT24g MTQvMTEvMjAxOSAwMDoyNCwgQnJpYW4gRGlja3NvbiB3cm90ZToNCiAgICA+IEJhc2ljYWxseSwg dGhpcyBkaXJlY3RseSByZWZ1dGVzIHdoYXQgeW91IHdyaXRlIGFib3V0ICJjb25zZW50IiwNCg0K ICAgIFlvdSBhcmUgaW5jb3JyZWN0Lg0KDQogICAgU28tY2FsbGVkICJjb25zZW50IiAoYXMgdGhl IHRlcm0gaXMgYWJ1c2VkIGluIGNvbXB1dGluZykNCiAgICByYXJlbHkgaWYgZXZlciBoYXMgYW55 dGhpbmcgdG8gZG8gd2l0aCBob3cgYSB1c2VyJ3MgZGF0YQ0KICAgIGlzIHRyZWF0ZWQuIEluIGFw cHJveC4gMTAwJSBvZiBjYXNlcyAoY291bnRpbmcgc2F5IHVzZXINCiAgICBhY3Rpb25zKSByZWxl dmFudCB0byB0aGlzIGRpc2N1c3Npb24sIHNvLWNhbGxlZCAiY29uc2VudCINCiAgICBpcyBhbiBh dHRlbXB0IHRvIHRyaWNrIHVzZXJzIGludG8gc2F5aW5nICJ5ZXMiIGFuZCByZWFsbHkNCiAgICBu b3RoaW5nIG1vcmUuDQoNCiAgICA+IGFuZCBpcw0KICAgID4gcmVmZXJlbmNlZCBieSA3MjU4IGlu IGEgd2F5IHRoYXQgYXQgbGVhc3Qgc3VnZ2VzdHMgaXQgaXMgbW9yZSBhdXRob3JpdGF0aXZlLg0K DQogICAgTm8uIDcyNTggaXMgYSBCQ1Agd2l0aCBJRVRGIGNvbnNlbnN1cywgNjc5MyBpcyBhbiBJ QUINCiAgICBzdHJlYW0gaW5mb3JtYXRpb25hbCBSRkMgYW5kIHJlZmxlY3RzIHRoZSBvcGluaW9u IG9mIHRoZQ0KICAgIElBQiBtZW1iZXJzIGF0IHRoYXQgdGltZS4gKEFzIGl0IGhhcHBlbnMsIEkg bGlrZSBtb3N0IG9mDQogICAgdGhlIHRleHQsIGFuZCB0aGluayBpdCdkIGJlIGEgZmluZSB0aGlu ZyBpZiB0aGUgSUVURiBoYWQgYQ0KICAgIEJDUCBvbiB0aGF0IHN1YmplY3QuKQ0KDQogICAgPg0K ICAgID4gSXQgZG9lc24ndCBoYXZlIHRvIGJlIGxhYmVsZWQgYXMgImNvbnNlbnQiIHRvIGFjdHVh bGx5IGJlIGNvbnNlbnQsDQoNCiAgICBQZXJoYXBzLiBNeSBwb2ludCBpcyBkaWZmZXJlbnQ6IEkg Y2xhaW0gdGhhdCB3aGF0IGlzIHRlcm1lZA0KICAgICJjb25zZW50IiBpbiBjb21wdXRpbmcsIHRo ZSBJbnRlcm5ldCBhbmQgdGhlIHdlYiBpcyByZWFsbHkgOTklIGEgbG9hZCBvZg0KICAgIGxhd3ll cmx5IG9iZnVzY2F0b3J5IGNyYXAgYW5kIG5vdGhpbmcgdG8gZG8NCiAgICB3aXRoIGNvbnNlbnQu DQoNCiAgICA+IGFuZCB0aGlzDQogICAgPiBkaXNjdXNzaW9uIG9mIGdvYWxzIGFuZCBtZXRob2Rz LCByZWdhcmRpbmcgaW5mb3JtaW5nIHVzZXJzIGFuZCBwcm92aWRpbmcNCiAgICA+IGNvbnRyb2wg YW5kIHNpZ25hbGluZyBpbnRlbnQsIHNlZW1zIHRvIGNvdmVyIHRoZSBpc3N1ZSB2ZXJ5IHN1Y2Np bmN0bHkuIE5vDQogICAgPiBtZWFucyBubywgYnV0IHllcyBtZWFucyB5ZXMuDQogICAgPg0KICAg ID4gSXQgZG9lcyBhcHBlYXIgdG8gaW1wbHkgdGhlIG5lZWQgZm9yIGV4cGxpY2l0IGNvbnNlbnQs IHNvIEknZCBhZ3JlZSB3aXRoDQogICAgPiBleGNsdWRpbmcgaW1wbGllZCBjb25zZW50IGFzIGFu IGFjY2VwdGFibGUgbWVjaGFuaXNtLg0KICAgID4NCiAgICA+IEJ1dCB0aGF0IGlzIGRpZmZlcmVu dCBmcm9tIGFzc2VydGluZyB0aGF0IGV4cGxpY2l0IGNvbnNlbnQgaXNuJ3QgcmVhbGx5DQogICAg PiBwb3NzaWJsZS4NCiAgICA+DQogICAgPiAoSWYgeW91IGRpZG4ndCBhZ3JlZSB3aXRoIHdoYXQg d2FzIGluIDY5NzMsIG1heWJlIHlvdSBzaG91bGRuJ3QgaGF2ZQ0KICAgID4gaW5jbHVkZWQgYSBy ZWZlcmVuY2UgdG8gaXQsIG9yIHNob3VsZCBtYXliZSBoYXZlIGNhbGxlZCBvdXQgdGhlIHNlY3Rp b24gb24NCiAgICA+IFVzZXIgUGFydGljaXBhdGlvbiBhcyBhIHByb2JsZW0uKQ0KDQogICAgNzI1 OCBpcyBub3QgIm15IiBkb2N1bWVudCAtIEkgd2FzIHRoZSBlZGl0b3IuIEJ1dCBzZWUgYWJvdmUN CiAgICByZWxhdGluZyB0byB0aGUgZm9ybWFsaXRpZXMuDQoNCiAgICBCdXQgSSB0aGluayB3ZSdy ZSB3YW5kZXJpbmcgb2ZmIHRvcGljIG5vdy4NCg0KICAgIENoZWVycywNCiAgICBTLg0KDQoNCg0K DQpJbmZvcm1hdGlvbiBpbiB0aGlzIGVtYWlsIGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMgbWF5 IGJlIHByaXZpbGVnZWQsIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZXhjbHVzaXZlbHkg Zm9yIHRoZSBhZGRyZXNzZWUuIFRoZSB2aWV3cyBleHByZXNzZWQgbWF5IG5vdCBiZSBvZmZpY2lh bCBwb2xpY3ksIGJ1dCB0aGUgcGVyc29uYWwgdmlld3Mgb2YgdGhlIG9yaWdpbmF0b3IuIElmIHlv dSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYnkg cmV0dXJuIGUtbWFpbCBhbmQgZGVsZXRlIGl0IGZyb20geW91ciBzeXN0ZW0uIFlvdSBzaG91bGQg bm90IHJlcHJvZHVjZSwgZGlzdHJpYnV0ZSwgc3RvcmUsIHJldHJhbnNtaXQsIHVzZSBvciBkaXNj bG9zZSBpdHMgY29udGVudHMgdG8gYW55b25lLiBQbGVhc2Ugbm90ZSB3ZSByZXNlcnZlIHRoZSBy aWdodCB0byBtb25pdG9yIGFsbCBlLW1haWwgY29tbXVuaWNhdGlvbiB0aHJvdWdoIG91ciBpbnRl cm5hbCBhbmQgZXh0ZXJuYWwgbmV0d29ya3MuIFNLWSBhbmQgdGhlIFNLWSBtYXJrcyBhcmUgdHJh ZGVtYXJrcyBvZiBTa3kgTGltaXRlZCBhbmQgU2t5IEludGVybmF0aW9uYWwgQUcgYW5kIGFyZSB1 c2VkIHVuZGVyIGxpY2VuY2UuDQoNClNreSBVSyBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8uIDI5 MDY5OTEpLCBTa3ktSW4tSG9tZSBTZXJ2aWNlIExpbWl0ZWQgKFJlZ2lzdHJhdGlvbiBOby4gMjA2 NzA3NSksIFNreSBTdWJzY3JpYmVycyBTZXJ2aWNlcyBMaW1pdGVkIChSZWdpc3RyYXRpb24gTm8u IDIzNDAxNTApIGFuZCBTa3kgQ1AgTGltaXRlZCAoUmVnaXN0cmF0aW9uIE5vLiA5NTEzMjU5KSBh cmUgZGlyZWN0IG9yIGluZGlyZWN0IHN1YnNpZGlhcmllcyBvZiBTa3kgTGltaXRlZCAoUmVnaXN0 cmF0aW9uIE5vLiAyMjQ3NzM1KS4gQWxsIG9mIHRoZSBjb21wYW5pZXMgbWVudGlvbmVkIGluIHRo aXMgcGFyYWdyYXBoIGFyZSBpbmNvcnBvcmF0ZWQgaW4gRW5nbGFuZCBhbmQgV2FsZXMgYW5kIHNo YXJlIHRoZSBzYW1lIHJlZ2lzdGVyZWQgb2ZmaWNlIGF0IEdyYW50IFdheSwgSXNsZXdvcnRoLCBN aWRkbGVzZXggVFc3IDVRRA0K From nobody Thu Nov 14 10:14:35 2019 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 94358120108 for ; Thu, 14 Nov 2019 10:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.5 X-Spam-Level: X-Spam-Status: No, score=-17.5 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HzZckgAh323b for ; Thu, 14 Nov 2019 10:14:30 -0800 (PST) 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 9A225120100 for ; Thu, 14 Nov 2019 10:14:30 -0800 (PST) Received: by mail-io1-xd2c.google.com with SMTP id k1so7874976ioj.6 for ; Thu, 14 Nov 2019 10:14:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jJ5KXTKuQH4js8QeZ3M+YmEKAF1whJLPrExEPm2P3Jo=; b=BP3OBN9uWvjXWQqk5ad6cGKa1tPOW7YLv3lmTjzigE945RVpjrl4V8p+S78ppxLEM6 5ts8MzBp9IUcNepEvX7gF+vkrHwcrVAj5mqqsuyE4fcDV/WU23ij0Q3+y5FAAuZI9mn/ MVKTMYlpnK3Dfhgsb2Q4UhZJmYhdW+mkzCtLTU9CdcjZ+Xn6iemWWW0CD8JJF/wi8yGh gD2dLMvY6Cm22woIZOZ9Pn1dhK84eYWwefNFWwszKq3lE3lOwMfr1sFqKGeNbq4C65Ef ktESVhb4Xfv3xjVXtyUlMXt6Ah/txxW2WGMi9czT+CokAJU8hD/nHx8kVXQdyU1Ij62B yFVw== 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=jJ5KXTKuQH4js8QeZ3M+YmEKAF1whJLPrExEPm2P3Jo=; b=f5RElRaxapD9R9Ub2LMAj0orK0UcpewNm0LqB1Shtm7JaL3ieu8SC5TzRKTbMa5asg poeSbT7RXXDF9/cpgZRxqj/xH8+bHvEdy/gYL8wh9zC7gCRsE/np1JWkKfJl4KoHn7p0 zWYG+MmRHOZg/67Rtu2qAivCVhSqwmHS2puWONyCLuT2BBqZEpNjpDwZWKdJg9C1gewp d0+UX8nwNUk8DVH2XKTU/CJHNybMYgp502+6Nf1xz1FmZ6brcbysOT++Ej0at85wAUs8 zHdQFthI+op+7hJwec4/vhsTGDVDmmuQ+KGq6pEGSijvmC/Rz4mNQHMWOwkwND2T6iKb 9XpA== X-Gm-Message-State: APjAAAUa/UhzoAMhEoCzC+EmtUtdw9K/6HXI2XdpCb9PHQZuPu054Iq+ 5Vy9Gm98ljxFdDu2TfU8oCuC7FJlVX67X2qv3RMjppfu3fk= X-Google-Smtp-Source: APXvYqxKKId+rLXmoax+rfI57K9Xs9b8uPDNu0sNGxfi4hMC6viHMfb37AhNQsvs5vMHjteX22G5NlNzV17k8DxBLN0= X-Received: by 2002:a5d:9349:: with SMTP id i9mr9801540ioo.163.1573755269433; Thu, 14 Nov 2019 10:14:29 -0800 (PST) MIME-Version: 1.0 References: <254AEFB0-F930-466B-8BB6-707D5CE72657@fl1ger.de> In-Reply-To: <254AEFB0-F930-466B-8BB6-707D5CE72657@fl1ger.de> From: Ben Schwartz Date: Thu, 14 Nov 2019 13:14:17 -0500 Message-ID: To: Ralf Weber Cc: ADD Mailing list Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000d670c70597527348" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 14 Nov 2019 18:14:34 -0000 --000000000000d670c70597527348 Content-Type: multipart/alternative; boundary="000000000000cc9c4205975273d9" --000000000000cc9c4205975273d9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Nov 14, 2019 at 7:42 AM Ralf Weber wrote: > Moin! > > On 13 Nov 2019, at 2:32, Ben Schwartz wrote: > > Please review the agenda and proposed charter, and join us next week > > for a > > full discussion. > From the proposed charter: > > This working group will consider technical drafts on DNS client > > configuration, especially with a focus on the following items where > > technical consensus seems obtainable: > > > > - Communicating configuration between the network, operating system, > > and > > applications > > - Discovery of resolvers and their capabilities and behaviors > > - Query routing in a multi-resolver environment > This is ambiguous. I think this is very closely related to the next entry on the list, so we should understand them together. Perhaps they should be combined > If it describes the current /etc/resolv.conf that=E2=80=99s > fine, That would be in-scope (and there has been some innovation here related to retry behavior, load spreading, etc. which could be documented). but I fear that it describes something where you ask =E2=80=9Cresolver > A=E2=80=9D for example.com and =E2=80=9Cresolver B=E2=80=9D for example.n= et. I think designs of this kind would also be in-scope. > I don=E2=80=99t think that there is consensus for such an approach. > I don't think there is a single approach here; it seems to me that there is a vast range of possible client behaviors related to multiple resolvers. Recommending a single behavior universally might be controversial, but I think there is plenty of room for productive technical discussion in this area without triggering reflexive disagreement. > > - Multiple non-equivalent query paths, such as split-horizon DNS or > > geo-sensitive answers > As an example of the kinds of issues that come up here, consider Mozilla's default behavior [1], in which an NXDOMAIN response from the primary resolution path triggers a retry of the query on a second resolution path. This is an interesting choice with particular privacy, security, compatibility, and performance properties. Perhaps it's worth specifying this solution in more detail, or perhaps defining a range of solutions with different properties. I believe we can discuss the properties of different stub state-machines without debating Mozilla's method for choosing the primary resolver. [1] https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_how-does-fir= efox-handle-split-horizon-dns > > - Local DNS caches (e.g. partitioning, use of stale records) > > - Resilience and fault-tolerance (e.g. single points of failure) > > - Support for debugging and analysis > > - DNS Push (accepting responses to queries that have not yet been > > issued) > Same thing I don=E2=80=99t think that there is consensus on this. We don't need consensus that a topic is worthwhile in order to include it in a working group charter. We merely need to believe that there is some positive interest and potential for a technical consensus to emerge without derailing the working group's other topics. > I personally > think it is a bad idea, but I seem to recall from earlier discussions > that others agreed with me. IMHO this belongs in the relevant, but more > challenging for consensus building category. > I don't think this topic is particularly controversial, and versions of this idea have been considered previously without major incident, e.g. [2]. This is purely a performance question; there is little security relevance, because we are speaking about answers delivered from the same resolver and query path as all the other DNS responses. In any case, RFC 8484 DoH already defines DNS Push (Section 5.3), along with some rules about when it cannot be used. It does not, however, provide any additional guidance that might support practical use, and has some significant limitations. Including this topic would allow us to improve the specification of DNS Push, or indeed deprecate it if that is the technical consensus. [2] https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05 So long > -Ralf > =E2=80=94-- > Ralf Weber > --000000000000cc9c4205975273d9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Thu, Nov 14, 2019 at 7:42 AM Ralf = Weber <dns@fl1ger.de> wrote:
=
Moin!

On 13 Nov 2019, at 2:32, Ben Schwartz wrote:
> Please review the agenda and proposed charter, and join us next week <= br> > for a
> full discussion.
=C2=A0From the proposed charter:
> This working group will consider technical drafts on DNS client
> configuration, especially with a focus on the following items where > technical consensus seems obtainable:
>
> - Communicating configuration between the network, operating system, <= br> > and
> applications
> - Discovery of resolvers and their capabilities and behaviors
> - Query routing in a multi-resolver environment
This is ambiguous.

I think this is ver= y closely related to the next entry on the list, so we should understand th= em together.=C2=A0 Perhaps they should be combined
=C2=A0
If it des= cribes the current /etc/resolv.conf that=E2=80=99s
fine,

That would be in-scope (and there has= been some innovation here related to retry behavior, load spreading, etc.= =C2=A0which could be documented).

but I fear that it describes something where = you ask =E2=80=9Cresolver
A=E2=80=9D for example.com and =E2=80=9Cresolver B=E2=80=9D for example.net.

I think designs of this kind would also be in-s= cope.
=C2=A0
I don=E2=80=99t think that there is consensus for such an approach.=

I don't think there is a single ap= proach here; it seems to me that there is a vast range of possible client b= ehaviors related to multiple resolvers.=C2=A0 Recommending a single behavio= r universally might be controversial, but I think there is plenty of room f= or productive technical discussion in this area without triggering reflexiv= e disagreement.
=C2=A0
> - Multiple non-equivalent query paths, such as split-horizon DNS or > geo-sensitive answers

As an exampl= e of the kinds of issues that come up here, consider Mozilla's default = behavior [1], in which an NXDOMAIN response from the primary resolution pat= h triggers a retry of the query on a second resolution path.=C2=A0 This is = an interesting choice with particular privacy, security, compatibility, and= performance properties.=C2=A0 Perhaps it's worth specifying this solut= ion in more detail, or perhaps defining a range of solutions with different= properties.=C2=A0 I believe we can discuss the properties of different stu= b state-machines without debating Mozilla's method for choosing the pri= mary resolver.

=C2=A0
> - Local DNS caches (e.g. partitioning, use of stale records)
> - Resilience and fault-tolerance (e.g. single points of failure)
> - Support for debugging and analysis
> - DNS Push (accepting responses to queries that have not yet been
> issued)
Same thing I don=E2=80=99t think that there is consensus on this.

We don't need consensus that a topic is worthwhi= le in order to include it in a working group charter.=C2=A0 We merely need = to believe that there is some positive interest and potential for a technic= al consensus to emerge without derailing the working group's other topi= cs.
=C2=A0
I personally
think it is a bad idea, but I seem to recall from earlier discussions
that others agreed with me. IMHO this belongs in the relevant, but more challenging for=C2=A0 consensus building category.
I don't think this topic is particularly controversial, and= versions of this idea have been considered previously without major incide= nt, e.g. [2].=C2=A0 This is purely a performance question; there is little = security relevance, because we are speaking about answers delivered from th= e same resolver and query path as all the other DNS responses.
In any case, RFC 8484 DoH already defines DNS Push (Section 5.= 3), along with some rules about when it cannot be used.=C2=A0 It does not, = however, provide any additional guidance that might support practical use, = and has some significant limitations.=C2=A0 Including this topic would allo= w us to improve the specification of DNS Push, or indeed deprecate it if th= at is the technical consensus.

<= /div>
So long
-Ralf
=E2=80=94--
Ralf Weber
--000000000000cc9c4205975273d9-- --000000000000d670c70597527348 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIIS5wYJKoZIhvcNAQcCoIIS2DCCEtQCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0BBwGg ghBNMIIEXDCCA0SgAwIBAgIOSBtqDm4P/739RPqw/wcwDQYJKoZIhvcNAQELBQAwZDELMAkGA1UE BhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVy c29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hBMjU2IC0gRzIwHhcNMTYwNjE1MDAwMDAwWhcNMjEw NjE1MDAwMDAwWjBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEiMCAG A1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCC AQoCggEBALR23lKtjlZW/17kthzYcMHHKFgywfc4vLIjfq42NmMWbXkNUabIgS8KX4PnIFsTlD6F GO2fqnsTygvYPFBSMX4OCFtJXoikP2CQlEvO7WooyE94tqmqD+w0YtyP2IB5j4KvOIeNv1Gbnnes BIUWLFxs1ERvYDhmk+OrvW7Vd8ZfpRJj71Rb+QQsUpkyTySaqALXnyztTDp1L5d1bABJN/bJbEU3 Hf5FLrANmognIu+Npty6GrA6p3yKELzTsilOFmYNWg7L838NS2JbFOndl+ce89gM36CW7vyhszi6 6LqqzJL8MsmkP53GGhf11YMP9EkmawYouMDP/PwQYhIiUO0CAwEAAaOCASIwggEeMA4GA1UdDwEB /wQEAwIBBjAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIB ADAdBgNVHQ4EFgQUyzgSsMeZwHiSjLMhleb0JmLA4D8wHwYDVR0jBBgwFoAUJiSSix/TRK+xsBtt r+500ox4AAMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC5nbG9iYWxzaWduLmNvbS9ncy9n c3BlcnNvbmFsc2lnbnB0bnJzc2hhMmcyLmNybDBMBgNVHSAERTBDMEEGCSsGAQQBoDIBKDA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzANBgkqhkiG 9w0BAQsFAAOCAQEACskdySGYIOi63wgeTmljjA5BHHN9uLuAMHotXgbYeGVrz7+DkFNgWRQ/dNse Qa4e+FeHWq2fu73SamhAQyLigNKZF7ZzHPUkSpSTjQqVzbyDaFHtRBAwuACuymaOWOWPePZXOH9x t4HPwRQuur57RKiEm1F6/YJVQ5UTkzAyPoeND/y1GzXS4kjhVuoOQX3GfXDZdwoN8jMYBZTO0H5h isymlIl6aot0E5KIKqosW6mhupdkS1ZZPp4WXR4frybSkLejjmkTYCTUmh9DuvKEQ1Ge7siwsWgA NS1Ln+uvIuObpbNaeAyMZY0U5R/OyIDaq+m9KXPYvrCZ0TCLbcKuRzCCBB4wggMGoAMCAQICCwQA AAAAATGJxkCyMA0GCSqGSIb3DQEBCwUAMEwxIDAeBgNVBAsTF0dsb2JhbFNpZ24gUm9vdCBDQSAt IFIzMRMwEQYDVQQKEwpHbG9iYWxTaWduMRMwEQYDVQQDEwpHbG9iYWxTaWduMB4XDTExMDgwMjEw MDAwMFoXDTI5MDMyOTEwMDAwMFowZDELMAkGA1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24g bnYtc2ExOjA4BgNVBAMTMUdsb2JhbFNpZ24gUGVyc29uYWxTaWduIFBhcnRuZXJzIENBIC0gU0hB MjU2IC0gRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCg/hRKosYAGP+P7mIdq5NB Kr3J0tg+8lPATlgp+F6W9CeIvnXRGUvdniO+BQnKxnX6RsC3AnE0hUUKRaM9/RDDWldYw35K+sge C8fWXvIbcYLXxWkXz+Hbxh0GXG61Evqux6i2sKeKvMr4s9BaN09cqJ/wF6KuP9jSyWcyY+IgL6u2 52my5UzYhnbf7D7IcC372bfhwM92n6r5hJx3r++rQEMHXlp/G9J3fftgsD1bzS7J/uHMFpr4MXua eoiMLV5gdmo0sQg23j4pihyFlAkkHHn4usPJ3EePw7ewQT6BUTFyvmEB+KDoi7T4RCAZDstgfpzD rR/TNwrK8/FXoqnFAgMBAAGjgegwgeUwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8C AQEwHQYDVR0OBBYEFCYkkosf00SvsbAbba/udNKMeAADMEcGA1UdIARAMD4wPAYEVR0gADA0MDIG CCsGAQUFBwIBFiZodHRwczovL3d3dy5nbG9iYWxzaWduLmNvbS9yZXBvc2l0b3J5LzA2BgNVHR8E LzAtMCugKaAnhiVodHRwOi8vY3JsLmdsb2JhbHNpZ24ubmV0L3Jvb3QtcjMuY3JsMB8GA1UdIwQY MBaAFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQACAFVjHihZCV/IqJYt 7Nig/xek+9g0dmv1oQNGYI1WWeqHcMAV1h7cheKNr4EOANNvJWtAkoQz+076Sqnq0Puxwymj0/+e oQJ8GRODG9pxlSn3kysh7f+kotX7pYX5moUa0xq3TCjjYsF3G17E27qvn8SJwDsgEImnhXVT5vb7 qBYKadFizPzKPmwsJQDPKX58XmPxMcZ1tG77xCQEXrtABhYC3NBhu8+c5UoinLpBQC1iBnNpNwXT Lmd4nQdf9HCijG1e8myt78VP+QSwsaDT7LVcLT2oDPVggjhVcwljw3ePDwfGP9kNrR+lc8XrfClk WbrdhC2o4Ui28dtIVHd3MIIDXzCCAkegAwIBAgILBAAAAAABIVhTCKIwDQYJKoZIhvcNAQELBQAw TDEgMB4GA1UECxMXR2xvYmFsU2lnbiBSb290IENBIC0gUjMxEzARBgNVBAoTCkdsb2JhbFNpZ24x EzARBgNVBAMTCkdsb2JhbFNpZ24wHhcNMDkwMzE4MTAwMDAwWhcNMjkwMzE4MTAwMDAwWjBMMSAw HgYDVQQLExdHbG9iYWxTaWduIFJvb3QgQ0EgLSBSMzETMBEGA1UEChMKR2xvYmFsU2lnbjETMBEG A1UEAxMKR2xvYmFsU2lnbjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMwldpB5Bngi FvXAg7aEyiie/QV2EcWtiHL8RgJDx7KKnQRfJMsuS+FggkbhUqsMgUdwbN1k0ev1LKMPgj0MK66X 17YUhhB5uzsTgHeMCOFJ0mpiLx9e+pZo34knlTifBtc+ycsmWQ1z3rDI6SYOgxXG71uL0gRgykmm KPZpO/bLyCiR5Z2KYVc3rHQU3HTgOu5yLy6c+9C7v/U9AOEGM+iCK65TpjoWc4zdQQ4gOsC0p6Hp sk+QLjJg6VfLuQSSaGjlOCZgdbKfd/+RFO+uIEn8rUAVSNECMWEZXriX7613t2Saer9fwRPvm2L7 DWzgVGkWqQPabumDk3F2xmmFghcCAwEAAaNCMEAwDgYDVR0PAQH/BAQDAgEGMA8GA1UdEwEB/wQF MAMBAf8wHQYDVR0OBBYEFI/wS3+oLkUkrk1Q+mOai97i3Ru8MA0GCSqGSIb3DQEBCwUAA4IBAQBL QNvAUKr+yAzv95ZURUm7lgAJQayzE4aGKAczymvmdLm6AC2upArT9fHxD4q/c2dKg8dEe3jgr25s bwMpjjM5RcOO5LlXbKr8EpbsU8Yt5CRsuZRj+9xTaGdWPoO4zzUhw8lo/s7awlOqzJCK6fBdRoyV 3XpYKBovHd7NADdBj+1EbddTKJd+82cEHhXXipa0095MJ6RMG3NzdvQXmcIfeg7jLQitChws/zyr VQ4PkX4268NXSb7hLi18YIvDQVETI53O9zJrlAGomecsMx86OyXShkDOOyyGeMlhLxS67ttVb9+E 7gUJTb0o2HLO02JQZR7rkpeDMdmztcpHWD9fMIIEZDCCA0ygAwIBAgIMb5MwaN/thbS6tcoSMA0G CSqGSIb3DQEBCwUAMEwxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMSIw IAYDVQQDExlHbG9iYWxTaWduIEhWIFMvTUlNRSBDQSAxMB4XDTE5MDgxMDA4MjIyMVoXDTIwMDIw NjA4MjIyMVowIjEgMB4GCSqGSIb3DQEJAQwRYmVtYXNjQGdvb2dsZS5jb20wggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQCapo7ARc1spX97SqdC5FrntcF1TsMY92BYdzbflXSKxq0yT835 3LNJtJ/J4lZC5QSgloRVy9U70CWQVLQUY+kXzFrEZkpgnHAtnlqZITjGGCj7+RAjWXbRHdOtvA/t EJKQJjEsuggE8qjMH2FoThWpOoAFfvLSw8aSir96C2tA8MV59tyI8ewdRBWKvQT6QTLPpPFmKJPJ H1idNM5tnwsWzADF6Xmz2tdLu4Nec4bGyzwHv4jGWrMfW6i5XO3cxFDLluvf7J6A2m+85dRtTC5q 2eqFRCpqqDsHcxsd8OFxpEe9ZhRw1XcMPjZmqHEPpJToDt9ReYetEffXx5DNqIcHAgMBAAGjggFu MIIBajAcBgNVHREEFTATgRFiZW1hc2NAZ29vZ2xlLmNvbTBQBggrBgEFBQcBAQREMEIwQAYIKwYB BQUHMAKGNGh0dHA6Ly9zZWN1cmUuZ2xvYmFsc2lnbi5jb20vY2FjZXJ0L2dzaHZzbWltZWNhMS5j cnQwHQYDVR0OBBYEFE77YQLCDddBAx5p+gBVO6KLah3VMB8GA1UdIwQYMBaAFMs4ErDHmcB4koyz IZXm9CZiwOA/MEwGA1UdIARFMEMwQQYJKwYBBAGgMgEoMDQwMgYIKwYBBQUHAgEWJmh0dHBzOi8v d3d3Lmdsb2JhbHNpZ24uY29tL3JlcG9zaXRvcnkvMDsGA1UdHwQ0MDIwMKAuoCyGKmh0dHA6Ly9j cmwuZ2xvYmFsc2lnbi5jb20vZ3NodnNtaW1lY2ExLmNybDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMA0GCSqGSIb3DQEBCwUAA4IBAQAW/09trVYeHUY5xMK3 1EuuFQyc7RaPOn+3qWJuDt4DVjNJl0uH27JsA30H70YGSPgNLo/KtC/1ejCAF2SjJrL+Qb93j4Cq BLI0djN/I9AHm7BVy4l+evwS6/7b8xwhKZSt+b2FuMSdpYRfxavlFKYo+WILW6gGx15o+KDRPusJ mo2s2mZDRTUfZ9e87SLTOUe/APBMIeKd+2Z9nnnBh0+d4LCn3tA4vmD1A/pIubUYaaTlLeZIQhpa D41mXEZUHdUVnGaIdPzJKNSkCeIUztyVBUJyYk3ROz9bCBjsHcUy2iqwuLGLaPI3bWjdwvxZ4kG4 dhjPuHq6t95sxpJ1F1X/MYICXjCCAloCAQEwXDBMMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xv YmFsU2lnbiBudi1zYTEiMCAGA1UEAxMZR2xvYmFsU2lnbiBIViBTL01JTUUgQ0EgMQIMb5MwaN/t hbS6tcoSMA0GCWCGSAFlAwQCAQUAoIHUMC8GCSqGSIb3DQEJBDEiBCD4AdiwuiMVmsnEdreJlRrv cSoQDjQdMNHhK3ENJNNAIzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xOTExMTQxODE0MzBaMGkGCSqGSIb3DQEJDzFcMFowCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQB FjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwCwYJKoZIhvcNAQEKMAsGCSqGSIb3DQEBBzALBglg hkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAEggEAcWN0QUY33BnRG/v+36GJtc2z5AaD6d1GIgofnD0e lFjp7CJTxmJIjbEuiVq27hGaigNFnHHw53fqdOibiI/NWKkazFFk1z0/oL8JaFuegLQQMNuoKD5q neR9m8pkd2Zw/h41WNlSoHJhwFL5qo+wCJucWU2qnZ30IO96KmTUYj4PUwnfQHRZVWTLqTnUGbZk rlW/tg9TTZ1ActNFdN3lsGKTsatGvKb8XiJGLQ1YzpYmqayaXg4HDQVat/DiPrqDyLf0m1Mj1RHw x+gqkPm6JLVZsYmdY/VOfGJ+8D5morMikBXVOBpWewNxAz4hmV0oCZtuaCfm5x4ArhCFlzMsWw== --000000000000d670c70597527348-- From nobody Fri Nov 15 21:05:34 2019 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 6CEDE12007C for ; Fri, 15 Nov 2019 21:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=pzhZC8EM; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=s72LRh2k 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 kiNlQvniXnZu for ; Fri, 15 Nov 2019 21:05:29 -0800 (PST) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 595CC1200B6 for ; Fri, 15 Nov 2019 21:05:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1573880729; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=O7MGJICZ4meRx9/11EeaEbP1FIqmxCjsZknVxpkD3q8LbbST5XTInJWd1dgwjgoOZEbgVf0pFeYI8 Qvu7HLnkT5mq1eI0QbbH1Jy5+e1AWJEOGPlJuZm6k1Ri22Vsvv6dtQVCEOZYpZJ9JdYIpvoDA+6wTW DtAmdGLyW7JEoZxVZZnO8yIlBHC2J315qrx/uNB7ImaaHmCFeF4V14fatcNnOaj507yh8T1EkdU9z6 AC2Hj/2hNkPCO946Zr3t9gfd60Uz5mURZo+QrPen30f9F1mLispbqwMlzGUZYG/9Y+zJH5dKTf7KHE 3samFK9kQNW9tuJQgYxE4xPQQiExakA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=CK9pfvhTOPCHl7n+GsdnWvNVMOkTBekmBAKqW9Yr3vk=; b=GkJbP5ERdoxOIog9Pq2kiJkmKX4n/C0TIkQCCsbt6h3NU4aUAFW3zhziEHYAkLvM2fIpZjUvQRhFB l7mm28IFP95q0EP24v1c2EGBlfWtjQ6fFZkhgDxIhTWoDKbSrbhjuqHdWeRu6DXjhZhpyoI8C5ajvY isPrIQG/P2B9SuaPt6czg9JCY5vneMvANLaFog9n2dgZgVx974L6K4245vTmcP8Y/J3xaQvDGijycF J0if1Vr+/wc4Lvzc6RmTxGk6gsPRhptT5KB9DhNxGPC1K356RaaoLl6pcAp4rXtPcTIbofIa69QW/+ 1Yy+wGwcQOViyxk4Hs6flXhw6lmPnwA== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.180; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=CK9pfvhTOPCHl7n+GsdnWvNVMOkTBekmBAKqW9Yr3vk=; b=pzhZC8EMdYm5e5nK7L3OioXQ2Q8HWF2i5Sfl+GkOxHW7Hq8tf0UcAyCilsqc5mrrd2fJWJYN2Iycv LTV2EkJjP7uVhpXkfnWpQ4sz9FeiijonDedLJXqr5CaNepejWcNu8Vrm+ZC2bVKJI+n9NqkCaB+aPa dmYj1/K7P1J2bkEI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=CK9pfvhTOPCHl7n+GsdnWvNVMOkTBekmBAKqW9Yr3vk=; b=s72LRh2kqOHXKOw0WhtPWBmzf3V2/Kg635JDPKQR1eHpW+J+JARILhmkytukHfy09YBWTs/wCO1sm yl2XulJM77olLhBXTgql/+MdqTlsRmRca5Yvw91WjF5s0XIzRraVEfp+5RPYHENwiAPDNKNE6FyQzd CK0LC/v/JCQP0p+ltdjSJBnwJH4bA60cmPPvwX30jVgqRSL1kJW9awJnYKV+xTB7rkq1SFcZ0YD0qy ikMKUEAvQp1DfTXlUIq6AuQF86dHlxr7byM4nzBs2A6g4FbIWtWg0WGY3+c9tO437Q9POtr2zg19Wp C/uPgxGYTpq/HB9pKCFB7UFlDYQku9g== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: b38810ac-082e-11ea-b80c-052b4a66b6b2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.167.180 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f180.google.com (unknown [209.85.167.180]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id b38810ac-082e-11ea-b80c-052b4a66b6b2; Sat, 16 Nov 2019 05:05:26 +0000 (UTC) Received: by mail-oi1-f180.google.com with SMTP id e9so10578518oif.8 for ; Fri, 15 Nov 2019 21:05:26 -0800 (PST) X-Gm-Message-State: APjAAAWfnbeb78fh7elxcF3cUjjUnizKsVLhA3+NMCDAtYJbV2SwvYYb ttWH2k2KQ8tAq/WSrFLlxZI1lTu4m0PW3FZg5zw= X-Google-Smtp-Source: APXvYqxqtFoKMSZpha5DNaFz5vb2t6drgbEznVqVpa7a4F1Up/HBXVJj9V42xsVHnKhLj7SslKC4tdmsI73CBdT0bnI= X-Received: by 2002:aca:adc1:: with SMTP id w184mr10277739oie.138.1573880725966; Fri, 15 Nov 2019 21:05:25 -0800 (PST) MIME-Version: 1.0 References: <254AEFB0-F930-466B-8BB6-707D5CE72657@fl1ger.de> In-Reply-To: From: Patrick McManus Date: Sat, 16 Nov 2019 00:05:13 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Ben Schwartz Cc: Ralf Weber , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000009718c805976fa9f7" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 16 Nov 2019 05:05:32 -0000 --0000000000009718c805976fa9f7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This charter just seems like a suggestion for a perpetual forum to argue and, afaict, isn't actually expected to produce anything.. it just has some things that if they were published would belong in the proposed wg. Please don't make us collectively relive the ADD side meeting every full meeting. My suggestion: If the proponents believe that a group can publish a document on (e.g.) "Communicating configuration between the network, operating system, and applications" please write a charter with that as the goal of the group and the BoF can do the usual thing of deciding whether that is a problem worth solving, is well understood, and has a chance of success. If it works out - recharter the group for new work. As is the charter fails those tests by putting everything in scope but requiring nothing at the same time. -Patrick On Thu, Nov 14, 2019 at 1:14 PM Ben Schwartz wrote: > > > On Thu, Nov 14, 2019 at 7:42 AM Ralf Weber wrote: > >> Moin! >> >> On 13 Nov 2019, at 2:32, Ben Schwartz wrote: >> > Please review the agenda and proposed charter, and join us next week >> > for a >> > full discussion. >> From the proposed charter: >> > This working group will consider technical drafts on DNS client >> > configuration, especially with a focus on the following items where >> > technical consensus seems obtainable: >> > >> > - Communicating configuration between the network, operating system, >> > and >> > applications >> > - Discovery of resolvers and their capabilities and behaviors >> > - Query routing in a multi-resolver environment >> This is ambiguous. > > > I think this is very closely related to the next entry on the list, so we > should understand them together. Perhaps they should be combined > > >> If it describes the current /etc/resolv.conf that=E2=80=99s >> fine, > > > That would be in-scope (and there has been some innovation here related t= o > retry behavior, load spreading, etc. which could be documented). > > but I fear that it describes something where you ask =E2=80=9Cresolver >> A=E2=80=9D for example.com and =E2=80=9Cresolver B=E2=80=9D for example.= net. > > > I think designs of this kind would also be in-scope. > > >> I don=E2=80=99t think that there is consensus for such an approach. >> > > I don't think there is a single approach here; it seems to me that there > is a vast range of possible client behaviors related to multiple > resolvers. Recommending a single behavior universally might be > controversial, but I think there is plenty of room for productive technic= al > discussion in this area without triggering reflexive disagreement. > > >> > - Multiple non-equivalent query paths, such as split-horizon DNS or >> > geo-sensitive answers >> > > As an example of the kinds of issues that come up here, consider Mozilla'= s > default behavior [1], in which an NXDOMAIN response from the primary > resolution path triggers a retry of the query on a second resolution path= . > This is an interesting choice with particular privacy, security, > compatibility, and performance properties. Perhaps it's worth specifying > this solution in more detail, or perhaps defining a range of solutions wi= th > different properties. I believe we can discuss the properties of differe= nt > stub state-machines without debating Mozilla's method for choosing the > primary resolver. > > [1] > https://support.mozilla.org/en-US/kb/dns-over-https-doh-faqs#w_how-does-f= irefox-handle-split-horizon-dns > > > >> > - Local DNS caches (e.g. partitioning, use of stale records) >> > - Resilience and fault-tolerance (e.g. single points of failure) >> > - Support for debugging and analysis >> > - DNS Push (accepting responses to queries that have not yet been >> > issued) >> Same thing I don=E2=80=99t think that there is consensus on this. > > > We don't need consensus that a topic is worthwhile in order to include it > in a working group charter. We merely need to believe that there is some > positive interest and potential for a technical consensus to emerge witho= ut > derailing the working group's other topics. > > >> I personally >> think it is a bad idea, but I seem to recall from earlier discussions >> that others agreed with me. IMHO this belongs in the relevant, but more >> challenging for consensus building category. >> > > I don't think this topic is particularly controversial, and versions of > this idea have been considered previously without major incident, e.g. > [2]. This is purely a performance question; there is little security > relevance, because we are speaking about answers delivered from the same > resolver and query path as all the other DNS responses. > > In any case, RFC 8484 DoH already defines DNS Push (Section 5.3), along > with some rules about when it cannot be used. It does not, however, > provide any additional guidance that might support practical use, and has > some significant limitations. Including this topic would allow us to > improve the specification of DNS Push, or indeed deprecate it if that is > the technical consensus. > > [2] https://tools.ietf.org/html/draft-wkumari-dnsop-multiple-responses-05 > > So long >> -Ralf >> =E2=80=94-- >> Ralf Weber >> > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000009718c805976fa9f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This charter just seems like a suggestion for a perpetual = forum to argue and, afaict, isn't actually expected to produce anything= .. it just has some things that if they were published would belong in the = proposed wg.=C2=A0

Please don't make us collectively= relive the ADD side meeting every full meeting.

My sugg= estion: If the proponents believe that a group can publish a document on (e= .g.) "Communicat= ing configuration between the network, operating system, and applications" please wr= ite a charter with that as the goal of the group and the BoF can do the usu= al thing of deciding whether that is a problem worth solving, is well under= stood, and has a chance of success. If it works out - recharter the group f= or new work.

As is the charter fails those tests by putting everything in scop= e but requiring nothing at the same time.

-Patrick

On Thu, = Nov 14, 2019 at 1:14 PM Ben Schwartz <bemasc=3D40google.com@dmarc.ietf.org> wrote:
<= 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">


On Thu, Nov 14, 2019 at 7:42 AM Ralf Weber <dns@fl1ger.de> wrote:
<= 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">Moin!

On 13 Nov 2019, at 2:32, Ben Schwartz wrote:
> Please review the agenda and proposed charter, and join us next week <= br> > for a
> full discussion.
=C2=A0From the proposed charter:
> This working group will consider technical drafts on DNS client
> configuration, especially with a focus on the following items where > technical consensus seems obtainable:
>
> - Communicating configuration between the network, operating system, <= br> > and
> applications
> - Discovery of resolvers and their capabilities and behaviors
> - Query routing in a multi-resolver environment
This is ambiguous.

I think this is ver= y closely related to the next entry on the list, so we should understand th= em together.=C2=A0 Perhaps they should be combined
=C2=A0
If it des= cribes the current /etc/resolv.conf that=E2=80=99s
fine,

That would be in-scope (and there has= been some innovation here related to retry behavior, load spreading, etc.= =C2=A0which could be documented).

but I fear that it describes something where = you ask =E2=80=9Cresolver
A=E2=80=9D for example.com and =E2=80=9Cresolver B=E2=80=9D for example.net.

I think designs of this kind would also be in-s= cope.
=C2=A0
I don=E2=80=99t think that there is consensus for such an approach.=

I don't think there is a single ap= proach here; it seems to me that there is a vast range of possible client b= ehaviors related to multiple resolvers.=C2=A0 Recommending a single behavio= r universally might be controversial, but I think there is plenty of room f= or productive technical discussion in this area without triggering reflexiv= e disagreement.
=C2=A0
> - Multiple non-equivalent query paths, such as split-horizon DNS or > geo-sensitive answers

As an exampl= e of the kinds of issues that come up here, consider Mozilla's default = behavior [1], in which an NXDOMAIN response from the primary resolution pat= h triggers a retry of the query on a second resolution path.=C2=A0 This is = an interesting choice with particular privacy, security, compatibility, and= performance properties.=C2=A0 Perhaps it's worth specifying this solut= ion in more detail, or perhaps defining a range of solutions with different= properties.=C2=A0 I believe we can discuss the properties of different stu= b state-machines without debating Mozilla's method for choosing the pri= mary resolver.

<= div>=C2=A0
> - Local DNS caches (e.g. partitioning, use of stale records)
> - Resilience and fault-tolerance (e.g. single points of failure)
> - Support for debugging and analysis
> - DNS Push (accepting responses to queries that have not yet been
> issued)
Same thing I don=E2=80=99t think that there is consensus on this.

We don't need consensus that a topic is worthwhi= le in order to include it in a working group charter.=C2=A0 We merely need = to believe that there is some positive interest and potential for a technic= al consensus to emerge without derailing the working group's other topi= cs.
=C2=A0
I personally
think it is a bad idea, but I seem to recall from earlier discussions
that others agreed with me. IMHO this belongs in the relevant, but more challenging for=C2=A0 consensus building category.
I don't think this topic is particularly controversial, and= versions of this idea have been considered previously without major incide= nt, e.g. [2].=C2=A0 This is purely a performance question; there is little = security relevance, because we are speaking about answers delivered from th= e same resolver and query path as all the other DNS responses.
In any case, RFC 8484 DoH already defines DNS Push (Section 5.= 3), along with some rules about when it cannot be used.=C2=A0 It does not, = however, provide any additional guidance that might support practical use, = and has some significant limitations.=C2=A0 Including this topic would allo= w us to improve the specification of DNS Push, or indeed deprecate it if th= at is the technical consensus.

So long
-Ralf
=E2=80=94--
Ralf Weber
--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000009718c805976fa9f7-- From nobody Fri Nov 15 23:38:36 2019 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 9B8551200F7; Fri, 15 Nov 2019 23:38:34 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 x6aEMx3O5crQ; Fri, 15 Nov 2019 23:38:32 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 850B112007A; Fri, 15 Nov 2019 23:38:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D1CEA6601B3; Sat, 16 Nov 2019 09:38:31 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rc35S7dAud0; Sat, 16 Nov 2019 09:38:30 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 7A2A46600DE; Sat, 16 Nov 2019 09:38:29 +0200 (EET) From: Jari Arkko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <680390BE-E819-4951-98EE-C77E9C60E495@piuha.net> Date: Sat, 16 Nov 2019 15:38:27 +0800 Cc: Ted Hardie , Martin Thomson To: ADD Mailing list , dns-privacy@ietf.org X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Add] Draft on the use of multiple recursive 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, 16 Nov 2019 07:38:35 -0000 I wanted to point people to a draft that Martin, Ted, and me recently = submitted on the use of multiple resolvers. This is early work; comments and = additional analysis appreciated. = https://tools.ietf.org/html/draft-arkko-abcd-distributed-resolver-selectio= n-00 This memo discusses the use of a set of different DNS resolvers to reduce privacy problems related to resolvers learning the Internet usage patterns of their clients. Jari From nobody Sat Nov 16 19:20:09 2019 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 7DEF6120833 for ; Sat, 16 Nov 2019 19:20:07 -0800 (PST) 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 lIksUCiFv1kv for ; Sat, 16 Nov 2019 19:20:06 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 3A419120046 for ; Sat, 16 Nov 2019 19:20:06 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 997C46601B3 for ; Sun, 17 Nov 2019 05:20:04 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rHZv1hSg5Bta for ; Sun, 17 Nov 2019 05:20:03 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id EA60E6600DE for ; Sun, 17 Nov 2019 05:20:02 +0200 (EET) From: Jari Arkko Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Sun, 17 Nov 2019 11:20:00 +0800 To: ADD Mailing list X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Add] Draft on deployment models for Internet infrastructure 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, 17 Nov 2019 03:20:07 -0000 I also wanted to point people to a draft that talks about centralised and other deployment models. This draft is about a broader topic than the DNS, more generally about anything in the Internet infrastructure. But it is also applicable for DNS. Comments and other observations are again appreciated. https://tools.ietf.org/html/draft-arkko-arch-infrastructure-centralisation-00 Abstract Centralised deployment models for Internet services and Internet business consolidation are well-known Internet trends, at least when it comes to popular and user-visible service. This memo discusses the impacts of similar trends within the Internet infrastructure, on functions such as DNS resolution. Jari From nobody Sat Nov 16 19:34:39 2019 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 96828120836 for ; Sat, 16 Nov 2019 19:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 zWAaF0Z1VyTX for ; Sat, 16 Nov 2019 19:34:35 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 65582120835 for ; Sat, 16 Nov 2019 19:34:35 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id 1so14877365iou.4 for ; Sat, 16 Nov 2019 19:34:35 -0800 (PST) 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=/DC3dOWbEFUpX+H7FEvnm0E54OFKBkIyw1RpRV8XAUE=; b=RtdLGZRqlf9PsIAVD+SADEajs1jRARVDzQT8CEbMgcpLvi6LwKroRg1vgv97EqiTiL AcYHvA2j8GorU12CkrmKhWaOVh/GYapUq7ijB5ZpoG0bZiV7LNkqcFkydz1134Hdpf7K UZOO+c/4nWvxVW9Hn0JxRya6WvqN/4rU++s2OOPM79pVinfjCyT3oOm2h5WkwG+7k3Ds q9v3wfDMkycMlJpioVVWJziPFp5JimpeHENiVzh2MkrLseAGPNgu/0bUFMZVOHFbAk4o sYHTL2aSQ4r/HuQfSZdpCxC9X8XQiElWx0p9pHS7RdB4ITJ3a/8H/JN+pRy1/4REW627 p+0g== 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=/DC3dOWbEFUpX+H7FEvnm0E54OFKBkIyw1RpRV8XAUE=; b=R7QN8iQy7u+LIBgoKCRcpE8D0tn9nPHcljuBH1GTFuahdIXQ7VN+RXkPePl32XEvKP ylpMuh0PCmtA7N7/0/YXexXknTmSLMuO8gaE/wVqtV/oTiKT9vsbsp8xEnnvh3stRwFE Cfw6O+zzmHZ6h60a0RvT+uht8z6myBP7uRrFfB7cVpoT3yifPhBThFB//ns9PfSL3Bjd qJIAEDX4QGcCD+FngCjBfkMSf5/yYl53PeD7OLrzagF9DVw/kGq+GYRWYOptnl/PApSW yeYLOZj859YFJEj6LOjb8LGF/6VtXkK2A4ouJhMBqrjXmI552NZrKo5IEWIE3Z84bcSp wPbA== X-Gm-Message-State: APjAAAXlomcRxMS11tXEq1rnSlQRbYV7dDli8CH1EAubSAjIM9sO2Ts0 c4BL5dsq8TEsfo5j0rzoWH/GHmZKqNKEogQDqytHmmAx X-Google-Smtp-Source: APXvYqwu86PjT+Y/402OT4Crny1I+ovyQu0MLq3eeNih5F9uUGe8hPJr4H3Rxo3z1gbBZ6gCzDp3q7Dsn2rBJRx+Vek= X-Received: by 2002:a5d:8b83:: with SMTP id p3mr744277iol.189.1573961674436; Sat, 16 Nov 2019 19:34:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Sat, 16 Nov 2019 19:34:22 -0800 Message-ID: To: Jari Arkko Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000007eb33c0597828290" Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 17 Nov 2019 03:34:38 -0000 --0000000000007eb33c0597828290 Content-Type: text/plain; charset="UTF-8" On Sat, Nov 16, 2019 at 7:20 PM Jari Arkko wrote: > I also wanted to point people to a draft that talks about centralised and > other deployment models. This draft is about a broader topic than the > DNS, more generally about anything in the Internet infrastructure. But > it is also applicable for DNS. Comments and other observations are > again appreciated. > > > https://tools.ietf.org/html/draft-arkko-arch-infrastructure-centralisation-00 I've already read this draft, so I hope this response will not be viewed as reflexive. The idea that encrypted DNS will result in increased centralization is unsubstantiated. For example, the way unencrypted DNS traffic enables centralized surveillance at the network layer is well known even in pop-science publications: https://www.wired.com/2013/06/nsa-whistleblower-klein/ Encrypted DNS might change the locations of centralization. That is a phenomenon that should be carefully studied, imho. It doesn't seem like a structural weakness, but it could be neutral. thanks, Rob --0000000000007eb33c0597828290 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sat, Nov 16, 2019 at 7:20 PM Jari = Arkko <jari.arkko@piuha.net&= gt; wrote:
I als= o wanted to point people to a draft that talks about centralised and
other deployment models. This draft is about a broader topic than the
DNS, more generally about anything in the Internet infrastructure. But
it is also applicable for DNS. Comments and other observations are
again appreciated.

https://tools.ietf.org/= html/draft-arkko-arch-infrastructure-centralisation-00

I've already read this draft, so I hope this response w= ill not be viewed as reflexive.

The idea that encr= ypted DNS will result in increased centralization is unsubstantiated. For e= xample, the way unencrypted DNS traffic enables centralized surveillance at= the network layer is well known even in pop-science publications:

https://www.wired.com/2013/06/nsa-whistleblower-klein/=C2=A0

Encrypted DNS might change the locations of central= ization. That is a phenomenon that should be carefully studied, imho. It do= esn't seem like a structural weakness, but it could be neutral.

thanks,
Rob

--0000000000007eb33c0597828290-- From nobody Sat Nov 16 22:30:52 2019 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 95BD312009C; Sat, 16 Nov 2019 22:30:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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 QYFqe_7JPdyF; Sat, 16 Nov 2019 22:30:49 -0800 (PST) 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 4F9C812007C; Sat, 16 Nov 2019 22:30:49 -0800 (PST) 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)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 621666A279; Sun, 17 Nov 2019 07:30:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1573972247; bh=yODm/5H8700lnLmtLdXRefNnKgWJud8gLrBX2DV5/Qw=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=ZAX5y/en8t1XOTbbDgNjW9z+guEdMTkPIe0NdmHJMvM0eHmoIpLU0ARG3pf6M5dGp /sSDFHslMrdyD3RWPAglKyQBcg8lMUohv+0QukJh4jqi41QOu9cBCF0wCfxXjvGpKG as0dxBY8mnzbNp9g/Xf0iCh78sMLl61/xc+6FlhSrmV8ZMHFrGYILva5rMTZQUsxtx AgWdFEeg6k9nYnN9f6qwbJhNgntQV9klqVnXjD3LJuq9/pDqujzdN5SYjZJOj+RprF gBE7To5VKu2Vmz7TCGyXx+SlDk/lSObtFI6eNP9b5lGQ7TTOsUu1PYbS1tRnntg0uv G5jw2+dTgmsXA== 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 515AE3C02DA; Sun, 17 Nov 2019 07:30:47 +0100 (CET) Date: Sun, 17 Nov 2019 07:30:47 +0100 (CET) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Jari Arkko , ADD Mailing list , dns-privacy@ietf.org Message-ID: <1017702565.6223.1573972247221@appsuite-gw1.open-xchange.com> In-Reply-To: <680390BE-E819-4951-98EE-C77E9C60E495@piuha.net> References: <680390BE-E819-4951-98EE-C77E9C60E495@piuha.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev17 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] Draft on the use of multiple recursive 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, 17 Nov 2019 06:30:52 -0000 > Il 16 novembre 2019 08:38 Jari Arkko ha scritto: > > > I wanted to point people to a draft that Martin, Ted, and me recently submitted > on the use of multiple resolvers. This is early work; comments and additional > analysis appreciated. > > https://tools.ietf.org/html/draft-arkko-abcd-distributed-resolver-selection-00 > > This memo discusses the use of a set of different DNS resolvers to > reduce privacy problems related to resolvers learning the Internet > usage patterns of their clients. Well, as you recognize in the draft itself, this is just "a narrow aspect within a bigger set of topics", so I would find it more useful to start from the broader discussion, the one you hint at in the final part of the draft: is there a reason to change the current model that has been generally adopted until now, i.e. the user picks (or is supplied) a resolver and all the queries go through it? What are the advantages and disadvantages of spreading the queries instead of using a single resolver? Even in terms of privacy, I would not be so sure that spreading the queries to multiple parties could ever provide more privacy than sending them only to a single trusted party, even if we could actually come up with a distribution strategy that solved the problem of letting all resolvers see most of your traffic over time. The original point of contention in this discussion was the browser sending the queries to a different resolver than the one they were meant for - not the fact that a single resolver was being used. Also, the entire legal data protection architecture in Europe relies on the fact that the user knows and authorizes each single party that gets a share of their data, which is philosophically the exact opposite of a model in which data start to be sent here and there in ways that the user is unable to control. Moreover, you cannot discuss these alternatives only in regard to privacy, as the choice will affect many other dimensions. By choosing a specific resolver, users can get better performance or additional services - how could this work if their queries started to be distributed? ISPs use their resolvers as a network security platform and as a way to make their Internet access service faster than competitors; it is unclear why they should spend considerable money to provide big scale resolvers if these resolvers will not be part of their service any more, and will rather be used at random by random users every now and then (so you would, again, reduce the number of mainstream resolver providers to the few usual suspects that can afford the cost no matter what). Then there's all the lawful interception and content blocking part, which people here tend to dismiss, but governments won't. So I am afraid that if you only discuss a single part of the problem, you will end up worsening the ot hers and not solving much. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Sun Nov 17 00:00:40 2019 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 E0C281200BA for ; Sun, 17 Nov 2019 00:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 iLk5CtRoXKJ1 for ; Sun, 17 Nov 2019 00:00:33 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id 53754120098 for ; Sun, 17 Nov 2019 00:00:33 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.115.196.83]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id xAH80F6j024373 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Nov 2019 00:00:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1573977627; x=1574064027; i=@elandsys.com; bh=fzW7D9qVrIKQt6jkBbrwpPmDinpjsdDhrn2b2TVIxRs=; h=Date:To:From:Subject:In-Reply-To:References; b=EQvO6q50e3X5p/MCbnzCpMjqnKHk3aF4xexNCe2eipZ3dgTqQatC0cL1oCA6M6qRl YNpwqFtUh8dAby2rKrn0wLpdYURVS1LFsO4Su+6msND7sFaNYqPKeLHhBXpeXjbagk bki6m0EJ0aN6nuuHo0xMNqvl2S6DVqi8rFCo8158= Message-Id: <6.2.5.6.2.20191116232455.10209e78@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Sat, 16 Nov 2019 23:57:09 -0800 To: Jari Arkko , add@ietf.org From: S Moonesamy In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 17 Nov 2019 08:00:34 -0000 Hi Jari, At 07:20 PM 16-11-2019, Jari Arkko wrote: >I also wanted to point people to a draft that talks about centralised and >other deployment models. This draft is about a broader topic than the >DNS, more generally about anything in the Internet infrastructure. But >it is also applicable for DNS. Comments and other observations are >again appreciated. The current deployments of, for example, DoH, are based on a centralized model. As the draft mentions, that encourages centralization of information and with it, control of information. That is at odds with the statement in Section 4.1 of RFC 3935, (re. decentralized control and edge-user empowerment). The DNS might be considered as complex because of jurisdiction. Commenting about jurisdiction, an IETF Area Director was quoted as stating that: "[DoH] will allow journalists in hostile regimes to do their jobs more safely, or people in heavily censored countries to get access to the truth". First of all, that is a very narrow use-case. Secondly, the argument of "getting access to the truth" sounds very convenient. Regards, S. Moonesamy From nobody Sun Nov 17 03:09:52 2019 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 1636E12008B; Sun, 17 Nov 2019 03:09:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 Gc-RP2D77BmF; Sun, 17 Nov 2019 03:09:48 -0800 (PST) Received: from mail-ua1-x944.google.com (mail-ua1-x944.google.com [IPv6:2607:f8b0:4864:20::944]) (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 66097120024; Sun, 17 Nov 2019 03:09:48 -0800 (PST) Received: by mail-ua1-x944.google.com with SMTP id a13so4347145uaq.0; Sun, 17 Nov 2019 03:09:48 -0800 (PST) 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=RybEf7ZlytPpu54Xyjh2IV+3gfnOyRdSiOHap09jExM=; b=QzY3AqS/jxkSv3A2az0o4Oa0aHt9CDxRhf8253sUxFSJfEssS7Rz+IMDkrBZ+ED3aD DIt+Q4yfBq3PlBwxI0f9tjeGoWJl61y0mVAdbIHb1KUbYhO0S2z6B5DrnLHpOec9W5CE XZLV/BxJytv6bjw2Amq+4JrJJzxpdBRGPbVEQhuUa/qyukb0ypuVQXHiSRnPpuT8ntmV qwynrhPaJVOTVfd+FN6BSXbm9C79ddYg5IswVd/DsMWEQgB+7Hs0GkhyiJijB3wbxyXd 81N+Qw+aBtNprR6I7z1BK/XaPHOfSbGoyA5uZX7zvDmZZvFOcQBe/3pOezaswV1wDafa 8wfg== 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=RybEf7ZlytPpu54Xyjh2IV+3gfnOyRdSiOHap09jExM=; b=Lt7zPnGNhhbCC8RtJGMtC5HrMubAuhHEdIKm3uyQpZdA+wEDC8vX9N6UyjUt/FOsyd rr2uv7zHGGvvtQkfCIexXit6UdmeYzMNBfUsSkif+XGLpIQ10Ne5Qt9dgSQAKGkn+4Zl PqY8nLpqkIyaHTrk237RVUk5nJTOEfWTOnWQPcDXTSZb/E9VvJ5yMJnrG5dO9K2sD/hb k6CZdqIyee8S+CNCmC11iyzRdbB0FoXF6nJSSJfyXl95LsaTu2zMZJ51+TJhDMbGbujc F3E2LJVMWjZ27eDROpfunIVSk42C7F4mPz9qUh1S1ro8nEGjepmv0DV3ExknvJbxScC9 +yoQ== X-Gm-Message-State: APjAAAWwzQcsMLZdP0VhGit/Jw+Rc8fCnNurIYd0JH3l5OUwGeOKP3Pm 8ej11QKSpn3KbMVg9PgIdnp8iDHOY3ypzDQge1c= X-Google-Smtp-Source: APXvYqx2ja6kSLPdfbGsjSDHtDBRkBxwIY5/AkJJPQmXNXBYprDznMeEk7SntwkceiSO1mAGU9wqfuaB+RPoqXfuo60= X-Received: by 2002:ab0:786:: with SMTP id c6mr14023856uaf.62.1573988987245; Sun, 17 Nov 2019 03:09:47 -0800 (PST) MIME-Version: 1.0 References: <680390BE-E819-4951-98EE-C77E9C60E495@piuha.net> In-Reply-To: <680390BE-E819-4951-98EE-C77E9C60E495@piuha.net> From: Brian Dickson Date: Sun, 17 Nov 2019 19:09:31 +0800 Message-ID: To: Jari Arkko Cc: ADD Mailing list , dns-privacy@ietf.org, Ted Hardie , Martin Thomson Content-Type: multipart/alternative; boundary="0000000000007718e1059788de22" Archived-At: Subject: Re: [Add] Draft on the use of multiple recursive 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, 17 Nov 2019 11:09:50 -0000 --0000000000007718e1059788de22 Content-Type: text/plain; charset="UTF-8" I scanned it briefly, and have a question about whether it makes sense to consider a couple of syntactic/semantic additions. I believe there would be more value to support explicit ordering as well as randomization within a given set at the same level of preference. I also believe adding rules for fallback to non-private servers would be advisable, even if some configurations choose to exclude the fallback server set. (Whether this uses names with hints for corresponding IP addresses of servers, or not, is another question; that might better be addressed separately?) Using bind-style syntax, I would imagine something like: resolvers { policy round-robin; fallback timeout 2s; set 1 { pref 30; proto dot; servers { 9.9.9.9; 8.8.8.8; 1.1.1.1;} } set 2 { pref 20; proto doh; servers {9.9.9.9; 8.8.8.8;} } set 3 { pref 10; proto dns; servers {1.1.1.1;} } } The concept would be to list the preferred sets of servers/protocols and their respective preference levels, along with resolver selection policy (possibilities could be best, round-robin, random-order, etc). Fallback to lower-preference sets would be controlled by fallback policy. The idea is to avoid privacy-impacting server/protocol selection generally (resistant to downgrade attacks), if the client so desires. Everything else in the draft would generally be applicable to the selection policy within server sets. This is a richer semantic than the traditional /etc/resolv.conf, but the latter doesn't really support anything other than traditional port 53, so being restricted by the old semantics seems unwise. Brian On Sat, Nov 16, 2019 at 3:38 PM Jari Arkko wrote: > I wanted to point people to a draft that Martin, Ted, and me recently > submitted > on the use of multiple resolvers. This is early work; comments and > additional > analysis appreciated. > > > https://tools.ietf.org/html/draft-arkko-abcd-distributed-resolver-selection-00 > > This memo discusses the use of a set of different DNS resolvers to > reduce privacy problems related to resolvers learning the Internet > usage patterns of their clients. > > Jari > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000007718e1059788de22 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I scanned it briefly, and have a question about whether it= makes sense to consider a couple of syntactic/semantic additions.

=
I believe there would be more value to support explicit ordering= as well as randomization within a given set at the same level of preferenc= e.
I also believe adding rules for fallback to non-private server= s would be advisable, even if some configurations choose to exclude the fal= lback server set.

(Whether this uses names with hi= nts for corresponding IP addresses of servers, or not, is another question;= that might better be addressed separately?)

Using= bind-style syntax, I would imagine something like:

resolvers {
=C2=A0policy round-robin;
=C2=A0fallback = timeout 2s;
=C2=A0set 1 {
=C2=A0 =C2=A0pref 30;
=C2=A0 =C2=A0proto dot;
=C2=A0 =C2=A0servers { 9.9.9.9; 8.8.8.= 8; 1.1.1.1;}
=C2=A0 =C2=A0 }
=C2=A0set 2 {
= =C2=A0 =C2=A0pref 20;
=C2=A0 =C2=A0proto doh;
=C2=A0 = =C2=A0servers {9.9.9.9; 8.8.8.8;}
=C2=A0 =C2=A0}
=C2=A0= set 3 {
=C2=A0 pref 10;
=C2=A0 proto dns;
=C2= =A0 servers {1.1.1.1;}
=C2=A0 }
}

<= div>The concept would be to list the preferred sets of servers/protocols an= d their respective preference levels, along with resolver selection policy = (possibilities could be best, round-robin, random-order, etc).
Fa= llback to lower-preference sets would be controlled by fallback policy.

The idea is to avoid privacy-impacting server/protoco= l selection generally (resistant to downgrade attacks), if the client so de= sires.

Everything else in the draft would generall= y be applicable to the selection policy within server sets.

<= /div>
This is a richer semantic than the traditional /etc/resolv.conf, = but the latter doesn't really support anything other than traditional p= ort 53, so being restricted by the old semantics seems unwise.
Brian=C2=A0 =C2=A0

On Sat, Nov 16, 2019 at 3:38 PM Ja= ri Arkko <jari.arkko@piuha.net> wrote:
I = wanted to point people to a draft that Martin, Ted, and me recently submitt= ed
on the use of multiple resolvers. This is early work; comments and addition= al
analysis appreciated.

https://tools.ietf.org= /html/draft-arkko-abcd-distributed-resolver-selection-00

=C2=A0 =C2=A0This memo discusses the use of a set of different DNS resolver= s to
=C2=A0 =C2=A0reduce privacy problems related to resolvers learning the Inte= rnet
=C2=A0 =C2=A0usage patterns of their clients.

Jari

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000007718e1059788de22-- From nobody Sun Nov 17 03:41:13 2019 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 51D4F1200F8 for ; Sun, 17 Nov 2019 03:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 aRaduk2tGKN2 for ; Sun, 17 Nov 2019 03:41:08 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 948D91200F5 for ; Sun, 17 Nov 2019 03:41:08 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id m6so9482878vsn.13 for ; Sun, 17 Nov 2019 03:41:08 -0800 (PST) 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=d7VYG+9PapqaWg+iOH0Xf7F12yxfg31B49DGyNvyi30=; b=sr1V9/Nf0DIvYTNfYZueIxl5OLoPQt3C+2u2wh8yzCSrInzpLAi6iXQjUnnnadWYwu yQRkHkaNLczXhlarMf7NXX7TRVwvlrzjsr/TbfA6Qhdn4yXilAsBo+cBIY4EBD7XW1lh 8+ZMMmPd0xTUWU/z3eMt7ols+CRpnrUqNMWvzzbAR+O6dnQSn8pzOz2VKu76r/mZXT44 2lux0nPDEhQkPPyyxTJnbKwXO8tA0G1YmGZqw5mBJLMYqFY7ngRhcpysj9MXV9wJXUcM 28RsFeCoUPmoj4yLZ3W3Z+TBweRPVvKzq5FXs99szpWS5CSvVR2H90/aos6tXmgKxasP B1cg== 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=d7VYG+9PapqaWg+iOH0Xf7F12yxfg31B49DGyNvyi30=; b=OcZAHhZsOFgJL/0UYse8X8G9XRif6FVOvfIggSlwfQ4+XWJLD9ztUB4GbL0bQTzxmB Ol0s4OBnmswxu7ERIlxAr2c3YwPiSlnj5zqEt9xh1Gb2m8I0UYDDKfSxv8Mkw9i7YMkt XPNy9sxSlLF02hzIFSi8Z/TOdgBExZFJGg5a3lKo/cDT9XQzj9Mycfb/0i62IzGpbkFs ur8N08ykMsiecCsD97lN9nQZIx+bp51yMoBZdOv1RM8I8FAsE8PfapUDW8fU6qds9r0+ +ue2tF/QjyHkrqXDYR3eXhlF3CVsM8Oq+j7/AZv+TNX6slREOaCL4Bkde7cTrf/iLkYo HqhQ== X-Gm-Message-State: APjAAAXoGCwYSwFId6WRPGydBMeH680I7X7XcO7xZhEACeyDkw7lXUKD ReZuI8B3AQepLrSMBBD/H31LuDRjI3bHKGgL8qD03B52 X-Google-Smtp-Source: APXvYqwXqNlfYw7its/2ZNDaprEpsgLiqMDGd++0jzNNumIDYVBurriJLhzCIhSjrBRI3XF22hyv6n4OUhSJNBuraBI= X-Received: by 2002:a67:f744:: with SMTP id w4mr3959616vso.219.1573990867546; Sun, 17 Nov 2019 03:41:07 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Dickson Date: Sun, 17 Nov 2019 19:40:51 +0800 Message-ID: To: Ben Schwartz Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000008a374f0597894e44" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 17 Nov 2019 11:41:11 -0000 --0000000000008a374f0597894e44 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 13, 2019 at 10:33 AM Ben Schwartz wrote: > On behalf of the ABCD BoF chairs, I am writing to confirm that the draft > agenda for the ABCD BoF has now been posted, along with a revised charter > proposal. > > Agenda: https://datatracker.ietf.org/meeting/106/materials/agenda-106-abcd > Proposed charter: > https://datatracker.ietf.org/meeting/106/materials/slides-106-abcd-proposed-charter-text-revised > > We have significantly adjusted the proposed charter text, incorporating > comments and suggestions from ADD participants. Most notably, the revised > text attempts to ensure that disagreements on the most contentious > questions will not impede valuable standards development in less > controversial areas. > > Please review the agenda and proposed charter, and join us next week for a > full discussion. > > Thanks to the authors etc for putting this all together, I look forward to the discussion. I have a question, about whether it would be reasonable to discuss the following in the context of ABCD's BoF and whether it would be reasonable to include it for discussion (or if it belongs somewhere else)? This the question, very briefly: *Is it too late to discuss changing the port for DoH from 443 to a unique port number?* Here's the context for the question, based on what has transpired since 8484 was published: - Two browsers have announced experiments on DoH - The two browser vendors are using very different approaches to resolver selection - Firefox is using its TRR with Cloudflare as the initial (only) entry - Chrome is doing a "same resolver" upgrade, but only for entries in its (TRR-like) table of resolvers - Public resolver operators have generally stated they will not run any other services on the IP addresses used for DoH - No widespread dependence on DoH (without fallback to regular DNS) is known to have been adopted The initial argument in 8484 for using the same port as HTTPS, was that mixing DoH traffic with regular HTTPS traffic would provide two benefits: - Difficulty in identifying DoH traffic - Difficulty in blocking DoH traffic (e.g. without impacting non-DoH HTTPS traffic) However, given that the public resolvers serving DoH are NOT mixing any other HTTPS traffic with the DoH traffic, both of those arguments are invalid: - Any on-path party wanting to block DoH to these public resolvers, can do so on the basis of IP address alone, - Thus the port number is irrelevant (and there is no reason to insist on 443 other than the relatively trivial issue of deployed code on two browsers and a handful of resolvers) There is one relevant aspect of the choice of port number, that motivates the question of changing to a unique port number: - The ability of an on-path network operator, such as an enterprise, to detect and/or block "rogue" DoH servers which are not on any TRR list, is dependent on having a unique port number to identify such traffic. The detection and/or blocking does NOT require the ability to observe the contents of the DoH traffic. I.e. it is compatible with encrypted DNS. This is not a proposal to change the wire format of DoH, only its port number. For many/most of the use cases contemplated, the mere existence of "new" DoH endpoints is of interest to network operators (e.g. for identifying malware), and blocking such detected connections at the network (IP and port) level is sufficient, and also does not require examination of the contents. Most of the remaining contentious issues from ADD (and presumably ABCD) may be significantly mitigated by a change of port number (thus allowing enterprise network operators to do the above). I'm not asking that this question be discussed here, or that a decision be taken just yet. I recognize the port number issue is a bit late; the question is, given that there does not appear to be any remaining benefit to overloading 443 for DoH: *Is it TOO late to revisit the port choice?* I.e., Is it appropriate to add to the ABCD on-topic matter for subsequent discussion and ID proposals? Brian --0000000000008a374f0597894e44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Nov 13, 2019 at 10:33 AM Ben = Schwartz <bemasc=3D40goog= le.com@dmarc.ietf.org> wrote:
On= behalf of the ABCD BoF chairs, I am writing to confirm that the draft agen= da for the ABCD BoF has now been posted, along with a revised charter propo= sal.

Agenda:=C2=A0https://datatracker.ietf.org/meeting/106/materials/agenda-106-abcd

<= div>We have significantly adjusted the proposed charter text, incorporating= comments and suggestions from ADD participants.=C2=A0 Most notably, the re= vised text attempts to ensure that disagreements on the most contentious qu= estions will not impede valuable standards development in less controversia= l areas.

Please review the agenda and proposed cha= rter, and join us next week for a full discussion.


Thanks to the authors etc for putting = this all together, I look forward to the discussion.

I have a question, about whether it would be reasonable to discuss the f= ollowing in the context of ABCD's BoF and whether it would be reasonabl= e to include it for discussion (or if it belongs somewhere else)?

This the question, very briefly: Is it too late to discu= ss changing the port for DoH from 443 to a unique port number?

Here's the context for the question, based on what has= transpired since 8484 was published:
  • Two browsers have a= nnounced experiments on DoH
  • The two browser vendors are using very = different approaches to resolver selection
    • Firefox is using its= TRR with Cloudflare as the initial (only) entry
    • Chrome is doing a = "same resolver" upgrade, but only for entries in its (TRR-like) t= able of resolvers
  • Public resolver operators have generally sta= ted they will not run any other services on the IP addresses used for DoH
  • No widespread dependence on DoH (without fallback to regular DNS) is= known to have been adopted
The initial argument in 8484 = for using the same port as HTTPS, was that mixing DoH traffic with regular = HTTPS traffic would provide two benefits:
  • Difficult= y in identifying DoH traffic
  • Difficulty in blocking DoH traffic (e.= g. without impacting non-DoH HTTPS traffic)
However, given th= at the public resolvers serving DoH are NOT mixing any other HTTPS traffic = with the DoH traffic, both of those arguments are invalid:
=
  • Any on-path party wanting to block DoH to these public resolvers, c= an do so on the basis of IP address alone,
  • Thus the port number is = irrelevant (and there is no reason to insist on 443 other than the relative= ly trivial issue of deployed code on two browsers and a handful of resolver= s)

There is one relevant aspect of the c= hoice of port number, that motivates the question of changing to a unique p= ort number:
  • The ability of an on-path network operator, s= uch as an enterprise, to detect and/or block "rogue" DoH servers = which are not on any TRR list, is dependent on having a unique port number = to identify such traffic.

The detection = and/or blocking does NOT require the ability to observe the contents of the= DoH traffic. I.e. it is compatible with encrypted DNS. This is not a propo= sal to change the wire format of DoH, only its port number.

<= /div>
For many/most of the use cases contemplated, the mere existence o= f "new" DoH endpoints is of interest to network operators (e.g. f= or identifying malware), and blocking such detected connections at the netw= ork (IP and port) level is sufficient, and also does not require examinatio= n of the contents.

Most of the remaining contentio= us issues from ADD (and presumably ABCD) may be significantly mitigated by = a change of port number (thus allowing enterprise network operators to do t= he above).

I'm not asking that this question b= e discussed here, or that a decision be taken just yet.

I recognize the port number issue is a bit late; the question is, giv= en that there does not appear to be any remaining benefit to overloading 44= 3 for DoH:
Is it TOO late to revisit the= port choice?
<= br>
I.e., Is it appropriate to add to the ABCD on-topic matter fo= r subsequent discussion and ID proposals?

Brian
--0000000000008a374f0597894e44-- From nobody Sun Nov 17 05:26:41 2019 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 BA44612010C for ; Sun, 17 Nov 2019 05:26:39 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 iT5LtIkGIWh7 for ; Sun, 17 Nov 2019 05:26:37 -0800 (PST) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 397201200CD for ; Sun, 17 Nov 2019 05:26:37 -0800 (PST) Received: by mail-qt1-x82e.google.com with SMTP id o49so16945654qta.7 for ; Sun, 17 Nov 2019 05:26:37 -0800 (PST) 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=+2H33X5dUkZXZQ6k36zjfA2DVQ/YGth0nmFm2MNXmIQ=; b=0bd1pdAak54qXXwjitOo7EKAn2GkaQuESl5yq6joq/h+q45nEo2/lY2yJZg0wsuBjQ S8i4RFWvvQ313SBR/MssyttmpolDQhy4is5M0KkeHTgca14XlB3HTS6uOl3qs+OLzGgv jQX067uKicUZ7oYNNO2GvZgo4P7pyr58mZC2ZjDAJ+diav6AvCRzuKFsLIvM+FJqYvEA F69vjQnGZb6avAfTBbEF0lbip9lKue4bVpOpt3HiUkxqHfrHXZt0+vlBfMdXTNvOgpUM Ydv8JfWH0Cti/wzazlEK+ZedRmotwrN9SRzoflnGT7oIWJ12Ghzf5LOwfQjKCY+i1JSV bMRA== 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=+2H33X5dUkZXZQ6k36zjfA2DVQ/YGth0nmFm2MNXmIQ=; b=gV8bQ21WDl/7u0uEbadeE+qBf+k8US6yuPYDKReUBuFXyVRE/f2wQxnPpJ7Pphihyv tsY91wqLV8fnQq0VkozKZmozvrpSkdiS0UasKBfTEE+Xjk2m9kQAE0jTBYbjUEv5z22K t3dkFzd/3U3Ix1qLX2r4nqOy2wbWyJaBnvqvT6waGgGgm7X+SI/KZ8Do6Gn20c7R4vtI BdUf+blT8iMC7DcUwMTyGotpaFWhprzeCmGFP7mGSYMqvTBFCwncq9dUWDB9O7kGjrL/ bftV2tI8+J2c6qMMkbk3TOMe1ffcUa3TnLnQUmdeGMoVuj857obhZ5dUOXdJT9lh4cwS JR2A== X-Gm-Message-State: APjAAAU3qdegvlXAVTCgM8LlJbNNTNNyNzwwEX6Q+h6o6w4P6VwOBeDS I5cWGyO2W4JQL5A3sPEdAmZBQw== X-Google-Smtp-Source: APXvYqz+UrwlbVRQZJNtHtYMUV0zeyIanIloHy5B00Y5OzYteD284018Jp/c32k5lyVAzwgcfZRcNw== X-Received: by 2002:ac8:385d:: with SMTP id r29mr23567937qtb.52.1573997196149; Sun, 17 Nov 2019 05:26:36 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:e59e:8be4:9ffc:3242? ([2601:18b:300:36ee:e59e:8be4:9ffc:3242]) by smtp.gmail.com with ESMTPSA id j10sm8511183qtb.34.2019.11.17.05.26.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 05:26:35 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_12887377-39CD-4D86-9C27-B2B40314B320" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.1\)) Date: Sun, 17 Nov 2019 08:26:33 -0500 In-Reply-To: Cc: Ben Schwartz , ADD Mailing list To: Brian Dickson References: X-Mailer: Apple Mail (2.3608.40.2.2.1) Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 17 Nov 2019 13:26:40 -0000 --Apple-Mail=_12887377-39CD-4D86-9C27-B2B40314B320 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 17, 2019, at 6:40 AM, Brian Dickson = wrote: > This the question, very briefly: Is it too late to discuss changing = the port for DoH from 443 to a unique port number? It=E2=80=99s never too late to have a discussion, but it would be a = useless discussion, unless you intend to obtain police powers; even = then, you=E2=80=99re not really going to be able to do it in a way that = gains you anything. This would be like going up to someone who=E2=80=99s = drinking coffee and getting into a discussion with them about how they = should switch to tea. They might be polite, or they might throw the = coffee at you (but probably not because then they wouldn=E2=80=99t be = able to drink it). They definitely aren=E2=80=99t going to stop = drinking coffee. --Apple-Mail=_12887377-39CD-4D86-9C27-B2B40314B320 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 17, 2019, at 6:40 AM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
This the question, very briefly: Is it too = late to discuss changing the port for DoH from 443 to a unique port = number?

It=E2=80=99s= never too late to have a discussion, but it would be a useless = discussion, unless you intend to obtain police powers; even then, = you=E2=80=99re not really going to be able to do it in a way that gains = you anything.  This would be like going up to someone who=E2=80=99s = drinking coffee and getting into a discussion with them about how they = should switch to tea.  They might be polite, or they might throw = the coffee at you (but probably not because then they wouldn=E2=80=99t = be able to drink it).  They definitely aren=E2=80=99t going to stop = drinking coffee.


= --Apple-Mail=_12887377-39CD-4D86-9C27-B2B40314B320-- From nobody Sun Nov 17 07:02:47 2019 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 5FAC412007A for ; Sun, 17 Nov 2019 07:02:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=fI9/By9s; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=IZO73RyC 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 0qPoWbp0bG1E for ; Sun, 17 Nov 2019 07:02:42 -0800 (PST) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (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 728251200CD for ; Sun, 17 Nov 2019 07:02:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574002962; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=Ud7RqWwQ+E3rMAu2TphcVpOjF5xI0x1qJjEDEE2/OuJ+ZsN8h+L+tVQtsMqWbN6PoYFn8Xfw0UAiq 3oMfTHpvFyoDrCDJJhe1GRDMuJc8Xa8HPkxbcPrv1gIcuzKDKwWNYgZuK9ib47BDf5CRAXOcSLMVlp A4RGY23UxXx++7Llc6lUxpi5ZBo2J8t793OAWiZdHhZr77Iunexzy9PmcEWZBghXTMO3ntx3q95LAC 0ws/Hw53P8w6hDv+tIXzoDSbmEdHgEue42JoTBSEdv7YpJZ4+vyvtz9BioozaR0FvJDTTw4ne3GufT lniJfOiq4qJxgjbyoSFUkfM3W7S511w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=JW8whLl7nycYJVj1UwYP0idNyyAbPTNwfKctJVzY8V8=; b=XEWphwbt5Qyfm/VPFv8cgzu3NJr8yBSQKFXmxAFgqvyIpciHgxlWAbMkc8qCGLg05qwq7TXOujRzJ 2lvMgXe8/1XjC70MZeb5cVZlEhgAnDtmLsd/6pluhicJibcZnUBcEjX5Xb1mYYqMb2BXQ5OrpVy6S0 IdIoDWPRmLYqsgL/txjYHpWadBQ3YJnahQY1HSbrbUci1D/Zzn7bSuyp6IjT6eE1vUVY6RwBnDVTNA 2V9zvYDuthAp2kftG2O3EcBHvyuRYBsvINlViRFYiVBRb2ZOksEEqi/aRDc1aSnqps6yX4aL8EQLTQ MxOBZTR/oaxxaLBZYaeej81qkNftpjg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.210.50; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=JW8whLl7nycYJVj1UwYP0idNyyAbPTNwfKctJVzY8V8=; b=fI9/By9s4683v4T3akbhfknyghX9kG+X4XeIfyRKvsRsjySThbJgPhuDBeGxEopLcQTlbISakzhhs Svun9+vLrdNTBX/L0DYMx2ytlUOHr8sJcWXx6EWvdGtgnuVdgu+1wRyWur0WJD2iZvDWFINgOoibxH CwFnegMs5HGnpLwA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=JW8whLl7nycYJVj1UwYP0idNyyAbPTNwfKctJVzY8V8=; b=IZO73RyC5yvVP5+zGDJCNHQiPXeC9NXVuipeOx7x5Nwvel3NwXWM1B4KnexvGXrdz/gRrNiyrdDkG OL36PMULe2zw2gNosPsbPpDWTNZs0glIgBUw54/SeygHzgAqrqympVNnvKei90Ug+7q/7fWFds4dN2 BZEBAotQc0AfjcscPEUrzUAQZ5jCoDGZBqxZ3YWuemKneFmGeGTYEQnFiFDJEJZQe7Qu4tCeVlswRw sZvWfS+6eyxAttHNtyVG5NUHIgT7r5tgcJwvogc7U9oY0jUG8GtnwvqRf+0Bn6EWltM6Vr3h4tN2sR ymmpg3ZBCcRk92ARxMY3Y9zLfn/ghtg== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 4cabed70-094b-11ea-829e-79a40d15cccd X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.210.50 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-ot1-f50.google.com (unknown [209.85.210.50]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 4cabed70-094b-11ea-829e-79a40d15cccd; Sun, 17 Nov 2019 15:02:40 +0000 (UTC) Received: by mail-ot1-f50.google.com with SMTP id w24so11778690otk.6 for ; Sun, 17 Nov 2019 07:02:40 -0800 (PST) X-Gm-Message-State: APjAAAUKeUWnAi/6++PQmRnyeafX02bBFQ7gNlS8MBy+42zucoTfjnO8 uVFkbmqPb2ajyR7cvV7+V7y27FVnjgw6/shWYdU= X-Google-Smtp-Source: APXvYqyzTuW6zPMyaZCaYLmk9xMzZ9hDy1e8+ZSbSsDNGE+fxX/zn+BMJDN6zcV0CgpZYHKv+r+bt3+1D+FyK5pYd4c= X-Received: by 2002:a05:6830:1f1a:: with SMTP id u26mr17040244otg.75.1574002959899; Sun, 17 Nov 2019 07:02:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Patrick McManus Date: Sun, 17 Nov 2019 23:02:27 +0800 X-Gmail-Original-Message-ID: Message-ID: To: Brian Dickson Cc: Ben Schwartz , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000004ce48505978c1fd3" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 17 Nov 2019 15:02:45 -0000 --0000000000004ce48505978c1fd3 Content-Type: text/plain; charset="UTF-8" DoH does not require any particular port number - the server specifies it as part of the URI Template and there is no default template. You cannot make another port number the default for https (which doh does required) without minting another scheme, which seems kind of pointless when you can simply explicitly use another port as part of the template if you like. Handcuffing the protocol to introduce intentional network signaling would weaken the confidentiality properties of HTTPS - i.e. it is quite explicit that any HTTPS content (or purpose) is not visible to the network and allow network attackers to trivially launch downgrade attacks. That isn't in the interest of securing a protocol. This thread is probably a good example of how ABCD would not be a productive working group. On Sun, Nov 17, 2019 at 7:41 PM Brian Dickson wrote: > > - The ability of an on-path network operator, such as an enterprise, > to detect and/or block "rogue" DoH servers which are not on any TRR list > > unregistered is rogue now? --0000000000004ce48505978c1fd3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
DoH does not require any particular port number - the= server specifies it as part of the URI Template and there is no default te= mplate. You cannot make another port number the default for https (which do= h does required) without minting another scheme, which seems kind of pointl= ess when you can simply explicitly use another port as part of the template= if you like.

Handcuffing the protocol to introduc= e intentional network signaling would weaken the confidentiality properties= of HTTPS - i.e. it is quite explicit that any HTTPS content (or purpose) i= s not visible to the network and allow network attackers to trivially launc= h downgrade attacks. That isn't in the interest of securing a protocol.=

This thread is probably a good example of how ABC= D would not be a productive working group.


On Sun,= Nov 17, 2019 at 7:41 PM Brian Dickson <brian.peter.dickson@gmail.com> wrote:
  • The ability of an on-path network operator, such as= an enterprise, to detect and/or block "rogue" DoH servers which = are not on any TRR list

unregistered is rogue now?
=C2=A0

--0000000000004ce48505978c1fd3-- From nobody Sun Nov 17 12:58:17 2019 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 DD06A12020A for ; Sun, 17 Nov 2019 12:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IXTonbc6pS2S for ; Sun, 17 Nov 2019 12:58:15 -0800 (PST) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4FE01201EF for ; Sun, 17 Nov 2019 12:58:15 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 292D537402CC; Sun, 17 Nov 2019 12:58:14 -0800 (PST) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id 8240D1965255; Mon, 18 Nov 2019 04:58:13 +0800 (+08) Received: from dhcp-984c.meeting.ietf.org (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id 7F00A1965254; Mon, 18 Nov 2019 04:58:13 +0800 (+08) From: Paul Ebersman To: Brian Dickson cc: ADD Mailing list In-reply-to: References: <680390BE-E819-4951-98EE-C77E9C60E495@piuha.net> Comments: In-reply-to Brian Dickson message dated "Sun, 17 Nov 2019 19:09:31 +0800." X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <10820.1574024293.1@dhcp-984c.meeting.ietf.org> Date: Mon, 18 Nov 2019 04:58:13 +0800 Message-Id: <20191117205813.8240D1965255@fafnir.remote.dragon.net> Archived-At: Subject: Re: [Add] Draft on the use of multiple recursive 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, 17 Nov 2019 20:58:17 -0000 bdickson> I believe there would be more value to support explicit bdickson> ordering as well as randomization within a given set at the bdickson> same level of preference. That ship sailed years ago. Round robin as load balancing (or any use of expected order of RRs in an RRSet) is never going to be reliable. If you have some need for it, do it in the code doing the DNS queury or you will be surprised. This is from painful years of tech support of BIND explaining why this wasn't doing what someone wanted. There are too many stub and recursive resolvers out there we can't change that won't "behave". What use case do you think this solves? From nobody Sun Nov 17 16:35:54 2019 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 5A47A1207FD for ; Sun, 17 Nov 2019 16:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 0zYCNeMnYI7u for ; Sun, 17 Nov 2019 16:35:52 -0800 (PST) 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 BD59C12026E for ; Sun, 17 Nov 2019 16:35:51 -0800 (PST) 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)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 320636A234; Mon, 18 Nov 2019 01:35:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1574037348; bh=WGKL8GTef+J5Ylp3HncmSZ6vxhshuNQNozIPMqeQcz4=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=j3KTGPEnf/IgPAXIJiGYLf5wJxOd7jMMIvCszdMemr4SnWE8PTzW2+gRKFMlr1cS0 091XepIAGAbEVjwgrzPuAxyHeeeIvKlcGj6YsbvG1RG8gCW9T4BJEiEf6Kmw0pNKIN uoQty8ocIy5OdT0whnf5V1khocfIvvLJ5Yvo1+fGsSZVVhbDFoHU1zvIKQfMIzR8HC eYjum2HK4AYEUaavDtTMxgWuwPLPbyNcwfB1o42qnWkvU2C+b2RyJQz5pfapDy8ZoU J43olwN2LQryrE5nxnDK1H6mPpOqjb+hUCs2bWgKt6yC2bsOo6KgfuCUyP+zTnAlh3 PHHH2XB9roovA== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (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 17C4E3C0045; Mon, 18 Nov 2019 01:35:48 +0100 (CET) Date: Mon, 18 Nov 2019 01:35:47 +0100 (CET) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Patrick McManus Cc: ADD Mailing list Message-ID: <299277505.7138.1574037347987@appsuite-gw2.open-xchange.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev17 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] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 00:35:53 -0000

Il 17 novembre 2019 16:02 Patrick McManus <mcmanus@ducksong.com> ha scritto:


DoH does not require any particular port number - the server specifies it as part of the URI Template and there is no default template. You cannot make another port number the default for https (which doh does required) without minting another scheme, which seems kind of pointless when you can simply explicitly use another port as part of the template if you like.
That's fine, but the discussion could rather be: should we suggest that all well-behaved DoH providers use a specific port other than 443 in their template? (Of course non-well-behaved providers will always do whatever possible to camouflage their traffic, but that's an intrinsic feature of a default port anyway - it can always be changed.)
unregistered is rogue now?
Honestly (coming from a free software maker that produces the most widely used mail delivery agent on the planet, and that strives to keep its long tail of small independent email servers able to work and connect with the big email platforms, something which has become increasingly difficult over time due to heuristic anti-abuse filters on incoming email by the big players that tend to treat any too-small-for-measurement server as "possibly rogue") I think that the TRR concept in itself is just going to get us there: by introducing the idea that some DNS providers are more trusted than others, of course everyone else's life will be made more and more difficult, by using the absence from that list as a signal of possible problems - or just by trying to block all traffic for resolvers that have not been vetted by someone.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
From nobody Sun Nov 17 16:50:04 2019 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 629321208DC for ; Sun, 17 Nov 2019 16:50:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 2SayZAS88_M5 for ; Sun, 17 Nov 2019 16:50:00 -0800 (PST) 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 AC36F1208BE for ; Sun, 17 Nov 2019 16:49:59 -0800 (PST) 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)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 1A57B6A234; Mon, 18 Nov 2019 01:49:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1574038198; bh=/H8pvLSDlXs2q64hiNyGC1XMAyQyjq3AM1crC9gCkuM=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=srT0VI9SfYmsymKsIfxhzFTGOq8uVPHXvlghuYxAV/XItnqCcnxZerXZAv8fOdbYV JxnWJxNRdssdhbbvsRnO0ZAzNcGgdWqLTnqyEXd5YcRLi3+s2GRWxHg2fSeNyU8Knc XKTDeqJR+hIhV0t9wuiiwqVH7Ptp9PB3YgSpjWeO4ubrEbZLZDmsSkDhy5RxqawzUh H9Yu7dCt7H6nR2oXOFhnEMBmOT6BsN5jOOCE5aGrhaZy8GeTVKk+6orx7C+0uCLa7O EFQbPmDPlRbRqZxzzGignOv0ggDMQUxLJRZ81W0wsYBebS/XNn8n7DWBxXu1FefPXh IXiqNkl+4I/dg== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (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 033EF3C0045; Mon, 18 Nov 2019 01:49:58 +0100 (CET) Date: Mon, 18 Nov 2019 01:49:57 +0100 (CET) From: Vittorio Bertola Reply-To: Vittorio Bertola To: S Moonesamy , add@ietf.org Message-ID: <2105867190.7141.1574038197898@appsuite-gw2.open-xchange.com> In-Reply-To: <6.2.5.6.2.20191116232455.10209e78@elandnews.com> References: <6.2.5.6.2.20191116232455.10209e78@elandnews.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev17 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] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 00:50:04 -0000 > Il 17 novembre 2019 08:57 S Moonesamy ha scritto: > > The current deployments of, for example, DoH, are based on a > centralized model. As the draft mentions, that encourages > centralization of information and with it, control of > information. That is at odds with the statement in Section 4.1 of > RFC 3935, (re. > decentralized control and edge-user empowerment). The DNS might be > considered as complex because of jurisdiction. > > Commenting about jurisdiction, an IETF Area Director was quoted as > stating that: "[DoH] will allow journalists in hostile regimes to do > their jobs more safely, or people in heavily censored countries to > get access to the truth". First of all, that is a very narrow > use-case. Secondly, the argument of "getting access to the truth" > sounds very convenient. I still find it weird that people at the IETF challenge jurisdiction and national sovereignty so directly. Whether we like it or not, that concept is what keeps the world together and more or less at peace, granting peoples the right to self-govern. In the end, a good architecture for the DNS would support the ability of each country to make and enforce rules over their citizens' use of it. The opposite, in the end, is only going to replace one jurisdiction with another, which is unacceptable to even the most democratic governments. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Sun Nov 17 17:38:44 2019 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 3D6B4120849 for ; Sun, 17 Nov 2019 17:38:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ducksong.com header.b=fQEqsYJp; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=lIf4FZ+v 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 CzOhsgYAf_g2 for ; Sun, 17 Nov 2019 17:38:40 -0800 (PST) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 A6DC91207FD for ; Sun, 17 Nov 2019 17:38:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574041119; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=nbwAwcUdnWPVEB1JKWZ+IUjrXco2gPAW9jS94GOhSDHSIPs5RuOaVf7fS3u7xgTmTALqFCbdtOKLr t2RQMAeF/T83wRi4UgFSXkhlioxaDR3MhfHVesSss3TH7xX8Do61BFi8YJkRasZb3TPeSF6E4Dp98A EZu4rBmKx9OfFU2dDyC2wc8nRm08MSEY6Bx6Crt7PBfvMvQHy+O+ri6FfCENLp3IRfhrVH210whFlA Aah+Ijn91YT4aVI3hsazWHG9SIYPtKWfniFVfoYjh06pUvBUu+LyR5UYwTLv4xiSggba+8jRX3NKKb 1lAnRElsE3WyG2VDJzxoibiIKNgVDsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=lLQ0ZrQgQWtf3DBvJ9LeYb6b94hBwFW2IXap3U7i8tw=; b=vVsMiQKl/IBfQvtGPdeUilNZUB8m/4T1T3I27yFF58ihK1YkFfqUrtbmU8imMVpUtAcD651DMTLGX GkaBoC9UxTrQKxVhm6Tqwfy9A+fSj56z/YVtlbEZ8A+Mz58ecmdQfcCqlI93JSogcbR/2nK/3Wbc07 NBgdNJ73Eq+QCscTImHc29T75ilsdcw80qLPabQ/FQCwyH6qAzCN00ETCXNCh7W4yqR2ZJT7lRFHIn sdcF0ypsi4OsnQBFL5/GIFSBx6+x2U9GiJWiNd4ruRMoImAp7095guReBjCds9KRN5gEeriv6E7f6d bt+vmFZrsJcDWHTjZwiEYwe1bjx0L1Q== ARC-Authentication-Results: i=1; outbound3.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.171; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=lLQ0ZrQgQWtf3DBvJ9LeYb6b94hBwFW2IXap3U7i8tw=; b=fQEqsYJpuuImuv9nKGtoiwaPvOFt+zQZwoUEBooFXQiDhkYurtQPGgVx+ioNRs5ustxbGdSJaSJh7 13IqVNAySxreZZDAUD5k63cSb9Ul59/dSEnfNxmw8gEy8QHRli33IYrw8uF0ZoYtEc1tyqkXSXMqco Kbgkwxmf16UNqGeA= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=lLQ0ZrQgQWtf3DBvJ9LeYb6b94hBwFW2IXap3U7i8tw=; b=lIf4FZ+vncFdClsAaZvTWTJz+Na2k5G+slMBMHr5Z5ejXloZE31zXcHCk2vIQvggCN/tIdyRKteok EGVZ7+jzuCyhPwNVYihvHkK7WUmJrN3wshobzp/8hKyaApHweqPdC0FT2L1YBHrUKnxUReJH84+jIj fHR4Hln7ezbe14MYI/MdeWVhMbNVA+J/rZOS017i/MtibqsVxW22togM6A0GoEn4327TEB8+8Wwtzk v5FAgqawXwH4QqthmdyLcGEhHXtNuFuwt88awQcpQYQQLSnuAgo5tUp7bqDI3YxcbE8h3WL8I9Sle3 yWb1h44wour7jFraeTguhGHodJg8iDg== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 249f9966-09a4-11ea-b80c-052b4a66b6b2 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.167.171 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f171.google.com (unknown [209.85.167.171]) by outbound3.ore.mailhop.org (Halon) with ESMTPSA id 249f9966-09a4-11ea-b80c-052b4a66b6b2; Mon, 18 Nov 2019 01:38:38 +0000 (UTC) Received: by mail-oi1-f171.google.com with SMTP id y194so13850561oie.4 for ; Sun, 17 Nov 2019 17:38:38 -0800 (PST) X-Gm-Message-State: APjAAAXsTRJdf6RqXIpQgqPR6R9B4rSzfRlEojoy1XIN7Mo+rAQDxRTH Lf+3vHefK3YeHrlaRkcx/CKqzJFU8C53GnPAcuQ= X-Google-Smtp-Source: APXvYqx2JWOBhufsT7mZ9AWS/8Hr31W299oZdY3tco6NoIhkX5uxAeTw9rXCAL9BVWLeBTjekAGaSQ7c14GWlIKeW9U= X-Received: by 2002:a54:4181:: with SMTP id 1mr18395538oiy.58.1574041118007; Sun, 17 Nov 2019 17:38:38 -0800 (PST) MIME-Version: 1.0 References: <299277505.7138.1574037347987@appsuite-gw2.open-xchange.com> In-Reply-To: <299277505.7138.1574037347987@appsuite-gw2.open-xchange.com> From: Patrick McManus Date: Mon, 18 Nov 2019 09:38:26 +0800 X-Gmail-Original-Message-ID: Message-ID: To: Vittorio Bertola Cc: Patrick McManus , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000b367710597950139" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 01:38:43 -0000 --000000000000b367710597950139 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 18, 2019 at 8:35 AM Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > > (Of course non-well-behaved providers will always do whatever possible to > camouflage their traffic, [..] > > Seeking confidential 2 party communication with HTTPS is not non-well-behaved - it is exactly what HTTPS seeks to do. --000000000000b367710597950139 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 18, 2019 at 8:35 AM Vitto= rio Bertola <vittor= io.bertola@open-xchange.com> wrote:
=20 =20 =20

(Of course non-well-behaved providers will always do whatever possi= ble to camouflage their traffic,=C2=A0 [..]

Seeking confidential 2 party communication with H= TTPS is not non-well-behaved - it is exactly what HTTPS seeks to do.
<= div>
=C2=A0
--000000000000b367710597950139-- From nobody Sun Nov 17 17:43:34 2019 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 C018C12080E for ; Sun, 17 Nov 2019 17:43:31 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.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 df4FCMTlm7tf for ; Sun, 17 Nov 2019 17:43:30 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100070.outbound.protection.outlook.com [40.107.10.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C391D120288 for ; Sun, 17 Nov 2019 17:43:29 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ku788PIU3zwDk6tFy2/cHNpSeH8ZofN0LTsi5uY2oWMsYAF6hjbu1x/OisyAT3dVQkq+w58LibeAIam8gStaGS94AVnQ3N61MvNxI6e+zI77Dx7a7tlChiA4Rn6MTHTL40wKbNZlFh4Ir9Tm5BS+Tn12ydHcrGDGzz9LVFQqtNDuvLX0t+ynpTi0LvJG98jg3TPMbjF6t8U8h+Kkysf7qDQMCtcfclRtkzb0wfvNsu1eE7uXo17/5gZRHIJXyZH4MPHa+RVLElk2DWcNbxQVJzu2MB0Zlzf7TnakkFyKWm/JLO1a3X25o76ByUBZIjMvFShHJIS2a5dxn632kGACjQ== 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=9cbpZ8ViaZ5adKVH8lUHr19tC9IESY8+6CkzVIEb1xU=; b=PDvH2Av+tRLmcYz7Y1U5xQy0r7YIc14mjdXTc//zkZakgdn+4v2rSG4daKsOlP/kTzTUrhEgrwxTPxwg6T06h8dbrHa4KjbkPucszL+o2i9SNLTXCQ8W81tP3Cu091mTRCl2VtpSrxPXUYTO9zNpoFOr98cbbbKDYl7x8C17yoxVeJ91Kb15FLWJ4Dt/tSIY4SPXaYoa3aOCdUn9ypyMs8ditWiosCCh2KucjH4NyVcYucHP3TEPPzPVofUwXud03bXdTwsxshmHK6A69OU+rPKo2QJ2YZCMZYbyyuaXyie+5n9HpRsAp2/Ljj4OQCvNHu2pSG4qNfM7itkLOfW50g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9cbpZ8ViaZ5adKVH8lUHr19tC9IESY8+6CkzVIEb1xU=; b=LopRYC2s6dfi0pOz3D9fHq8KZOfTRdxuVrdb5s1MXd8dvPQM5zrvweZq1+4dQy1KQhp1jgsl2ODBNaXy/l6DL5LIlCM4EMGKn35tFms0/vEdJ6+Um3NYO0/HwZ5mNelzN/1eJMqwjQMHcCxlPI5d3///w2t55wuT+XMEUp8ci+Q= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB1229.GBRP265.PROD.OUTLOOK.COM (20.176.142.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.22; Mon, 18 Nov 2019 01:43:27 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 01:43:27 +0000 From: Andrew Campling To: Rob Sayre , Jari Arkko , ADD Mailing list Thread-Topic: [Add] Draft on deployment models for Internet infrastructure Thread-Index: AQHVnTeNDIqUSkRmpkepRJaNdYNopaeQIaQQ Date: Mon, 18 Nov 2019 01:43:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [31.133.154.171] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cc3e73b4-64c7-4d7d-8fb1-08d76bc8b55d x-ms-traffictypediagnostic: LO2P265MB1229: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39830400003)(366004)(376002)(136003)(189003)(199004)(86362001)(2906002)(52536014)(6506007)(7696005)(8936002)(25786009)(8676002)(81156014)(53546011)(14454004)(76176011)(508600001)(66066001)(476003)(11346002)(5660300002)(486006)(44832011)(55016002)(6246003)(9686003)(54896002)(229853002)(71200400001)(71190400001)(6306002)(446003)(186003)(14444005)(102836004)(256004)(26005)(76116006)(66946007)(33656002)(6436002)(66574012)(81166006)(99286004)(7736002)(74316002)(110136005)(3846002)(316002)(6116002)(790700001)(66476007)(66556008)(64756008)(66446008)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB1229; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xxGDjb1H4XN92awhH/ZpzzVo7hZO8pyR9PZRIpIf1U4PHglV/mLHI3Tqn9iyrQKPtDXi2nZ91+SO4Ti+iM9H2qN/nbOJdDZc54qLZk5sPxu5iVSuLaSW7wDmplYrD2KcgQGC6y3FaXMJbHxo1QPIOm7GEU5BIuYdiUNNwkuvuqCZ/m94pyql2QUher9DYojAWhdjB7sSmEmGklnvcgyACnPOVsFz047PiH+VjV11YkCsEjPggnAHWJt1Hk48CRMw4mcJJKJcWpceumNyOcF6g+7QXwQHx1aA/X+ivWGnLAeFenXpPOzFgf/nnYoZTcSUk+YZLP/gK39gL/yQ3KER6WYTaBU75024M1W8ZN16CAp4UZkchDilKJAm2YCaaGP4XcjoOQj2vvE/qdSPolnxAbAp5NcBYn5BtiAQU64MRzVSfI6ujdOxqoqDPUfR8AEx x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB057303764DF741B8F2ABE8F0C24D0LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: cc3e73b4-64c7-4d7d-8fb1-08d76bc8b55d X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 01:43:27.5654 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: K138THu1QsXfQhLil8yKmUGrHj9l2iVLcBV5aNHohbp3VyanTR5/n07Km+GUGgWlauNfi5xlTSoZTx5wHRhMQv+yJLWWspYn7/bXfnw+8Jg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1229 Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 01:43:32 -0000 --_000_LO2P265MB057303764DF741B8F2ABE8F0C24D0LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gU3VuLCBOb3YgMTcsIDIwMTkgYXQgMDM6MjQgUm9iIFNheXJlIDxzYXlyZXJAZ21haWwuY29t PiB3cm90ZToNCg0KPiBUaGUgaWRlYSB0aGF0IGVuY3J5cHRlZCBETlMgd2lsbCByZXN1bHQgaW4g aW5jcmVhc2VkIGNlbnRyYWxpemF0aW9uIGlzIHVuc3Vic3RhbnRpYXRlZC4gRm9yDQo+IGV4YW1w bGUsIHRoZSB3YXkgdW5lbmNyeXB0ZWQgRE5TIHRyYWZmaWMgZW5hYmxlcyBjZW50cmFsaXplZCBz dXJ2ZWlsbGFuY2UgYXQgdGhlIG5ldHdvcmsNCj4gbGF5ZXIgaXMgd2VsbCBrbm93biBldmVuIGlu IHBvcC1zY2llbmNlIHB1YmxpY2F0aW9uczoNCg0KR2l2ZW4gdGhlIHZhc3QgZGlmZmVyZW5jZSBi ZXR3ZWVuIHRoZSBudW1iZXIgb2YgRE5TIHJlc29sdmVycyBhbmQgRG9IIHJlc29sdmVycywgaXQg aXMgaW5ldml0YWJsZSB0aGF0IGNlbnRyYWxpemF0aW9uIHdpbGwgb2NjdXIsIGVzcGVjaWFsbHkg d2hlbiBGaXJlZm94IGlzIGN1cnJlbnRseSBlbmFibGluZyBEb0ggYnkgZGVmYXVsdCBpbiB0aGUg VVMgd2l0aCBhIHNpbmdsZSBkZWZhdWx0IHJlc29sdmVyIG9wdGlvbi4gIEFuZCB5ZXMsIHdoaWxz dCB5b3UgY2FuIGNoYW5nZSB0byBhIGRpZmZlcmVudCByZXNvbHZlciBidXQgbWFueSBwZW9wbGUg d2lsbCBsYWNrIHRoZSBzdWJqZWN0IG1hdHRlciBrbm93bGVkZ2UgdG8gZG8gdGhpcy4gIFdoZW4g eW91IHRoZW4gY29uc2lkZXIgbm9uLWJyb3dzZXIgYXBwcyBkb2luZyBEb0gsIEkgc3VzcGVjdCB0 aGF0IG1hbnkgZG9u4oCZdC93b250IGJvdGhlciB0byBldmVuIGFzayB0aGUgdXNlciBmb3IgdGhl aXIgYWdyZWVtZW50IG5vciBsZXQgdGhlbSBjb25maWd1cmUgYW4gYWx0ZXJuYXRlIHJlc29sdmVy Lg0KDQpTbyB5b3UgaGF2ZSBwb3RlbnRpYWxseSA2LTclIG9mIHRyYWZmaWMgZ29pbmcgdG8gYSBz aW5nbGUgcmVzb2x2ZXIgdGhhdCBtYXkgaGF2ZSBiZWVuIHNwcmVhZCBhY3Jvc3MgMTAwcyBvZiBy ZXNvbHZlcnMgcHJldmlvdXNseS4gIEhvdyBpcyB0aGlzIG5vdCBjZW50cmFsaXphdGlvbj8NCg0K SW4gbXkgdmlldywgdGhlIGRyYWZ0IGRvY3VtZW50IGhlbHBmdWxseSBzZXRzIG91dCB0aGUgcmlz a3MgcG9zZWQgYnkgY2VudHJhbGl6YXRpb24sIGFzIHdlbGwgYXMgaGlnaGxpZ2h0aW5nIHdoeSBz dWNoIGNlbnRyYWxpemF0aW9uIGdvZXMgYWdhaW5zdCBzb21lIG9mIHRoZSBiYXNpYyBkZXNpZ24g b2JqZWN0aXZlcyAtIHRoZSBwYXBlciByZWZlcmVuY2VzIFJGQ3MgMTk1OCBhbmQgMzkzNSB0byBz dXBwb3J0IHRoaXMgY29udGVudGlvbi4gIEkgYmVsaWV2ZSB0aGF0IHRoZSByaXNrcyBwb3NlZCBi eSBjZW50cmFsaXphdGlvbiBkbyBpbmRlZWQgYXBwbHkgdG8gRG9IIGFzIGN1cnJlbnRseSBkZXNj cmliZWQgYnkgUkZDODQ4NCBhbmQgdGhhdCBmdXJ0aGVyIHdvcmsgaXMgcmVxdWlyZWQgaW4gb3Jk ZXIgdG8gYWRkcmVzcyB0aGVzZSBzaG9ydGNvbWluZ3MuDQoNCg0KQW5kcmV3DQoNCg== --_000_LO2P265MB057303764DF741B8F2ABE8F0C24D0LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1i b3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVM7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gU3VuLCBOb3YgMTcsIDIwMTkgYXQgMDM6MjQgPHNwYW4gbGFuZz0iRU4tVVMiPlJvYiBT YXlyZSAmbHQ7c2F5cmVyQGdtYWlsLmNvbSZndDsNCjwvc3Bhbj53cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFRoZSBpZGVhIHRo YXQgZW5jcnlwdGVkIEROUyB3aWxsIHJlc3VsdCBpbiBpbmNyZWFzZWQgY2VudHJhbGl6YXRpb24g aXMgdW5zdWJzdGFudGlhdGVkLiBGb3INCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDsgPC9zcGFuPmV4YW1wbGUs IHRoZSB3YXkgdW5lbmNyeXB0ZWQgRE5TIHRyYWZmaWMgZW5hYmxlcyBjZW50cmFsaXplZCBzdXJ2 ZWlsbGFuY2UgYXQgdGhlIG5ldHdvcmsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPiZndDsgPC9zcGFuPmxheWVyIGlz IHdlbGwga25vd24gZXZlbiBpbiBwb3Atc2NpZW5jZSBwdWJsaWNhdGlvbnM6PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkdpdmVuIHRoZSB2YXN0 IGRpZmZlcmVuY2UgYmV0d2VlbiB0aGUgbnVtYmVyIG9mIEROUyByZXNvbHZlcnMgYW5kIERvSCBy ZXNvbHZlcnMsIGl0IGlzIGluZXZpdGFibGUgdGhhdCBjZW50cmFsaXphdGlvbiB3aWxsIG9jY3Vy LCBlc3BlY2lhbGx5IHdoZW4gRmlyZWZveCBpcyBjdXJyZW50bHkgZW5hYmxpbmcgRG9IIGJ5IGRl ZmF1bHQgaW4gdGhlIFVTIHdpdGggYSBzaW5nbGUgZGVmYXVsdCByZXNvbHZlciBvcHRpb24uJm5i c3A7DQogQW5kIHllcywgd2hpbHN0IHlvdSBjYW4gY2hhbmdlIHRvIGEgZGlmZmVyZW50IHJlc29s dmVyIGJ1dCBtYW55IHBlb3BsZSB3aWxsIGxhY2sgdGhlIHN1YmplY3QgbWF0dGVyIGtub3dsZWRn ZSB0byBkbyB0aGlzLiZuYnNwOyBXaGVuIHlvdSB0aGVuIGNvbnNpZGVyIG5vbi1icm93c2VyIGFw cHMgZG9pbmcgRG9ILCBJIHN1c3BlY3QgdGhhdCBtYW55IGRvbuKAmXQvd29udCBib3RoZXIgdG8g ZXZlbiBhc2sgdGhlIHVzZXIgZm9yIHRoZWlyIGFncmVlbWVudCBub3INCiBsZXQgdGhlbSBjb25m aWd1cmUgYW4gYWx0ZXJuYXRlIHJlc29sdmVyLiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U28geW91IGhhdmUgcG90ZW50aWFsbHkgNi03JSBvZiB0cmFmZmljIGdvaW5nIHRvIGEgc2lu Z2xlIHJlc29sdmVyIHRoYXQgbWF5IGhhdmUgYmVlbiBzcHJlYWQgYWNyb3NzIDEwMHMgb2YgcmVz b2x2ZXJzIHByZXZpb3VzbHkuJm5ic3A7IEhvdyBpcyB0aGlzIG5vdCBjZW50cmFsaXphdGlvbj8m bmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBteSB2aWV3LCB0aGUgZHJhZnQgZG9j dW1lbnQgaGVscGZ1bGx5IHNldHMgb3V0IHRoZSByaXNrcyBwb3NlZCBieSBjZW50cmFsaXphdGlv biwgYXMgd2VsbCBhcyBoaWdobGlnaHRpbmcgd2h5IHN1Y2ggY2VudHJhbGl6YXRpb24gZ29lcyBh Z2FpbnN0IHNvbWUgb2YgdGhlIGJhc2ljIGRlc2lnbiBvYmplY3RpdmVzIC0gdGhlIHBhcGVyIHJl ZmVyZW5jZXMgUkZDcyAxOTU4IGFuZCAzOTM1IHRvIHN1cHBvcnQgdGhpcw0KIGNvbnRlbnRpb24u Jm5ic3A7IEkgYmVsaWV2ZSB0aGF0IHRoZSByaXNrcyBwb3NlZCBieSBjZW50cmFsaXphdGlvbiBk byBpbmRlZWQgYXBwbHkgdG8gRG9IIGFzIGN1cnJlbnRseSBkZXNjcmliZWQgYnkgUkZDODQ4NCBh bmQgdGhhdCBmdXJ0aGVyIHdvcmsgaXMgcmVxdWlyZWQgaW4gb3JkZXIgdG8gYWRkcmVzcyB0aGVz ZSBzaG9ydGNvbWluZ3MuJm5ic3A7DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmRyZXcgPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_LO2P265MB057303764DF741B8F2ABE8F0C24D0LO2P265MB0573GBRP_-- From nobody Sun Nov 17 17:53:21 2019 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 9D12C120288 for ; Sun, 17 Nov 2019 17:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.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 YvCfsdFGPFK5 for ; Sun, 17 Nov 2019 17:53:17 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110055.outbound.protection.outlook.com [40.107.11.55]) (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 6B18C120048 for ; Sun, 17 Nov 2019 17:53:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GGb5H6wkHHTdRbw4Ev8GEZW4ZiiP44xfjaIms9BkMae3i29G7BYc0n98OWDBwOflVEttoYHQ3RT8GXDV6t+i5SjYivPHhwnkE1v9ruQbCN6WMnDJ+TRPWwjxq7csahywrFgtavolJiMCvfm3GXQvkS8et1n6Je9+u7khciq7IIdnVrRSIw5oY8BbQ7l2CUj0ArPJJ6o3NzoZi+f8dcF+o9No9uqHycEmH4sG/8fNTs35mxFKWKtX4NiTG73NT6ESTdf/YZixyiU5K3AF1CRz8U30v354CoSc5AV7ewBt4MW/VssW6fgAxLQZRuSmRxPoNY4X05VX3IniL3AlPwzl1g== 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=ctbd3kLqTBOhv0SQdExsP4k0Awqgxf63ih0wjlqreKE=; b=An6fZUL1mLbQOufT65kcmmQNpSIHr8XfclIlWHdVNjThnuZxjp3g8V5Jmyk7bCA8JBt5dIzBMJYwaXNs7AtbVFlQtdqP2NDHpefgfNXh/tYhnIPcpfdR5/qamTvYDbsjRxwFYI4+ermPlyG0gJel9eurtL9WhkUN3n6M/gB/eRDhyjqT8dCxdI602QCmSET5iUFKZhbPoy5w6Td6c8qWys1qU0hUV0KKe3kqguZP2XbG/5k1UXpo9maU4usZl0EqVb+l0bJyzdPmYuKynNRtbU8WTX38GnSBnywI1SFER+uQOTx14STUXskKalF2NOQ/lBd/PZxFog9xVknCkCYebw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ctbd3kLqTBOhv0SQdExsP4k0Awqgxf63ih0wjlqreKE=; b=YzTLHkj1Py/anVCWEndUMwvCHRocS85+yzY2FIZtienPMkXW2RnHfQmctyfIxjlu2XDhCizBfn50W7by/ijBsQ02k7ow+5i76l99Vv0xadvPnMSfvPOtaK8/vTLLlbiR7Ae0QfeSnOYYUhNrob9K1abTZlrHo39zVJjvNDwgwLE= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB0208.GBRP265.PROD.OUTLOOK.COM (10.166.99.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.29; Mon, 18 Nov 2019 01:53:14 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 01:53:14 +0000 From: Andrew Campling To: S Moonesamy , Jari Arkko , "add@ietf.org" Thread-Topic: [Add] Draft on deployment models for Internet infrastructure Thread-Index: AQHVnTeNCX7ZBpaaJEuhoVUjJ09Cm6eQKQhg Date: Mon, 18 Nov 2019 01:53:14 +0000 Message-ID: References: <6.2.5.6.2.20191116232455.10209e78@elandnews.com> In-Reply-To: <6.2.5.6.2.20191116232455.10209e78@elandnews.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [31.133.154.171] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 49bbc8e6-2d2d-4a7d-1534-08d76bca1364 x-ms-traffictypediagnostic: LO2P265MB0208: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39830400003)(366004)(136003)(376002)(346002)(396003)(199004)(189003)(71200400001)(186003)(44832011)(2906002)(508600001)(99286004)(316002)(14444005)(64756008)(8676002)(256004)(76116006)(110136005)(55016002)(86362001)(4744005)(14454004)(25786009)(2501003)(6246003)(9686003)(5660300002)(6116002)(3846002)(229853002)(486006)(66066001)(66946007)(66476007)(66556008)(8936002)(81156014)(52536014)(81166006)(71190400001)(476003)(11346002)(446003)(6436002)(6506007)(33656002)(102836004)(305945005)(76176011)(74316002)(7696005)(26005)(7736002)(66446008)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB0208; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YCTfjUKbpBaDPjUN0UyT5hll+C7sJEqUN+rJrv284wnH2ZEKeT4OAvq3YWBM0Z9AgWTmPJm7t0EqPrZbktPCcuNLS9LAH4JpakzcsMX+2RPJT4UL65ZjSoT00yfhLK7BEcm0S63ZQ6rpkZdxDMxJqfgKBLuY41n7REfXrugg7TOE54T2EDs1LPNhrIDDEV6aAPB9nb8uhNghrZkyFPlWOvMLeBwmYbKDO29rSY8kyBFkbYVQL8kRoeAx+ri7quJ4mCF4He16PmvV4PFlg8tSERB3HxcQNDAmaNXJFGTUQOdxfRgKuKfsVIF3Fj1XVDhMlU4EMT45jwsuXfUR90xaZvRVicU9/vb5oOe1Vjm5G20VwWfc6cxtlBmR0VjLis5wPLYQLbICAmMBvlUIlexZnXPXXMXRoiNENxuI+pjcdo6MVg5E2pkG/GAUeM8idCKI x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 49bbc8e6-2d2d-4a7d-1534-08d76bca1364 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 01:53:14.8057 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 3DS68I/S1ktX6/ybmZfyxV0OkJz3lHpKVoUGjwUhWnFAzS0TUOH0W9JOaBuMpzWFq58ykuNaoLSVZ6mSsfq5Wtgllq3G/E0v4GceG9DV2y8= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0208 Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 01:53:20 -0000 At 07:57 17-11-2019, S Moonesamy wrote: > Commenting about jurisdiction, an IETF Area Director was quoted as statin= g that: "[DoH] will=20 > allow journalists in hostile regimes to do their jobs more safely, or peo= ple in heavily censored=20 > countries to get access to the truth". First of all, that is a very narr= ow use-case. Secondly, the=20 > argument of "getting access to the truth" sounds very convenient. I agree that the use case is indeed very narrow. I'd add that better tools= are already available to aid dissidents and others that do not impair the = use of the web by other large groups (eg children, enterprise users etc) an= d in any case question the validity of the dissident use case for DoH, do = not believe that it stands up to examination. Andrew=20 From nobody Sun Nov 17 18:03:00 2019 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 928D41207FD for ; Sun, 17 Nov 2019 18:02:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JwdTI_Ou6zuE for ; Sun, 17 Nov 2019 18:02:56 -0800 (PST) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 B0288120048 for ; Sun, 17 Nov 2019 18:02:56 -0800 (PST) Received: by mail-ua1-x929.google.com with SMTP id w10so2259227uar.12 for ; Sun, 17 Nov 2019 18:02:56 -0800 (PST) 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=FPBYTDXlAN2szcfQv7PSSFssL1lm/HgnHJDt0x00Jv8=; b=S3B1V1izGmWGBRwLcu8XVquUDkBNVHW/Olq2/TTCzoR8aIMWotGV340hrx5BS9g4GP yAo5WYsrVcL/XfwocHHTH/hHjda1ogEMRKahBulqMbDi4FtXHDq8B8E93Wt1MFE52H7M RHizateX64urpFdjrrEon1jy8EHsXN8LbNqs6hHa+kJtJVYyy4qccsPopG2LcUg9yvX1 tYEXNdHWqhQV8b+fpsUl0iISreFKoHrSzJZdQB1gX/2wIwPffOVscP5RiFd3f0pZsy+D J9QKrjXwdFJQBS5r7qPDTuknTPUPHX4++MPDR1371ml6bGV5divzmzA3Tmqpre95LeZT uQRw== 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=FPBYTDXlAN2szcfQv7PSSFssL1lm/HgnHJDt0x00Jv8=; b=rk4WGGG193GuHU/60hVT3HZpFOPKtfccSzoKfsGu1zGJbkSFCneI0wu1YE33xuswXy IFqITPhhgaw+LAbXcWGyfixtfiumrL4c5jqmnPOkp/LmX/XkcBgQQNmCAEIWoEL2CQAM +ZaXTfm/mwgYKDz+lemvXnEQWPbl/7wTe6KkWsUvZiP4cI8cWfuv2K1sgSkldYc2XVk8 x0OMGH+qRxM/cqzXl0a4rg7XXjuTvF4rmRiZxpoZROjbHdKcASzZmtbWuf1rGipOWCHk dwb+Gs+wy3Y9Vfy8WBZYPSJ+v528PHWTNho5HDdjTEas/JUyqN7eBt/d6RoBUSrRvxrU Yz6g== X-Gm-Message-State: APjAAAWnGGARfId8Y8ev7XdMZhSkuVaEWPHjFm0bvE3FMmFRBTNft21k MBvPcEpLHQfBtmqPmz5buhpAL7NgxtDCbyPVERNbt5/k X-Google-Smtp-Source: APXvYqzloZSG1RzPuJeQEAa0bfKRhpvgXwmlF7159Q2K+iLNL+vxL4OUoRGI6TepR/6ckp0xyvIvXt0Ow0MNWq6AIWo= X-Received: by 2002:ab0:189a:: with SMTP id t26mr15964327uag.87.1574042575522; Sun, 17 Nov 2019 18:02:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Dickson Date: Mon, 18 Nov 2019 10:02:39 +0800 Message-ID: To: Patrick McManus Cc: Ben Schwartz , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000009351af0597955863" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 02:02:59 -0000 --0000000000009351af0597955863 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 17, 2019 at 11:02 PM Patrick McManus wrote: > DoH does not require any particular port number - the server specifies it > as part of the URI Template and there is no default template. You cannot > make another port number the default for https (which doh does required) > without minting another scheme, which seems kind of pointless when you can > simply explicitly use another port as part of the template if you like. > The default for HTTPS is just that - a default. RFC2818 is very clear, that any transport can be used, and the default is just a default. Revising 8484 to specify a particular default to use for DoH would be pretty simple, and supported by any protocol stack that supports HTTPS. Recall: HTTPS uses the HTTP URI scheme, which requires support for an optional ":port" parameter. So, modifying what is done under the hood on a browser is literally as simple as changing the embedded DoH stuff to append ":DOH_PORT" to the DoH server name/IP. No new minting required. I'm not concerned with the Template contents, only the base URI from which the template is obtained. > > Handcuffing the protocol to introduce intentional network signaling would > weaken the confidentiality properties of HTTPS - i.e. it is quite explicit > that any HTTPS content (or purpose) is not visible to the network and allow > network attackers to trivially launch downgrade attacks. That isn't in the > interest of securing a protocol. > In my original message, I pointed out that this is already the case. The public DNS resolvers offering DoH do not offer any other services on the IP address(es) used for DNS. This weakening already exists and is intractable based on the operators' practices. The purpose can be trivially inferred by the IP addresses of those servers. In fact, the browsers themselves publish such a list of addresses, in their TRR (or equivalent) tables. > > This thread is probably a good example of how ABCD would not be a > productive working group. > Notwithstanding how you feel about this particular suggestion, I think it unfair to the rest of the ABCD participants to take this stance. It is ad hominem pluribus. No offense intended. Brian --0000000000009351af0597955863 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 17, 2019 at 11:02 PM Patr= ick McManus <mcmanus@ducksong.co= m> wrote:
DoH does not require any particular port number - th= e server specifies it as part of the URI Template and there is no default t= emplate. You cannot make another port number the default for https (which d= oh does required) without minting another scheme, which seems kind of point= less when you can simply explicitly use another port as part of the templat= e if you like.

The default for = HTTPS is just that - a default. RFC2818 is very clear, that any transport c= an be used, and the default is just a default.
Revising 8484 to s= pecify a particular default to use for DoH would be pretty simple, and supp= orted by any protocol stack that supports HTTPS.

R= ecall: HTTPS uses the HTTP URI scheme, which requires support for an option= al ":port" parameter.=C2=A0

So, modifyin= g what=C2=A0is done under the hood on a browser is literally as simple as c= hanging the embedded DoH stuff to append ":DOH_PORT" to the DoH s= erver name/IP.

No new minting required.
<= div>
I'm not concerned with the Template contents, only t= he base URI from which the template is obtained.
=C2=A0

Handcuffing the protocol to introduce intentional network signaling= would weaken the confidentiality properties of HTTPS - i.e. it is quite ex= plicit that any HTTPS content (or purpose) is not visible to the network an= d allow network attackers to trivially launch downgrade attacks. That isn&#= 39;t in the interest of securing a protocol.
<= br>
In my original message, I pointed out that this is already th= e case. The public DNS resolvers offering DoH do not offer any other servic= es on the IP address(es) used for DNS.
This weakening already exi= sts and is intractable based on the operators' practices.=C2=A0
The purpose can be trivially inferred by the IP addresses of those serve= rs.
In fact, the browsers themselves publish such a list of addre= sses, in their TRR (or equivalent) tables.
=C2=A0

This thread is probably a good example of how ABCD would not be a product= ive working group.

Notwithstand= ing how you feel about this particular suggestion, I think it unfair to the= rest of the ABCD participants to take this stance. It is ad hominem plurib= us.

No offense intended.

= Brian=C2=A0
--0000000000009351af0597955863-- From nobody Sun Nov 17 18:06:44 2019 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 44C3B12011F for ; Sun, 17 Nov 2019 18:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wf8COL1b6t4P for ; Sun, 17 Nov 2019 18:06:41 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 79184120048 for ; Sun, 17 Nov 2019 18:06:41 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id s3so16931871ioe.3 for ; Sun, 17 Nov 2019 18:06:41 -0800 (PST) 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=u0DYytJapNw0b2ExI3yGzFhrJoFVg9Hy/VxMl1QvOUc=; b=DIjEZQBwUshZjqzLDrsp25sp1AeoDqaSr7hsw5/FVbngYyf4RMiUJV84dV97gRIjWc +ky0GDb4xYyYQtkoVc0AetAiQURb20rqtLKkbDdwMsk6eAA6RvzbJS/SsUk8XHDAOp/5 rWkshHsDZXxbm6hNx3GbAQA2LAZAKUFzBq++mgZxgO8f+mmKXsTJFUNTRCYl4VQzLhK7 rBaEZwBp04FGJ0XBOzPFyYGJvW+W5dnoNFTk68bceP5wWNpuzjGu9cwJX0CNo5572y76 AGr9DZhWRMRN/h/i+V2L6yAfFCOSPsKBeptJHK9af5VydRIn4NowGjsubi0O1DTEtEeU mLbA== 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=u0DYytJapNw0b2ExI3yGzFhrJoFVg9Hy/VxMl1QvOUc=; b=ZFCapG6OdRhMoompmspeMvtBhpcSOPpsoNuUp1dOjIZzJmpBm6Na89hHFpnl1m1LZu q/MOI9NBRwKUXQotuBPPw0fBBzfkvCH9eN1AHqshqfIr4gV49e5xlb4BPaiBZEV0BSAM LoggSNdFcSh/ovmSr1+U16YCcyCs67Zm/0bTZVlQZchp+gCR0wg6lV+/jkvgxpQZ+1qj whz2Zrow+J7++E7sHqpIVk4KAwvAVJ5lo0HTAOYC8z7o4bJH+dvxZkpXsimCamWIMCCI 9XgaVyCSbgefMV3KLEed9LqWawkWKuS7mKoZ2vfPGjNTUMSOsCNp7/iuFlogf/nnQu/G 7sMQ== X-Gm-Message-State: APjAAAXzVdy8A7pOMNxmTIdGXZPJZgikhO51sjVvPGbqRwM0aUeOY8Zs +LB06/OgmN6cpDMIDmvF5v78XlyuZl1ovYqygQD1YUMQ X-Google-Smtp-Source: APXvYqyZIQnBz6ugo4GLXiGMoUZLv9IYOKdOSD0GSYmcR3al5x+7CbUHGJgN8njgqo4h7sm6+ksb47Eucj7/6pdlijo= X-Received: by 2002:a05:6602:8c:: with SMTP id h12mr11220668iob.254.1574042800544; Sun, 17 Nov 2019 18:06:40 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Sun, 17 Nov 2019 18:06:29 -0800 Message-ID: To: Andrew Campling Cc: Jari Arkko , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000fce26105979565b8" Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 02:06:43 -0000 --000000000000fce26105979565b8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 17, 2019 at 5:43 PM Andrew Campling wrote: > On Sun, Nov 17, 2019 at 03:24 Rob Sayre wrote: > > > > > The idea that encrypted DNS will result in increased centralization is > unsubstantiated. For > > > example, the way unencrypted DNS traffic enables centralized > surveillance at the network > > > layer is well known even in pop-science publications: > > > > Given the vast difference between the number of DNS resolvers and DoH > resolvers, it is inevitable that centralization will occur, especially wh= en > Firefox is currently enabling DoH by default in the US with a single > default resolver option. > DNS has been around for 30 years, and DoH for about 1, if that. I'd expect there to be a difference in number. FWIW, I'm already using Comcast's DoH trial server. > And yes, whilst you can change to a different resolver but many people > will lack the subject matter knowledge to do this. When you then conside= r > non-browser apps doing DoH, I suspect that many don=E2=80=99t/wont bother= to even > ask the user for their agreement nor let them configure an alternate > resolver. > That's true. They already do this. > > > So you have potentially 6-7% of traffic going to a single resolver that > may have been spread across 100s of resolvers previously. How is this no= t > centralization? > Well, that estimate is vastly off even for browsers, since you seem to be looking at desktop data. Counting mobile, it would be around 4% of browser usage in the US. And that's only browser traffic... Even then, lots of seemingly distinct resolvers just point at Google DNS or other centralized resolvers. The level of decentralization in the current system is overstated. In any case, my point was that encrypted DNS does not introduce a new centralized surveillance risk. That just happens in lower layers right now. > > > In my view, the draft document helpfully sets out the risks posed by > centralization, as well as highlighting why such centralization goes > against some of the basic design objectives - the paper references RFCs > 1958 and 3935 to support this contention. I believe that the risks posed > by centralization do indeed apply to DoH as currently described by RFC848= 4 > and that further work is required in order to address these shortcomings. > I think this opinion depends on whether one views DNS as special vs other traffic. I don't--it's just another protocol. thanks, Rob --000000000000fce26105979565b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Nov 17, 2019 at 5:43 PM Andrew Ca= mpling <andrew.campling@419.consulting> wrote:

On Sun, Nov 17, 2019 at 03:24 R= ob Sayre <sayrer@g= mail.com> wrote:

=C2=A0<= /span>

> The idea that encrypted DNS will result in incr= eased centralization is unsubstantiated. For

> example, = the way unencrypted DNS traffic enables centralized surveillance at the net= work

> layer is = well known even in pop-science publications:

=C2=A0

Given the vast difference between the number of DNS = resolvers and DoH resolvers, it is inevitable that centralization will occu= r, especially when Firefox is currently enabling DoH by default in the US w= ith a single default resolver option.=C2=A0


DNS has = been around for 30 years, and DoH for about 1, if that. I'd expect ther= e to be a difference in number. FWIW, I'm already using Comcast's D= oH trial server.

=C2=A0

And ye= s, whilst you can change to a different resolver but many people will lack = the subject matter knowledge to do this.=C2=A0 When you then consider non-b= rowser apps doing DoH, I suspect that many don=E2=80=99t/wont bother to eve= n ask the user for their agreement nor let them configure an alternate resolver.=C2=A0


That's true. They already do th= is.

=C2=A0

=C2=A0

So you have potentially 6-7% of traffic going to a s= ingle resolver that may have been spread across 100s of resolvers previousl= y.=C2=A0 How is this not centralization?=C2=A0

<= /div>

Well, that estimate is vastly off eve= n for browsers, since you seem to be looking at desktop data. Counting mobi= le, it would be around 4% of browser usage in the US. And that's only b= rowser traffic...

Even then, lots of seemingly dis= tinct resolvers just point at Google DNS or other centralized resolvers. Th= e level of decentralization in the current system is overstated. In any cas= e, my point was that encrypted DNS does not introduce a new centralized sur= veillance risk. That just happens in lower layers right now.

=
=C2=A0
<= div>

=C2=A0

In my view, the draft document helpfully sets out th= e risks posed by centralization, as well as highlighting why such centraliz= ation goes against some of the basic design objectives - the paper referenc= es RFCs 1958 and 3935 to support this contention.=C2=A0 I believe that the risks posed by centralization do inde= ed apply to DoH as currently described by RFC8484 and that further work is = required in order to address these shortcomings.=C2=A0


I think this opinion depends = on whether one views DNS as special vs other traffic. I don't--it's= just another protocol.

thanks,
Rob
=C2=A0
--000000000000fce26105979565b8-- From nobody Sun Nov 17 18:08:11 2019 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 0FFB612083C for ; Sun, 17 Nov 2019 18:08:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 QTDSlA8L9dM6 for ; Sun, 17 Nov 2019 18:08:08 -0800 (PST) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97A2712011F for ; Sun, 17 Nov 2019 18:08:08 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id EE38F37401FA; Sun, 17 Nov 2019 18:08:07 -0800 (PST) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id AD1D51969BB0; Mon, 18 Nov 2019 10:08:06 +0800 (+08) Received: from dhcp-984c.meeting.ietf.org (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id ACAB71969BAF; Mon, 18 Nov 2019 10:08:06 +0800 (+08) From: Paul Ebersman To: Andrew Campling cc: "add@ietf.org" In-reply-to: References: <6.2.5.6.2.20191116232455.10209e78@elandnews.com> Comments: In-reply-to Andrew Campling message dated "Mon, 18 Nov 2019 01:53:14 +0000." X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15151.1574042886.1@dhcp-984c.meeting.ietf.org> Date: Mon, 18 Nov 2019 10:08:06 +0800 Message-Id: <20191118020806.AD1D51969BB0@fafnir.remote.dragon.net> Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 02:08:10 -0000 sm> Commenting about jurisdiction, an IETF Area Director was quoted as sm> stating that: "[DoH] will allow journalists in hostile regimes to do sm> their jobs more safely, or people in heavily censored countries to sm> get access to the truth". First of all, that is a very narrow sm> use-case. Secondly, the argument of "getting access to the truth" sm> sounds very convenient. acampling> I agree that the use case is indeed very narrow. I'd add acampling> that better tools are already available to aid dissidents and acampling> others that do not impair the use of the web by other large acampling> groups (eg children, enterprise users etc) and in any case acampling> question the validity of the dissident use case for DoH, do acampling> not believe that it stands up to examination. Agreed. Tor/VPN and similar solve the dissident case; DoH is an insufficient protection against state actors or folks with similar resources. From nobody Sun Nov 17 18:11:36 2019 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 3019D1207FD for ; Sun, 17 Nov 2019 18:11:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.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 8ukZ0nZx4LC8 for ; Sun, 17 Nov 2019 18:11:33 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100047.outbound.protection.outlook.com [40.107.10.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF190120048 for ; Sun, 17 Nov 2019 18:11:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=arQUyX8n62H5YYW4X4IeWRtj3dukgKvQ1/NyUmBD+1cL+OXJTkLdpMVUFFlxnva9NKkfrmQkLM4tiGxli1HG7POVwnYE5mf2f9oaYJEBTAEmpRUWU54V3GqkM8l4HYBegzLUXxmAHeWJEoHsjrpVWhLH+FswbrxcnAf139g5mqcR7BoPwRIckheapt6uhA+ACCi11dP9KfGFqHFDp9j2bgyeACmLghFVwNyCUkM/vDNmq86ftRgR9PavnuLuvuPL5uGTCovkfOAzhJdtEX//K/8/rAYFDzbnXmeGD3mogpS839KP9u8Wd4a9nExgfddBB81heYqgud0umySj/V+OCg== 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=y41ByIeS517Iz6h76rnfzwurhdwq/YDyB9pWkR8bzeo=; b=YvqeeX38dzmuelRTvkMgGyMBKXKISHgzosHPDJObRiHYPwyPBdO3kt6aShTGdMQ26EuswKma7YTGu8kZ40+buM3eCa69iqLsWPeew9x7DwOL6lESaH2a+WcsI5uOtUDg1xXPshcKpS6Z0Axr5ZFXc0CL2x0NW6MwgUEBqJpa0GxcMBk5/kbfoVX9zFrf7NCbnCQuP26x1nzhShXe3dPJF401gvSbI9gdezcm8JyEkWeSoA9n04LfiWbkdfr5nAMJ9e0hleDMEeoWhYlAv0Cpibevz8ySurciQRqyRwW90vANUWANToTUj0rShNg1Ldx7iQlhEJ0xgAsoU/UxSpW89w== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=y41ByIeS517Iz6h76rnfzwurhdwq/YDyB9pWkR8bzeo=; b=kALC9PT0iQ+QRW/z61E5hOPfidB50AWhh8E5wawRpMeIGLWv9jXGH/pbCIO11iM3/U8zU7JIgsVLBxJjN3ULqIxJzu+02OZPPhBO4HfbLEUpA+/3W366n+S2fkQzXVk+LsEi4plQZI9KYhHXet0fxQSHTI8IxfpE2qADDlgcmA0= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB0783.GBRP265.PROD.OUTLOOK.COM (10.166.103.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.30; Mon, 18 Nov 2019 02:11:30 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 02:11:30 +0000 From: Andrew Campling To: Vittorio Bertola , S Moonesamy , "add@ietf.org" Thread-Topic: [Add] Draft on deployment models for Internet infrastructure Thread-Index: AQHVnbV8DIqUSkRmpkepRJaNdYNopQ== Date: Mon, 18 Nov 2019 02:11:30 +0000 Message-ID: References: <6.2.5.6.2.20191116232455.10209e78@elandnews.com> <2105867190.7141.1574038197898@appsuite-gw2.open-xchange.com> In-Reply-To: <2105867190.7141.1574038197898@appsuite-gw2.open-xchange.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [31.133.154.171] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 639c2c8c-b8b6-412e-3c9e-08d76bcca081 x-ms-traffictypediagnostic: LO2P265MB0783: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(136003)(39830400003)(376002)(366004)(199004)(189003)(7736002)(305945005)(6116002)(3846002)(256004)(71200400001)(71190400001)(74316002)(66556008)(66946007)(66446008)(66476007)(14444005)(5660300002)(508600001)(76116006)(25786009)(14454004)(316002)(66066001)(486006)(6246003)(102836004)(229853002)(52536014)(64756008)(44832011)(6436002)(110136005)(55016002)(446003)(2501003)(99286004)(186003)(81166006)(81156014)(8676002)(26005)(9686003)(11346002)(76176011)(33656002)(7696005)(86362001)(2906002)(6506007)(476003)(8936002)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB0783; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: RquNbN5BoaUrAG3zBUVlXa/ic7kq7gbl7JGoc3crm8owIA0HVcNWAZPMgrInJf0xRmUh5HEDSX+y+iib/cfn6crdsXK2vvdecB8Wp7XzWjNr8v5uYW73l/ds/nsyQO97zhofaEdGtrXt8uYZ6EOZkBiGDGyzypvjzm31xrl1+Q9EwKrCB1FjgxR8gjOHEkl1qfiLI+PU77URI2fqCiycBLdfMQONgeKgEAWBHkIb2ErvG/l7jmr1qCdx16+wTmBubSWomgOMRKfGEBB6RmnEJA2+RP7+egFt1G5Kh4M+sdOLCCxoHhR6rHRYtGYH+hgsFe+3prxfIDhVQ7a6em8EZ+bbEJAXgn9Ma4acn+L+WABDAUEX7py6YEjgVJ2tapZxWg1QU991Bt/E1RQVCyWLdRXffAQbp+cTaW4IV2peUU13QnBW2FhzAIQu1Cw2AB0d x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 639c2c8c-b8b6-412e-3c9e-08d76bcca081 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 02:11:30.6039 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: FtM4BG0N/NVr4Q+XOOUIHrqKNYh+shHC3XfVgf0oOzOjrrYqzdS80n0Dw9QSXRyM6jvw3Q5BF4LglLuPAiIzKnbUzclw1FYa/Pve7a/cJGU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0783 Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 02:11:35 -0000 T24gU3VuLCBOb3YgMTgsIDIwMTkgYXQgMDA6NTAgVml0dG9yaW8gQmVydG9sYSA8dml0dG9yaW8u YmVydG9sYUBvcGVuLXhjaGFuZ2UuY29tPg0KDQo+IEkgc3RpbGwgZmluZCBpdCB3ZWlyZCB0aGF0 IHBlb3BsZSBhdCB0aGUgSUVURiBjaGFsbGVuZ2UganVyaXNkaWN0aW9uIGFuZCBuYXRpb25hbCBz b3ZlcmVpZ250eSBzbyBkaXJlY3RseS4gDQo+IFdoZXRoZXIgd2UgbGlrZSBpdCBvciBub3QsIHRo YXQgY29uY2VwdCBpcyB3aGF0IGtlZXBzIHRoZSB3b3JsZCB0b2dldGhlciBhbmQgbW9yZSBvciBs ZXNzIGF0IHBlYWNlLCANCj4gZ3JhbnRpbmcgcGVvcGxlcyB0aGUgcmlnaHQgdG8gc2VsZi1nb3Zl cm4uIEluIHRoZSBlbmQsIGEgZ29vZCBhcmNoaXRlY3R1cmUgZm9yIHRoZSBETlMgd291bGQgc3Vw cG9ydCANCj4gdGhlIGFiaWxpdHkgb2YgZWFjaCBjb3VudHJ5IHRvIG1ha2UgYW5kIGVuZm9yY2Ug cnVsZXMgb3ZlciB0aGVpciBjaXRpemVucycgdXNlIG9mIGl0LiBUaGUgb3Bwb3NpdGUsIGluIA0K PiB0aGUgZW5kLCBpcyBvbmx5IGdvaW5nIHRvIHJlcGxhY2Ugb25lIGp1cmlzZGljdGlvbiB3aXRo IGFub3RoZXIsIHdoaWNoIGlzIHVuYWNjZXB0YWJsZSB0byBldmVuIHRoZSANCj4gbW9zdCBkZW1v Y3JhdGljIGdvdmVybm1lbnRzLg0KDQpJIGFncmVlLCBhbSBjb25jZXJuZWQgYXQgdGhlIGFwcGFy ZW50IGxhY2sgb2YgcmVjb2duaXRpb24gb2YgdGhlIHBvb3IgcmVwdXRhdGlvbiB0aGF0IHRoZSB0 ZWNoIHNlY3RvciBoYXMgd2hlbiBpdCBjb21lcyB0byBtYXR0ZXJzIHN1Y2ggYXMgcHJpdmFjeSBp biBtYW55IHBhcnRzIG9mIHRoZSB3b3JsZC4gIFJhdGhlciB0aGFuIGhhdmUgYSBwb2xpY3kgb2Yg dHJlYXRpbmcgdGhlIG5ldHdvcmsgYXMgYW4gZW5lbXksIHRoZXJlIGlzIGEgY2FzZSBmb3IgZG9p bmcgdGhpcyB3aXRoIHRoZSBlbmQgcG9pbnRzIGluIG9yZGVyIHRvIHByb3RlY3QgdXNlcnMgZm9y IGJhZGx5IGJlaGF2ZWQgYXBwbGljYXRpb25zLiAgDQoNCkl0IGlzIGluZXZpdGFibGUgdGhhdCBn b3Zlcm5tZW50cyB3aWxsIGFzc2VydCB0aGVpciByaWdodCB0byBhcHBseSBuYXRpb25hbC9yZWdp b25hbCByZWd1bGF0aW9uIHRvIHRlY2ggbWF0dGVycyAtIGZvciBleGFtcGxlLCBpbiBFdXJvcGUg RE5TIGZhbGxzIHdpdGhpbiB0aGUgc2NvcGUgb2YgYm90aCBHRFBSIGFuZCBlUHJpdmFjeSwgYXMg d2VsbCBhcyBhbnkgbmF0aW9uYWwgcmVndWxhdGlvbnMuICBPcmdhbmlzYXRpb25zIHRoYXQgaWdu b3JlIHRoZXNlIHdpbGwgZmFjZSBiZWluZyBsb2NrZWQgb3V0IG9mIGxhcmdlIG1hcmtldHMgQXNo d2VsbCBhcyBmYWNpbmcgcG9zc2libGUgZW5mb3JjZW1lbnQgYWN0aW9uLiAgDQoNCg0KQW5kcmV3 IA0K From nobody Sun Nov 17 18:19:14 2019 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 4039612083E for ; Sun, 17 Nov 2019 18:19:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TyrTl8jasir0 for ; Sun, 17 Nov 2019 18:19:11 -0800 (PST) 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 F0A961207FD for ; Sun, 17 Nov 2019 18:19:10 -0800 (PST) Received: by mail-ua1-x935.google.com with SMTP id l38so4732921uad.4 for ; Sun, 17 Nov 2019 18:19:10 -0800 (PST) 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=pKDukdHxuBEd1Qy0SFhZa2I3PKUG3bLQFZfxNKRXNn4=; b=EbRG89xEvXEi8dWtOUd9EEeaCntxWY9Q2caTvZ+qM7yUj68g4hMRDmTXyOBPxmjTa+ jgFVv+PHzMwMKljhU4EgqXCb9cy1LzEfREmshbDTg73f9gQ7dFN2lfcMEUycydJzh4zK tC1Ec9EWEHZ1aLwGMnlkFtHA3ZPxQUPwvkR37ayaHYw87CLIfYc45haDhcYoaXppmaJy oO02XAl3xEql8frcvGhlVsbgq5asebHY6HsCbLyYlekph77GdMrArGv7IluOmjAERWyf VpYcWsEM5A2SbU0osDANu8wCSTPxsz47JMYg2zdx2GiAnJoyFb8qhdOVN1Vyb1udyRyk J+AQ== 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=pKDukdHxuBEd1Qy0SFhZa2I3PKUG3bLQFZfxNKRXNn4=; b=C0SGwCqkH/Ph8z10ei7PuZdcW5RXTyKweGat2jzF36Th+UNUEX1dYqkK5RpmuMwvPA ju0YKMQ4WuWEan+5XvPZ+HDJ2KP8le/Sr8gp9aALPq4QsiSsXK5QOn+wXj4itzFSTPw8 zDA/HfyC+zgIAONr9ieFit3jXgIm7gZqPNMiGW5gPFRYYTVXjhv6dl7F2Eht3o+RhFqI 2OYlW0xyiv9rnHFq/APwPDlS89HFILazI+kox2yQVB8H9h5CSImQNXMI2mD4/Ftoc2Ty KJVnWftKwkpP5G9KKVCdwNPzab8smwkOaudMnaREfI7z6vNR/BXMcLPB6+nhLCBd9YcC edcg== X-Gm-Message-State: APjAAAUOeeFfuiinVPEjZ+xWVFWwkMflheb6BcTCENjr9kfCyz423C2w 6p8eVTVhBxMIVXAvU+8+9GSN5OVcoWMRzlFTcno= X-Google-Smtp-Source: APXvYqzd9LuYt89jb+ImoEtHdnhgg2VCq3BCbz1DG3rWw92TdgImv+p+OtnU+ZF6QvPT780/BIf0R7vp7+8J2Txzubs= X-Received: by 2002:ab0:5ea9:: with SMTP id y41mr15296569uag.114.1574043549863; Sun, 17 Nov 2019 18:19:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Dickson Date: Mon, 18 Nov 2019 10:18:53 +0800 Message-ID: To: Ted Lemon Cc: Ben Schwartz , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000a694910597959220" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 02:19:13 -0000 --000000000000a694910597959220 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 17, 2019 at 9:26 PM Ted Lemon wrote: > On Nov 17, 2019, at 6:40 AM, Brian Dickson > wrote: > > This the question, very briefly: *Is it too late to discuss changing the > port for DoH from 443 to a unique port number?* > > > It=E2=80=99s never too late to have a discussion, but it would be a usele= ss > discussion, unless you intend to obtain police powers; even then, you=E2= =80=99re > not really going to be able to do it in a way that gains you anything. > I take it you are skeptical of the requirement that browsers change port in order to DoH. I agree it isn't necessarily an easy task, which is why updating the standard for DoH is the right place to start. If the larger community, in particular the DNS operator community agrees this is worth doing, particularly at this early juncture, this provides a path to accomplishing the change. If the DNS operators change the port they serve DoH on, the browsers would have no choice but to change. The port must be agreed upon for the protocol to function. In particular, given that Google operate one such public DNS resolver, as well as develop one of the two browsers doing DoH experimentation, I'd say the prospects of this depend very much on Google. I don't discount either possibility; it might be possible, or it might not succeed. It doesn't mean we shouldn't explore the possibility. The main motivation is that the port number, rather than the transport protocol (HTTPS) or resolver selection, are the biggest areas of contention. Changing the protocol allows impacted network operators (enterprise, SOHO, etc.) who have reasons to implement detection and/or blocking to take action that does not require MITM or policing devices on their network. It preserves, more or less, the network posture status quo, without in any way weakening the privacy afforded generally. I.e. Changing the port number still results in encrypted transport to the resolver, if the resolver is reachable. It does not automatically prevent DoH, and in fact use of DoH or DoT within such networks is encouraged (by me at least). I'd like to see more work on the resolver identity issues and connection upgrade (bootstrapping). > This would be like going up to someone who=E2=80=99s drinking coffee and = getting > into a discussion with them about how they should switch to tea. They > might be polite, or they might throw the coffee at you (but probably not > because then they wouldn=E2=80=99t be able to drink it). They definitely= aren=E2=80=99t > going to stop drinking coffee. > I think product (coffee/tea) comparisons aren't good analogies, I think standards things like railway track gauge, or the NTSC upgrade to support HDTV, or wireless frequency stuff, are better choices. E.g. There is some good history on why subways and railroads use different standards for track gauge, at least in some cities, IIRC. A good use case example would be bridges or tunnels used for multiple vehicle types, where being able to operate switches that apply to one set of colinear tracks but not the other, would be particularly useful, something only possible with different rail gauges running literally one inside the other. Brian --000000000000a694910597959220 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 17, 2019 at 9:26 PM Ted L= emon <mellon@fugue.com> wrote= :
On Nov 17, 2019, at 6:40 AM, Brian Dickson <= brian.pe= ter.dickson@gmail.com> wrote:
This the question, very briefly:=C2=A0Is = it too late to discuss changing the port for DoH from 443 to a unique port = number?

It=E2=80=99s never too l= ate to have a discussion, but it would be a useless discussion, unless you = intend to obtain police powers; even then, you=E2=80=99re not really going = to be able to do it in a way that gains you anything. =C2=A0

I take it you are skeptical of the requiremen= t that browsers change port in order to DoH.=C2=A0

I agree it isn't necessarily an easy task, which is why updating the s= tandard for DoH is the right place to=C2=A0start.

= If the larger community, in particular the DNS operator community agrees th= is is worth doing, particularly at this early juncture, this provides a pat= h to accomplishing the change.

If the DNS operator= s change the port they serve DoH on, the browsers would have no choice but = to change. The port must be agreed upon for the protocol to function.
=

In particular, given that Google operate one such publi= c DNS resolver, as well as develop one of the two browsers doing DoH experi= mentation, I'd say the prospects of this depend very much on Google.

I don't discount either possibility; it might be= possible, or it might not succeed. It doesn't mean we shouldn't ex= plore the possibility.

The main motivation is that= the port number, rather than the transport protocol=C2=A0 (HTTPS) or resol= ver selection, are the biggest areas of contention.

Changing the protocol allows impacted network operators (enterprise, SOHO= , etc.) who have reasons to implement detection and/or blocking to take act= ion that does not require MITM or policing devices on their network.
<= div>
It preserves, more or less, the network posture status q= uo, without in any way weakening the privacy afforded generally. I.e. Chang= ing the port number still results in encrypted transport to the resolver, i= f the resolver is reachable.

It does not automatic= ally prevent DoH, and in fact use of DoH or DoT within such networks is enc= ouraged (by me at least). I'd like to see more work on the resolver ide= ntity issues and connection upgrade (bootstrapping).
= =C2=A0
This would be like going up to someone wh= o=E2=80=99s drinking coffee and getting into a discussion with them about h= ow they should switch to tea.=C2=A0 They might be polite, or they might thr= ow the coffee at you (but probably not because then they wouldn=E2=80=99t b= e able to drink it).=C2=A0 They definitely aren=E2=80=99t going to stop dri= nking coffee.

I think product (= coffee/tea) comparisons aren't good analogies, I think standards things= like railway track gauge, or the NTSC upgrade to support HDTV, or wireless= frequency stuff, are better choices.
E.g. There is some good his= tory on why subways and railroads use different standards for track gauge, = at least in some cities, IIRC.
=C2=A0A good use case example woul= d be bridges or tunnels used for multiple vehicle types, where being able t= o operate switches that apply to one set of colinear tracks but not the oth= er, would be particularly useful, something only possible with different ra= il gauges running literally one inside the other.

= Brian
--000000000000a694910597959220-- From nobody Sun Nov 17 18:25:47 2019 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 41AC712084E for ; Sun, 17 Nov 2019 18:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 58Kzlg9ihYVz for ; Sun, 17 Nov 2019 18:25:43 -0800 (PST) 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 7631C12089D for ; Sun, 17 Nov 2019 18:25:40 -0800 (PST) Received: by mail-vs1-xe2e.google.com with SMTP id c25so10456950vsp.0 for ; Sun, 17 Nov 2019 18:25:40 -0800 (PST) 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=7+E7rsb/94qGGrbCH+VCLbLG7ANCjZKvVnii+g2dlsc=; b=hXKVCGNA5BcZ57cYL8DUGhMigwLFbFBDo5eObeClfa5KOIknJEjJR7T/I2bh9YWskr bcZOaubC4eVUrhyR/pAuGgMY8q20bNnglNjuBY2c8CjTUbuc9a7nXaJXaZ9V1O360cvf +sfslx/6NRXJGU59uEv9sXaMmo3cB21K+acPmyYbQK/+zUjWmN5ZJQeziKu3jgmEtFYe ed+PCk7XdWAKv+QC8j4tREPyD7x3U7IFjFsZmz9d6+8EZC3MhvBZ6vWefymaG3j5yK9N dIYmbLvGqgRhtbOC1QqCkzZn8bcrXGcziICyHzdEpPiYcs824H0dbXSEDU7ZBEOo8o5V hSdw== 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=7+E7rsb/94qGGrbCH+VCLbLG7ANCjZKvVnii+g2dlsc=; b=pbuZaCnbZrugJZDgiwkfaDOSTyea/yihQno73R0YmC0ZxO045eHMylRq32Y4307a0x Cu36UNew5PDyrLqmWePMgL2Ylg0c9Qs1ORMhU6vZ8+vlLuVzYVsh8qPYX8zJIlq0rbC1 y8vhJv0WOGGLAz8V8Ouvjbzqr1eOHBTACmGErbG6EitoMxvGT/w9KGvVcva4rkbSjTzJ NcffWmjO1vwtLbOVNXQ/AKu16EBjbOowrnPy7eeiqmTUEmm0QD4T5GU6vB9wl1F+bN3r VbYmpR7G/lpwHWfS7DCGWCrtxTPi5rP10kETplOG9blqLHGWnPm6NbLShmLmTe4Bzm23 CYIQ== X-Gm-Message-State: APjAAAUa2DHk3HIqp/yir8XQcPu0uU9hQLvPsCpMBuaVXPSk1xfVu6us nLvnlXYNxyTHpvOBeTQmzHnA1akAgZYd5VmEuGPfd9dl X-Google-Smtp-Source: APXvYqzvQXsVnRnG7dhWk6GZtq+jFrN3sKKYEDfrPTQhqfmm/PKCuAukefpmyPm5AzaHn7aXzcPTiHDHdtGd/1jOXfw= X-Received: by 2002:a67:ef90:: with SMTP id r16mr16360513vsp.199.1574043939554; Sun, 17 Nov 2019 18:25:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Dickson Date: Mon, 18 Nov 2019 10:25:23 +0800 Message-ID: To: Patrick McManus Cc: Ben Schwartz , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000e0cead059795a9d8" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 02:25:45 -0000 --000000000000e0cead059795a9d8 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 17, 2019 at 11:02 PM Patrick McManus wrote: > > unregistered is rogue now? > > No, but rogue is unregistered. There is no "evil" bit, so the detection of rogue starts with detecting unregistered, and digging deeper as necessary. We're in favor of lots and lots of resolvers, rather than an effective forcing function via TRR lists, to centralized resolvers. A unique port number for DoH actually encourages this rather than discourages this. A new set of traffic that is explicitly DoH (based on port number) would be more likely to malware-detection-friendly than overloading HTTPS. (It involves less initial investigation, as it already self-identifies as DoH. A cursory examination of the DoH service being contacted should be enough to identify "regular" DoH server functionality from "irregular" DoH functionality.) Brian --000000000000e0cead059795a9d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 17, 2019 at 11:02 PM Patr= ick McManus <mcmanus@ducksong.co= m> wrote:

unregister= ed is rogue now?
=C2=A0

No, but rogue is unregistered.=C2=A0

Ther= e is no "evil" bit, so the detection of rogue starts with detecti= ng unregistered, and digging deeper as necessary.=C2=A0

We're in favor of lots and lots of resolvers, rather than an effe= ctive forcing function via TRR lists, to centralized resolvers.
<= br>
A unique port number for DoH actually encourages this rather = than discourages this.

A new set of traffic that i= s explicitly DoH (based on port number) would be more likely to malware-det= ection-friendly than overloading HTTPS.
(It involves less initial= investigation, as it already self-identifies as DoH. A cursory examination= of the DoH service being contacted should be enough to identify "regu= lar" DoH server functionality from "irregular" DoH functiona= lity.)

Brian
--000000000000e0cead059795a9d8-- From nobody Sun Nov 17 18:30:57 2019 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 5FE62120048 for ; Sun, 17 Nov 2019 18:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrqEPbr6Dkkt for ; Sun, 17 Nov 2019 18:30:53 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 BF7B51207FD for ; Sun, 17 Nov 2019 18:30:53 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id u18so9673943vsg.5 for ; Sun, 17 Nov 2019 18:30:53 -0800 (PST) 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=BxwDlkxEbgB+df/mBnKuKkvxPqiQN+fcdBLGSkDjjds=; b=jZjxbuAYrd1llLUN1VTdxeLBIimLk48wa+ylV8hkCvuVS7U1z3cSpWZL+c/S+zBCxW /SC7TUbdTs4hOL8bYm36eg1cXHympOkbS97zp/Ffc48Vs+rW5ZWg49t/OFr+flld/Rp7 LhmzwUbNXE5g30HIc3BCSQUEnHIExA0NkIqwMAHWwqUqrhptsh6oLplheZ4H1YWjH/RK 1vpb8JiZfgtE0KDjJsLJxY8/CL7J8hECTSvYfHHGqFYUoVAyfrUVRK0akw96K3zswPht 8ioDYDBobYxWni+rQZ6NBsQ30RXZBCqHMZsRZ+rAklLtnYQGws+izx9dVKC3a6gYfA3x +Bng== 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=BxwDlkxEbgB+df/mBnKuKkvxPqiQN+fcdBLGSkDjjds=; b=Sum++/WD8IZoslbOek+zUcnW7rg3H8/JicfzkPKZRdji5bZRCasmlXoOIQ2xd7o1b2 k+FYLKl2ojqhWYYZY0+gnJLJCvSYJ43Vh365GS/N8YhStxgFngYy4nRP+kvXW5Zq2o8L 3aN9UTlvoOdFHUbFInTpDZR/8tM9MkUvzWx10gDB2K413+9MKpHa806O1O64I9MoCodb 203uu4MqMtL76/L6usZR1P6h/e3Ez4EB722yOVae+ymrkj6rlQZR9lRkBkZSU5pKiXNq VMXnRbseVgZ0lIJC9yp3X1sCF3xIyRjiaIkqEiIJBmCOOHFIMRh7D7dABX9A+wm9ybgD LrYg== X-Gm-Message-State: APjAAAVDXhEv5H21Hacw+4rYXkRw5uCMpbNhdr4DCselHtnRqCoHvtRs KF7E29SoBUSPbK7PdlPibYJR9DslrPPX9lQPVyU98IYl X-Google-Smtp-Source: APXvYqwWHeAkZoLCWfOMNKadyCOV3ylYvQhdUnC2dCwli81N96nCxmMLA9ASaDYuPYnPQHZnTUmW6zVtIXw4FNto/iY= X-Received: by 2002:a67:f744:: with SMTP id w4mr5871072vso.219.1574044252831; Sun, 17 Nov 2019 18:30:52 -0800 (PST) MIME-Version: 1.0 References: <680390BE-E819-4951-98EE-C77E9C60E495@piuha.net> <20191117205813.8240D1965255@fafnir.remote.dragon.net> In-Reply-To: <20191117205813.8240D1965255@fafnir.remote.dragon.net> From: Brian Dickson Date: Mon, 18 Nov 2019 10:30:36 +0800 Message-ID: To: Paul Ebersman Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000008d03a6059795bc84" Archived-At: Subject: Re: [Add] Draft on the use of multiple recursive 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, 18 Nov 2019 02:30:55 -0000 --0000000000008d03a6059795bc84 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 18, 2019 at 4:58 AM Paul Ebersman wrote: > bdickson> I believe there would be more value to support explicit > bdickson> ordering as well as randomization within a given set at the > bdickson> same level of preference. > > That ship sailed years ago. Round robin as load balancing (or any use of > expected order of RRs in an RRSet) is never going to be reliable. If you > have some need for it, do it in the code doing the DNS queury or you > will be surprised. > > This is from painful years of tech support of BIND explaining why this > wasn't doing what someone wanted. There are too many stub and recursive > resolvers out there we can't change that won't "behave". > > What use case do you think this solves? > I was responding in the context of the draft by Jari, which supposed privacy improvement by this sort of round robin from clients to resolvers. In retrospect, I think you're right, it makes much more sense to stick to a single resolver. That said, my suggestion is probably moderately useful for the more explicit selection of such a single resolver, as well as providing an "electric fence" to optionally protect against downgrade from private to non-private. Brian --0000000000008d03a6059795bc84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 18, 2019 at 4:58 AM Paul = Ebersman <list-add@dragon.net= > wrote:
bdic= kson> I believe there would be more value to support explicit
bdickson> ordering as well as randomization within a given set at the bdickson> same level of preference.

That ship sailed years ago. Round robin as load balancing (or any use of expected order of RRs in an RRSet) is never going to be reliable. If you have some need for it, do it in the code doing the DNS queury or you
will be surprised.

This is from painful years of tech support of BIND explaining why this
wasn't doing what someone wanted. There are too many stub and recursive=
resolvers out there we can't change that won't "behave".<= br>
What use case do you think this solves?

I was responding in the context of the draft by Jari, which supposed priva= cy improvement by this sort of round robin from clients to resolvers.
=

In retrospect, I think you're right, it makes much = more sense to stick to a single resolver.

That sai= d, my suggestion is probably moderately useful for the more explicit select= ion of such a single resolver, as well as providing an "electric fence= " to optionally protect against downgrade from private to non-private.=

Brian=C2=A0
--0000000000008d03a6059795bc84-- From nobody Sun Nov 17 18:32:10 2019 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 22B50120841 for ; Sun, 17 Nov 2019 18:32:09 -0800 (PST) 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 Wh6KnN5FBiBS for ; Sun, 17 Nov 2019 18:32:07 -0800 (PST) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 4D4FC120251 for ; Sun, 17 Nov 2019 18:32:07 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id 5EFAB5F40B13; Mon, 18 Nov 2019 03:32:06 +0100 (CET) Received: from [172.19.217.14] (dhcp-8ca6.meeting.ietf.org [31.133.140.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 78BD45F4037A; Mon, 18 Nov 2019 03:32:04 +0100 (CET) From: "Ralf Weber" To: "Patrick McManus" Cc: "Vittorio Bertola" , "ADD Mailing list" Date: Mon, 18 Nov 2019 10:32:01 +0800 X-Mailer: MailMate (1.13r5655) Message-ID: <495649EB-4E75-4E0A-A766-2C13D05D2D16@fl1ger.de> In-Reply-To: References: <299277505.7138.1574037347987@appsuite-gw2.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 02:32:09 -0000 Moin! On 18 Nov 2019, at 9:38, Patrick McManus wrote: > On Mon, Nov 18, 2019 at 8:35 AM Vittorio Bertola < > vittorio.bertola@open-xchange.com> wrote: >> >> (Of course non-well-behaved providers will always do whatever >> possible to >> camouflage their traffic, [..] >> >> > Seeking confidential 2 party communication with HTTPS is not > non-well-behaved - it is exactly what HTTPS seeks to do. I think that is not question here that Vittorio and Brian wanted to raise. We all agree that https or TLS in general allows confidential 2 party communication. The question is more who are these endpoints and I think it is in scope of ABCD, and I still hope that we will be successful in doing this, to define client and server behaviour or deployment advices for DoH servers and clients. So long -Ralf —-- Ralf Weber From nobody Sun Nov 17 18:49:52 2019 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 63848120841 for ; Sun, 17 Nov 2019 18:49:50 -0800 (PST) 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 8KAF81gVd59J for ; Sun, 17 Nov 2019 18:49:48 -0800 (PST) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCED0120013 for ; Sun, 17 Nov 2019 18:49:48 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 99649916E9; Sun, 17 Nov 2019 21:49:47 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24018.1739.610788.280101@gro.dd.org> Date: Sun, 17 Nov 2019 21:49:47 -0500 From: Dave Lawrence To: add@ietf.org In-Reply-To: <2105867190.7141.1574038197898@appsuite-gw2.open-xchange.com> References: <6.2.5.6.2.20191116232455.10209e78@elandnews.com> <2105867190.7141.1574038197898@appsuite-gw2.open-xchange.com> Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 02:49:50 -0000 Vittorio Bertola writes: > I still find it weird that people at the IETF challenge jurisdiction > and national sovereignty so directly. You were careful with your words and I appreciate that. To make it extra explicit for everyone, please bear in mind that "people at the IETF" is not equivalent to "the IETF", as should be painfully evident by the ongoing debates on this list and in other IETF venues. Even despite the reference earlier in this thread to one AD's remarks, it is still one opinion among many. From nobody Sun Nov 17 18:52:19 2019 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 ED6DB12081B for ; Sun, 17 Nov 2019 18:52:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xR9mHWeRz343 for ; Sun, 17 Nov 2019 18:52:15 -0800 (PST) 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 840FE120846 for ; Sun, 17 Nov 2019 18:52:13 -0800 (PST) Received: by mail-io1-xd33.google.com with SMTP id 1so17023283iou.4 for ; Sun, 17 Nov 2019 18:52:13 -0800 (PST) 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=mDAJr4zKErvZWB9xeAxweisgll8JzJQ6UypRHCMKPtc=; b=vWphQNf1ZuGKAMSDej5OA2uvJRrsGEzg1d1C7xHCf81ourXggsL0APNwG5o/zsW+rs rH7J94OgctaOkAEfrpO9UFYLDcqy57xv1JQXKC9udy3r1KcyWzi8S1QPfSOKnTSWF7fP zeBma4P7olqDZ18allBf4ja/6XSU4+Ndiy8hhcH1AGJaGEHTXtev32JW7GnjJJXUM2dV XkyLlsP0CXVqcWO3bnvW5og8XKZyQL2zc9rysWj3N+81dN8W+p+ge3ace0qI+gH58W0X hQlKdT07MRw/QRF62yV3beFgabpEzTtEP7st+awjaH+svhCffSjAfy9dQ8fnV6TFj8Cd 0h9Q== 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=mDAJr4zKErvZWB9xeAxweisgll8JzJQ6UypRHCMKPtc=; b=tmItZz9KcMiKJl191ouLcJDB9xnIF8E4a+pVVxEgAt6/mux8IcpuftUswyIy7bfxdm AQJQjgoA/AUkJqO7vh77J2201DxNeDmtDh2WNrZl8Lt1iZWS0V+Rvz1DGytllmmImUPs 7YAjpa39xWesizf7o20HJDnDtz38h2Ccw3wf0lVj2Hf/ng1Wl9tilfvbTXoM2Sg/f6wI 2IvxWcIuHyTz1BdT9uqRPUardI++vqZByQqjULagc3aKJ5Hd2l3V5CYL8SYaV2g/6DIJ H+WYrbFRrI+78uv2nMQEGvTKcPMnycfvCoLjLV/Cq9rBaXd9PJ1/TV0+Ni7atWiu/bvS cUUA== X-Gm-Message-State: APjAAAU7G6Wnp7aG21wDBvn9KuzuKeMpRb5Ia2m1zVIEGj5pkphT6l28 3xonst1fUN7yd/UHa92e+KRcFYQdSMb/cjHZ9vnPqCAZ X-Google-Smtp-Source: APXvYqw/5b+yuENAYHyM9Pl9wWWbUZPBHgBPyOYsuminIN1y8wUF5zCi6kcawVBh6jAF55vNEC+FLx81Y/oTg7yh6I4= X-Received: by 2002:a5d:860e:: with SMTP id f14mr202052iol.290.1574045532653; Sun, 17 Nov 2019 18:52:12 -0800 (PST) MIME-Version: 1.0 References: <680390BE-E819-4951-98EE-C77E9C60E495@piuha.net> <20191117205813.8240D1965255@fafnir.remote.dragon.net> In-Reply-To: From: Ted Hardie Date: Mon, 18 Nov 2019 10:51:45 +0800 Message-ID: To: Brian Dickson Cc: Paul Ebersman , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000d58c390597960869" Archived-At: Subject: Re: [Add] Draft on the use of multiple recursive 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, 18 Nov 2019 02:52:17 -0000 --000000000000d58c390597960869 Content-Type: text/plain; charset="UTF-8" Hi Brian On Mon, Nov 18, 2019 at 10:31 AM Brian Dickson < brian.peter.dickson@gmail.com> wrote: > > I was responding in the context of the draft by Jari, which supposed > privacy improvement by this sort of round robin from clients to resolvers. > > In the author discussion, we were each convinced that a basic round-robin of queries to a set of resolvers ended up leaking the most of any of the strategies, because there were many conditions (common web pages or apps) in which all of the resolvers ended up with enough information to identify which web pages/resources the client was attempting to access. My apologies that this didn't get communicated in the draft well; we'll try to make it clearer in later versions. regards, Ted --000000000000d58c390597960869 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Brian

On Mon, Nov 18, 2019 at 10:31= AM Brian Dickson <bria= n.peter.dickson@gmail.com> wrote:

I was responding in the context of the draft by Jari, which supposed pri= vacy improvement by this sort of round robin from clients to resolvers.


In the author= discussion, we were each convinced that a basic round-robin of queries to = a set of resolvers ended up leaking the most of any of the strategies, beca= use there were many conditions (common web pages or apps) in which all of t= he resolvers ended up with enough information to identify which web pages/r= esources the client was attempting to access.=C2=A0

My apologies that this didn't get communicated in the draft well= ; we'll try to make it clearer in later versions.

<= div>regards,

Ted

=C2= =A0
--000000000000d58c390597960869-- From nobody Sun Nov 17 18:57:18 2019 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 198A3120841 for ; Sun, 17 Nov 2019 18:57:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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=lfldaOim; dkim=pass (2048-bit key) header.d=comcast.com header.b=twMP8vJS; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=MTe2+AgZ 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 BQLTTwqn2Uge for ; Sun, 17 Nov 2019 18:57:12 -0800 (PST) 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 6129D120013 for ; Sun, 17 Nov 2019 18:57:12 -0800 (PST) Received: from pps.filterd (m0184893.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAI2uDQD008060 for ; Sun, 17 Nov 2019 21:57:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=g2kRIa4fH/eu/H5AHnGkd9QK8qZLQC4BA1jBI+ViE5Q=; b=lfldaOim7I6KpwwftTRMSM7TPeP7sAd32XzN+in6PSU1FwD2Wi7+RNKpTtsE1IXMsgYC a5Ni6m8LuN2trKRpZ8HK83HqIObM50yTK25dyJkg3uy/CXbHa6OSf1E/2WZ80/Wsofd9 dZeSOkg6lAFz7+KEx1XWXwm3nnMWdUbZgZKmoGI9jSfrYkiPRbQ1aF6Ga8wvoC7B/gkg jGdYy7c6gtux6TlGd8gcyZQ84fnZzPW7HRuoMEibEA4Gn2jSbcW1wxEsaDpPcyO9Dlje Pd9W/Hr7xtz5KzCagsjdh567P7bfVkW/+SBAej9viDWDvshRLN9IcQn2rJlNAsjKzmbu nw== Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) by mx0a-00143702.pphosted.com with ESMTP id 2wad5k1gwq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 17 Nov 2019 21:57:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1574045830; x=2437959430; 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=g2kRIa4fH/eu/H5AHnGkd9QK8qZLQC4BA1jBI+ViE5Q=; b=twMP8vJSnrBjl8iz4uSaZBUN0/6tLu+FRuv6X3ZUDAn7QcpqQv7r8RI3mTvB+CDI sTE9JlKpKq9snNjUAzuX3rv1LqybdNd4dZ8F0hcGI5FcWhaLHAkEsVqjO14LuXGk T47cJa2jT6tOUt9Ta8bgJbjfRtO+P5hICaWP2on4t1jiJAdOM9ViYRCm7phrD2RF ZZuHY5/6NbunEY9GZnxpY39ipqlaPBbsHQAw2xL2GPV2dR41QlxBZQwHNoDNndGr mMeiYCY70KmRL7k+SYWtB56dB/MSJnjUVU0sDvbhMFxoKdEnKwq6Iv3KqA0zDWab rJ1FIpDs9VINKIAeet+o6w==; X-AuditID: 60721c4c-a33ff70000003748-44-5dd208855e70 Received: from PACDCEX10.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id A0.60.14152.68802DD5; Sun, 17 Nov 2019 21:57:10 -0500 (EST) Received: from PACDCEX23.cable.comcast.com (24.40.1.146) by PACDCEX10.cable.comcast.com (24.40.1.133) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 17 Nov 2019 21:57:08 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX23.cable.comcast.com (24.40.1.146) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 17 Nov 2019 21:57:08 -0500 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (104.47.32.57) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 17 Nov 2019 21:57:08 -0500 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB4119.namprd11.prod.outlook.com (10.255.163.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.25; Mon, 18 Nov 2019 02:57:07 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 02:57:07 +0000 From: "Livingood, Jason" To: ADD Mailing list Thread-Topic: [Add] Agenda and Revised Charter for the ABCD BoF Thread-Index: AQHVnDttw5Xi8KlSJ0qQiU8WuHP22aeP47wA Date: Mon, 18 Nov 2019 02:57:07 +0000 Message-ID: References: <254AEFB0-F930-466B-8BB6-707D5CE72657@fl1ger.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-originating-ip: [2001:67c:1232:144:fcaa:fd79:9cb8:c6a7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8eb9143a-0386-4177-191b-08d76bd2ffc7 x-ms-traffictypediagnostic: BY5PR11MB4119: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(39860400002)(376002)(366004)(136003)(396003)(199004)(189003)(5660300002)(66946007)(66446008)(66476007)(33656002)(76176011)(6916009)(64756008)(66556008)(53546011)(102836004)(81166006)(81156014)(66574012)(186003)(6506007)(8936002)(14444005)(256004)(99286004)(76116006)(91956017)(86362001)(7736002)(8676002)(71190400001)(71200400001)(11346002)(446003)(2616005)(606006)(6486002)(316002)(46003)(58126008)(25786009)(6436002)(478600001)(6512007)(14454004)(790700001)(6116002)(236005)(54896002)(6306002)(6246003)(966005)(2906002)(80792005)(476003)(486006)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB4119; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: aPMeN8FZBBr/ViUgPCGQyxfKe4yngVembke/F9H4S7QJrMT14e769uvyBYGG0LW4lzO9vjCtMevScp8E/EPkLE3FBMtRvAtYDGfnmmlo2z28IDlVGkfUf+xPVOmn+JeY6AyekF42OYeSAPbET5lh3DLu++PqV4G76lavTy6wC7SSy6X5t++DYeMkETIpDS4UW+7HmPmaQVqmCcAmtSbZSKJ8im2lHQFjc/1tIKHAzxJ4VGCGNR8+IeKjWa0btzurwOiw9q94G7Z9Fu8VSDEksIRSqWE8SWjf3umQ4F0gIgKq4O5B8qwBPaSeqeIG0nW4YzAGFy3bxjr8nVle5VysfiLuusqEWf4MHqi2Bzlqp6C0Rs+QWwzRMZiwn4I5g8r3ogevaMnf7HXkvwPWgGa44LbYbyzVppvqzEhC6zf5V3RdbxCH3ENNlXL5rAU+TfKK x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Shpek6OXMdta5New3lp7w8HhJo4t2SkTa1cf7a7sX8BG+qziJy/CXMWzLCh0iXqwYsVOj23jnA5ujux0hB2a3l9c4DTMCTnZO4sC37E1o4zUAdMNRrNEnfeB72ax6W48cU7b1Tui1JAJVBvzA1R73oN/4+IPU7Acx3FDwH/2ZKuYqMAVT5qKYCLFB9ICjl50SV8JNmSbB3eVmjxRtwaQiRMV80jWHz3PyhyAaoSNBL12FXRcccPt9m8fRTonohb6X0eEpCcTQ3QHAGkB7N7WJ2HONVSnaPWruPHUdUHHV8HIqf01OJ9A776QBemy9kfZ3Z3tDe37ujhTutiA7JuxfQ== 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=HBmVwMPqvKvbx9UbkISHainaJSdgZDSXURDMsI4Bsps=; b=CsE2CfDkpMkn8vO4myuXy5533B39kNUAb36++CeZDuxeS+vsAOFOxpEcL7HDFTD4v6ItcNh6elZqyBvxaGiiidjZTW4HD/iQ/OFRbYKfVzs4oQIsLHzrjmfEJg6F92X6yBrFOI3XvL4QOaLCzHmhfIXhyCLd4C+0wMNz6IbdQ/SwJpr3Ezn4jJ5cktU66EMdff3kbYjLA2SDKhYhRl6shrcXuinBfUYlOGa/i4/f+C/PafuFiAvN47UCsW6kxwTQEt5pwL3qjXrrus7z3ZM4gX5R9ru6CwPZscJGtQGgoiTe+DS2VJzmfSo+BgYBN1+ZTK3BOuhf82WvGaaq28IdMQ== 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=HBmVwMPqvKvbx9UbkISHainaJSdgZDSXURDMsI4Bsps=; b=MTe2+AgZ+Yg8FOJ00EnE5q+mXdQxxY57a4ZOpOfbxEiYvY1Rm4BP8/h9JYMrH/tQDauY/zZztySfCTEY655S5gg89ZgtSkkDwPiqvgHO66up6ETxa2FphcIaxK22183ID1gITSks2SmO1e1c1O8elyD0wXHGGHKMetJ8g9DOc6g= x-ms-exchange-crosstenant-network-message-id: 8eb9143a-0386-4177-191b-08d76bd2ffc7 x-ms-exchange-crosstenant-originalarrivaltime: 18 Nov 2019 02:57:07.2268 (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: dNQ4giYzOw7lo4yhDDCay0N6hVXFBt4KYM8u6VH5HeJQmnWtPEDcxHW6u9f5hrpYy0mXfQLTEy9jC1m3myA2hf/mOEV9DA2GxVKhI2jEMf4= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4119 x-originatororg: cable.comcast.com Content-Type: multipart/alternative; boundary="_000_A5F1D3AD73D7449199A83CCA02F49EF4cablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA22Sf0yMcRzHfZ/nueu5OPt2yn3kmM4sQlctucxilsnIwvijLTz0Telc9ty5 ic3KyjhMlB8VXfrB3PXDFJG2VhNTcv1kIinNz9IP0rRVeu7JZtP3r9fn/Xl/3vvssy9LKy5J 3dkYvZHwek6nljozewwbtctPsk0RPmPpM7XjdUXStSgkL+83FYbCE9BqYzRPOGMwiSJ6Awly XvDfW72XRMXxZD3H6+K3ER3hprYJzkiiizERXjNljGbKnD0tVPSTp7X0oZeD1JHKF4V0Ahr/ TJkRywL2B8vpDWbkzCpwFQXv7EOUWJQjaK6yOZmRbKJoRfDEFis2ahCk36xHYpFKQVFlz+RI F4LO3gKJMCLFAdB+o4UW2BUvhPz2MkrgWTgI+q5+kor6GvjwrdCxhyv2g6LncwSZwYug7Y1V IshyHAyJF7Vi/AUKbp+/54iR4a3w0VbGCIzwbBiuLXDoNFZCW7fFwYAx5FXYaZHd4MuHMUem G9ZA1WioOBoJueacSXsg5I42IpHnQZPlDBIvFAr13+JF2QvSvpoZkWOhv/jeZLonJA1kSURW QU5Zg5OwMuARCbxKyZQKOQp8AHpbg0TPfLCe62RSkF/GP0tnTLhovB+aS0IEWY5d4Fl6NyPK S6C4XCO6PSDtTKeTyIsh+dr1SQ6B+j4b9a8nG7FWNCMwwNvX19/bT+u9MuAuEj4rr9r8AA1e DqlGmEXqGfL1HY0RCglnMsQfrEbA0mpX+ZauhgiFPJKLP0r4uN38YR0xVKO5LKNWyqcVZkco 8H7OSGIJOUT4v12KlbknoLoetx2vU35pv/cGn1iiutDnk+xTSycqSzd1H3e94xuYvNf4fmf2 dP3wUMXMZ2Wx9l3rTrU+0g9s32ftv5//c9XSh5/HaxQmz7PHZMoknbIEZS2DtyYPl/BKS8aV kegVTU/La8Iyh7pMcXHPjbM6erTSZP+Exz9U6bdSSzm7ZixngZoxRHO+XjRv4P4AQbxZrKgD AAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-17_05:2019-11-15,2019-11-17 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 02:57:17 -0000 --_000_A5F1D3AD73D7449199A83CCA02F49EF4cablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWZ0ZXIgcmVmbGVjdGluZyBvbiB0aGUgbGlzdCBkaXNjdXNzaW9uLCBJIGFncmVlIHRoZXJlIGFy ZSBhc3BlY3RzIG9mIHRoZSBwcm9wb3NlZCBjaGFydGVyIG9uIHdoaWNoIGl0IHdpbGwgYmUgZGlm ZmljdWx0IHRvIGFjaGlldmUgY29uc2Vuc3VzIChMT0wpLiBTbyBtYXliZSBsZXTigJlzIGp1c3Qg c2V0IGFzaWRlIHRoZSBzdHVmZiB3aGVyZSB3ZSBhbGwga25vdyB0aGF0IGlzIHRoZSBjYXNlIGFu ZCB0cnkgdG8gZm9jdXMgbW9yZSBuYXJyb3dseSBvbiB0aG9zZSBhcmVhcyB3aGVyZSBnZXR0aW5n IGEgZmV3IHRoaW5ncyBkb25lIG1pZ2h0IGJlIHBvc3NpYmxlLiBTbyBmb3IgZXhhbXBsZSDigJMg aGVyZSBhcmUgc29tZSBvZmYtdGhlLWN1ZmYgdGhvdWdodHMgd2hpY2ggbWF5IG9yIG1heSBub3Qg YmUgd2VsbCBjb25zaWRlcmVkIG9uIG15IHBhcnQuIDstKSAod2l0aCBhcG9sb2dpZXMgdG8gcGVv cGxlIHRoYXQgdmlldyB0aGlzIGluIHBsYWludGV4dCBtb2RlIHZzLiBIVE1MIC0gc2luY2UgSSBo YXZlIGFkZGVkIHN0cmlrZXRocm91Z2ggYW5kIGNvbG9yZWQgdGV4dCBtYXJrdXAg4oCTIGJsdWUg dGV4dCBpcyBuZXcpOg0KDQpUaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb25zaWRlciB0ZWNobmlj YWwgZHJhZnRzIG9uIEROUyBjbGllbnQNCmNvbmZpZ3VyYXRpb24sIGVzcGVjaWFsbHkgd2l0aCBh IGZvY3VzIG9uIHRoZSBmb2xsb3dpbmcgaXRlbXMgd2hlcmUNCnRlY2huaWNhbCBjb25zZW5zdXMg c2VlbXMgb2J0YWluYWJsZToNCg0KLSBDb21tdW5pY2F0aW5nIGNvbmZpZ3VyYXRpb24gYmV0d2Vl biB0aGUgbmV0d29yaywgb3BlcmF0aW5nIHN5c3RlbSwgYW5kDQpBcHBsaWNhdGlvbnMgSG93IHJl c29sdmVycyBjYW4gc2lnbmFsIHRoZWlyIGNvbmZpZ3VyYXRpb24gYW5kL29yIHByYWN0aWNlcyB0 byBvcGVyYXRpbmcgc3lzdGVtcyBhbmQgYXBwbGljYXRpb25zIChhbmQgdXNlcnM/KSwgdG8gc3Vw cG9ydCBkZWNpc2lvbi1tYWtpbmcgb3Igc2VsZWN0aW9uIGJlaGF2aW9ycyBieSB0aG9zZSBwYXJ0 aWVzLg0KDQotIEF1dG9tYXRlZCBkaXNjb3ZlcnkgJiBzZWxlY3Rpb24gRGlzY292ZXJ5IG9mIHJl c29sdmVycywgd2l0aCBzZWxlY3Rpb24gcG90ZW50aWFsbHkgbWFkZSBiYXNlZCBvbiBkZXRlY3Rl ZCByZXNvbHZlciBhbmQgdGhlaXIgY2FwYWJpbGl0aWVzIGFuZCBiZWhhdmlvcnMgKGJhc2VkIG9u IE9TLCBhcHAgYW5kL29yIHVzZXIgcHJlZmVyZW5jZXMpDQoNCi0gUXVlcnkgcm91dGluZyBpbiBh IG11bHRpLXJlc29sdmVyIGVudmlyb25tZW50DQoNCi0gTXVsdGlwbGUgbm9uLWVxdWl2YWxlbnQg cXVlcnkgcGF0aHMsIHN1Y2ggYXMgc3BsaXQtaG9yaXpvbiBETlMgb3INCmdlby1zZW5zaXRpdmUg YW5zd2Vycw0KDQotIERldGVybWluYXRpb24gLyBkZXRlY3Rpb24gb2Ygc3BsaXQtaG9yaXpvbiBE TlMgZW52aXJvbm1lbnRzIGFuZCBzdGFuZGFyZGl6ZWQgdXNlcyBvZiDigJhjYW5hcnkgZG9tYWlu c+KAmSBvciBvdGhlciBtZXRob2RzIHRvIGVuYWJsZSBkZXRlY3Rpb24gb2Ygc3VjaCBlbnZpcm9u bWVudHMNCg0KLSBQb3RlbnRpYWwgdXNlIG9mIGFsdGVybmF0aXZlIGFwcGxpY2F0aW9uIHBvcnQg bnVtYmVycyBpbiBzb21lIGNvbnRyb2xsZWQgZW52aXJvbm1lbnRzIChlLmcuIG1hbmFnZWQgZW50 ZXJwcmlzZSBlbnZpcm9ubWVudHMpLCBpbmNsdWRpbmcgdGhlIHByb3MvY29ucyBhbmQgaW1wbGlj YXRpb25zIG9mIHNlY3VyaXR5IGRvd25ncmFkZSBhbmQvb3IgZGV0ZWN0YWJpbGl0eSBpbiB0aGVz ZSBlbnZpcm9ubWVudHMNCg0KLSBMb2NhbCBETlMgY2FjaGVzIChlLmcuIHBhcnRpdGlvbmluZywg dXNlIG9mIHN0YWxlIHJlY29yZHMpDQoNCi0gUmVzaWxpZW5jZSBhbmQgZmF1bHQtdG9sZXJhbmNl IChlLmcuIHNpbmdsZSBwb2ludHMgb2YgZmFpbHVyZSBtb2RlcyBmcm9tIGVuY3J5cHRlZCBETlMg dG8gRG81MyBvciBmcm9tIGEgcHJpbWFyeSBlbmNyeXB0ZWQgRE5TIHJlc29sdmVycyB0byBzZWNv bmRhcnkgb3IgdGVydGlhcnkgcmVzb2x2ZXJzIOKAkyBvciBzb21ldGhpbmcgbGlrZSB0aGF0KQ0K DQotIFN1cHBvcnQgU3RhbmRhcmRzIC8gYXBwcm9hY2hlcyBmb3IgZGVidWdnaW5nIGFuZCBhbmFs eXNpcyAoZS5nLiB0byBzdXBwb3J0IGRldmVsb3BtZW50IG9mIE9TIGFuZCBhcHBsaWNhdGlvbi1s YXllciBkaWFnbm9zdGljIHRyb3VibGVzaG9vdGluZyB0b29scywgYSBsYSBkaWcsIHdoZXRoZXIg c29mdHdhcmUtZHJpdmVuIG9yIHVzZXItcHJvbXB0ZWQpDQoNCi0gRE5TIFB1c2ggKGFjY2VwdGlu ZyByZXNwb25zZXMgdG8gcXVlcmllcyB0aGF0IGhhdmUgbm90IHlldCBiZWVuIGlzc3VlZCkgW0pM IGNvbW1lbnQ6IG5vdCBzdXJlIHdoeSB0aGlzIHdvdWxkIG5vdCBiZSBhIGNsaWVudC1kcml2ZW4g YWN0aXZpdHksIHN1Y2ggYXMgbG9va2luZyBhdCBhbGwgcG9zc2libGUgRlFETnMgb24gYSBzaXRl IHRoYXQgYSB1c2VyIGlzIGxpa2VseSB0byBhc2sgZm9yIGFuZCBzZW5kaW5nIGFsbCB0aG9zZSBx dWVyaWVzIGZyb20gdGhlIGNsaWVudCB3aGVuIHRoZSBhcHAvc2l0ZSBmaXJzdCBvcGVucywgYmFz ZWQgb24gcHJpb3IgdXNlciBiZWhhdmlvciBvciBsaWtlbHkgcGF0aHdheXMgdGhyb3VnaCBhbiBh cHAvc2l0ZV0NCg0KLSBPc3NpZmljYXRpb24gYW5kIGV2b2x2YWJpbGl0eQ0KDQpUaGUgZm9sbG93 aW5nIHRvcGljcyBhcmUgYWxzbyByZWxldmFudCwgYnV0IHJlcHJlc2VudCBhcmVhcyB0aGF0IGFy ZQ0Kc2lnbmlmaWNhbnRseSBtb3JlIGNoYWxsZW5naW5nIGZvciBjb25zZW5zdXMtYnVpbGRpbmc6 DQoNCi0gRW5kLXVzZXIgcHJpdmFjeSBhbmQgcGVydmFzaXZlIHN1cnZlaWxsYW5jZQ0KLSBEZXRl Y3Rpb24gYW5kIHN1cHByZXNzaW9uIG9mIG1hbHdhcmUNCi0gVXNlIG9mIHJlY29yZHMgZnJvbSB1 bnRydXN0ZWQgc291cmNlcw0KLSBQb2xpY3kgZW5mb3JjZW1lbnQgYW5kIGNvbnRyb2wgb2YgdGhl IHN0dWIgcmVzb2x2ZXIgY29uZmlndXJhdGlvbg0KLSBVc2UgYW5kIGltcGFjdHMgb2YgbGFyZ2Ug cmVjdXJzaXZlIHJlc29sdXRpb24gc2VydmljZXMNCg0KVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBu b3QgYXR0ZW1wdCB0byByZXNvbHZlIGRpc2FncmVlbWVudHMgb24gdGhlc2UgdG9waWNzLA0KYW5k IHdpbGwgcmVxdWlyZSBmdWxsIGNvbnNlbnN1cyBvbiBhbnkgc3RhdGVtZW50cyByZWdhcmRpbmcg dGhlc2UgYXJlYXMuDQoNClRoaXMgd29ya2luZyBncm91cCB3aWxsIGNvb3JkaW5hdGUgd2l0aCBk bnNvcCAoT1BTIEFyZWEpLCBjYXBwb3J0IChBUlQNCkFyZWEpLCBkcHJpdmUsIGRoYywgYW5kIGhv bWVuZXQgKElOVCBBcmVhKS4gQWxsIGxhc3QtY2FsbCBhbm5vdW5jZW1lbnRzIHdpbGwNCmJlIGNv cGllZCB0byB0aGUgcmVsZXZhbnQgd29ya2luZyBncm91cHMgdG8gZW5zdXJlIHRob3JvdWdoIGFu ZCBjYXJlZnVsDQpyZXZpZXcuIFRoZSB3b3JraW5nIGdyb3VwIHdpbGwgYWxzbyBjb29yZGluYXRl IHdpdGggdGhlIFNFQyBBcmVhLCBhbmQgd2lsbA0KYmUgYXNzaWduZWQgYSBzZWN1cml0eSBhZHZp c29yLg0KDQoNCg0KRnJvbTogQWRkIDxhZGQtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9m IFBhdHJpY2sgTWNNYW51cyA8bWNtYW51c0BkdWNrc29uZy5jb20+DQpEYXRlOiBTYXR1cmRheSwg Tm92ZW1iZXIgMTYsIDIwMTkgYXQgMTowNiBQTQ0KVG86IEJlbiBTY2h3YXJ0eiA8YmVtYXNjPTQw Z29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiBBREQgTWFpbGluZyBsaXN0IDxhZGRAaWV0 Zi5vcmc+LCBSYWxmIFdlYmVyIDxkbnNAZmwxZ2VyLmRlPg0KU3ViamVjdDogUmU6IFtBZGRdIEFn ZW5kYSBhbmQgUmV2aXNlZCBDaGFydGVyIGZvciB0aGUgQUJDRCBCb0YNCg0KVGhpcyBjaGFydGVy IGp1c3Qgc2VlbXMgbGlrZSBhIHN1Z2dlc3Rpb24gZm9yIGEgcGVycGV0dWFsIGZvcnVtIHRvIGFy Z3VlIGFuZCwgYWZhaWN0LCBpc24ndCBhY3R1YWxseSBleHBlY3RlZCB0byBwcm9kdWNlIGFueXRo aW5nLi4uIGl0IGp1c3QgaGFzIHNvbWUgdGhpbmdzIHRoYXQgaWYgdGhleSB3ZXJlIHB1Ymxpc2hl ZCB3b3VsZCBiZWxvbmcgaW4gdGhlIHByb3Bvc2VkIHdnLg0KDQpQbGVhc2UgZG9uJ3QgbWFrZSB1 cyBjb2xsZWN0aXZlbHkgcmVsaXZlIHRoZSBBREQgc2lkZSBtZWV0aW5nIGV2ZXJ5IGZ1bGwgbWVl dGluZy4NCg0KTXkgc3VnZ2VzdGlvbjogSWYgdGhlIHByb3BvbmVudHMgYmVsaWV2ZSB0aGF0IGEg Z3JvdXAgY2FuIHB1Ymxpc2ggYSBkb2N1bWVudCBvbiAoZS4uZy4pICJDb21tdW5pY2F0aW5nIGNv bmZpZ3VyYXRpb24gYmV0d2VlbiB0aGUgbmV0d29yaywgb3BlcmF0aW5nIHN5c3RlbSwgYW5kIGFw cGxpY2F0aW9ucyIgcGxlYXNlIHdyaXRlIGEgY2hhcnRlciB3aXRoIHRoYXQgYXMgdGhlIGdvYWwg b2YgdGhlIGdyb3VwIGFuZCB0aGUgQm9GIGNhbiBkbyB0aGUgdXN1YWwgdGhpbmcgb2YgZGVjaWRp bmcgd2hldGhlciB0aGF0IGlzIGEgcHJvYmxlbSB3b3J0aCBzb2x2aW5nLCBpcyB3ZWxsIHVuZGVy c3Rvb2QsIGFuZCBoYXMgYSBjaGFuY2Ugb2Ygc3VjY2Vzcy4gSWYgaXQgd29ya3Mgb3V0IC0gcmVj aGFydGVyIHRoZSBncm91cCBmb3IgbmV3IHdvcmsuDQoNCg0KQXMgaXMgdGhlIGNoYXJ0ZXIgZmFp bHMgdGhvc2UgdGVzdHMgYnkgcHV0dGluZyBldmVyeXRoaW5nIGluIHNjb3BlIGJ1dCByZXF1aXJp bmcgbm90aGluZyBhdCB0aGUgc2FtZSB0aW1lLg0KDQoNCi1QYXRyaWNrDQoNCg0KDQpPbiBUaHUs IE5vdiAxNCwgMjAxOSBhdCAxOjE0IFBNIEJlbiBTY2h3YXJ0eiA8YmVtYXNjPTQwZ29vZ2xlLmNv bUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86NDBnb29nbGUuY29tQGRtYXJjLmlldGYub3JnPj4gd3Jv dGU6DQoNCg0KT24gVGh1LCBOb3YgMTQsIDIwMTkgYXQgNzo0MiBBTSBSYWxmIFdlYmVyIDxkbnNA ZmwxZ2VyLmRlPG1haWx0bzpkbnNAZmwxZ2VyLmRlPj4gd3JvdGU6DQpNb2luIQ0KDQpPbiAxMyBO b3YgMjAxOSwgYXQgMjozMiwgQmVuIFNjaHdhcnR6IHdyb3RlOg0KPiBQbGVhc2UgcmV2aWV3IHRo ZSBhZ2VuZGEgYW5kIHByb3Bvc2VkIGNoYXJ0ZXIsIGFuZCBqb2luIHVzIG5leHQgd2Vlaw0KPiBm b3IgYQ0KPiBmdWxsIGRpc2N1c3Npb24uDQogRnJvbSB0aGUgcHJvcG9zZWQgY2hhcnRlcjoNCj4g VGhpcyB3b3JraW5nIGdyb3VwIHdpbGwgY29uc2lkZXIgdGVjaG5pY2FsIGRyYWZ0cyBvbiBETlMg Y2xpZW50DQo+IGNvbmZpZ3VyYXRpb24sIGVzcGVjaWFsbHkgd2l0aCBhIGZvY3VzIG9uIHRoZSBm b2xsb3dpbmcgaXRlbXMgd2hlcmUNCj4gdGVjaG5pY2FsIGNvbnNlbnN1cyBzZWVtcyBvYnRhaW5h YmxlOg0KPg0KPiAtIENvbW11bmljYXRpbmcgY29uZmlndXJhdGlvbiBiZXR3ZWVuIHRoZSBuZXR3 b3JrLCBvcGVyYXRpbmcgc3lzdGVtLA0KPiBhbmQNCj4gYXBwbGljYXRpb25zDQo+IC0gRGlzY292 ZXJ5IG9mIHJlc29sdmVycyBhbmQgdGhlaXIgY2FwYWJpbGl0aWVzIGFuZCBiZWhhdmlvcnMNCj4g LSBRdWVyeSByb3V0aW5nIGluIGEgbXVsdGktcmVzb2x2ZXIgZW52aXJvbm1lbnQNClRoaXMgaXMg YW1iaWd1b3VzLg0KDQpJIHRoaW5rIHRoaXMgaXMgdmVyeSBjbG9zZWx5IHJlbGF0ZWQgdG8gdGhl IG5leHQgZW50cnkgb24gdGhlIGxpc3QsIHNvIHdlIHNob3VsZCB1bmRlcnN0YW5kIHRoZW0gdG9n ZXRoZXIuICBQZXJoYXBzIHRoZXkgc2hvdWxkIGJlIGNvbWJpbmVkDQoNCklmIGl0IGRlc2NyaWJl cyB0aGUgY3VycmVudCAvZXRjL3Jlc29sdi5jb25mIHRoYXTigJlzDQpmaW5lLA0KDQpUaGF0IHdv dWxkIGJlIGluLXNjb3BlIChhbmQgdGhlcmUgaGFzIGJlZW4gc29tZSBpbm5vdmF0aW9uIGhlcmUg cmVsYXRlZCB0byByZXRyeSBiZWhhdmlvciwgbG9hZCBzcHJlYWRpbmcsIGV0Yy4gd2hpY2ggY291 bGQgYmUgZG9jdW1lbnRlZCkuDQoNCmJ1dCBJIGZlYXIgdGhhdCBpdCBkZXNjcmliZXMgc29tZXRo aW5nIHdoZXJlIHlvdSBhc2sg4oCccmVzb2x2ZXINCkHigJ0gZm9yIGV4YW1wbGUuY29tPGh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi9leGFtcGxlLmNvbV9fOyFyeF9MNzVJVGdPUSFR cFlpWW1MZnc1eDBHTkN6bjU1cWdzVmVpazhTY3F0dDdSUXp6VEdoRzRwZUNwbFRFNWlqNjdUdDF4 UG9tZDl5dHVRX1VnJD4gYW5kIOKAnHJlc29sdmVyIELigJ0gZm9yIGV4YW1wbGUubmV0PGh0dHBz Oi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwOi9leGFtcGxlLm5ldF9fOyFyeF9MNzVJVGdPUSFR cFlpWW1MZnc1eDBHTkN6bjU1cWdzVmVpazhTY3F0dDdSUXp6VEdoRzRwZUNwbFRFNWlqNjdUdDF4 UG9tZC1Jd1NXallnJD4uDQoNCkkgdGhpbmsgZGVzaWducyBvZiB0aGlzIGtpbmQgd291bGQgYWxz byBiZSBpbi1zY29wZS4NCg0KSSBkb27igJl0IHRoaW5rIHRoYXQgdGhlcmUgaXMgY29uc2Vuc3Vz IGZvciBzdWNoIGFuIGFwcHJvYWNoLg0KDQpJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGEgc2luZ2xl IGFwcHJvYWNoIGhlcmU7IGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlcmUgaXMgYSB2YXN0IHJhbmdl IG9mIHBvc3NpYmxlIGNsaWVudCBiZWhhdmlvcnMgcmVsYXRlZCB0byBtdWx0aXBsZSByZXNvbHZl cnMuICBSZWNvbW1lbmRpbmcgYSBzaW5nbGUgYmVoYXZpb3IgdW5pdmVyc2FsbHkgbWlnaHQgYmUg Y29udHJvdmVyc2lhbCwgYnV0IEkgdGhpbmsgdGhlcmUgaXMgcGxlbnR5IG9mIHJvb20gZm9yIHBy b2R1Y3RpdmUgdGVjaG5pY2FsIGRpc2N1c3Npb24gaW4gdGhpcyBhcmVhIHdpdGhvdXQgdHJpZ2dl cmluZyByZWZsZXhpdmUgZGlzYWdyZWVtZW50Lg0KDQo+IC0gTXVsdGlwbGUgbm9uLWVxdWl2YWxl bnQgcXVlcnkgcGF0aHMsIHN1Y2ggYXMgc3BsaXQtaG9yaXpvbiBETlMgb3INCj4gZ2VvLXNlbnNp dGl2ZSBhbnN3ZXJzDQoNCkFzIGFuIGV4YW1wbGUgb2YgdGhlIGtpbmRzIG9mIGlzc3VlcyB0aGF0 IGNvbWUgdXAgaGVyZSwgY29uc2lkZXIgTW96aWxsYSdzIGRlZmF1bHQgYmVoYXZpb3IgWzFdLCBp biB3aGljaCBhbiBOWERPTUFJTiByZXNwb25zZSBmcm9tIHRoZSBwcmltYXJ5IHJlc29sdXRpb24g cGF0aCB0cmlnZ2VycyBhIHJldHJ5IG9mIHRoZSBxdWVyeSBvbiBhIHNlY29uZCByZXNvbHV0aW9u IHBhdGguICBUaGlzIGlzIGFuIGludGVyZXN0aW5nIGNob2ljZSB3aXRoIHBhcnRpY3VsYXIgcHJp dmFjeSwgc2VjdXJpdHksIGNvbXBhdGliaWxpdHksIGFuZCBwZXJmb3JtYW5jZSBwcm9wZXJ0aWVz LiAgUGVyaGFwcyBpdCdzIHdvcnRoIHNwZWNpZnlpbmcgdGhpcyBzb2x1dGlvbiBpbiBtb3JlIGRl dGFpbCwgb3IgcGVyaGFwcyBkZWZpbmluZyBhIHJhbmdlIG9mIHNvbHV0aW9ucyB3aXRoIGRpZmZl cmVudCBwcm9wZXJ0aWVzLiAgSSBiZWxpZXZlIHdlIGNhbiBkaXNjdXNzIHRoZSBwcm9wZXJ0aWVz IG9mIGRpZmZlcmVudCBzdHViIHN0YXRlLW1hY2hpbmVzIHdpdGhvdXQgZGViYXRpbmcgTW96aWxs YSdzIG1ldGhvZCBmb3IgY2hvb3NpbmcgdGhlIHByaW1hcnkgcmVzb2x2ZXIuDQoNClsxXSBodHRw czovL3N1cHBvcnQubW96aWxsYS5vcmcvZW4tVVMva2IvZG5zLW92ZXItaHR0cHMtZG9oLWZhcXMj d19ob3ctZG9lcy1maXJlZm94LWhhbmRsZS1zcGxpdC1ob3Jpem9uLWRuczxodHRwczovL3VybGRl ZmVuc2UuY29tL3YzL19faHR0cHM6L3N1cHBvcnQuLi5tb3ppbGxhLm9yZy9lbi1VUy9rYi9kbnMt b3Zlci1odHRwcy1kb2gtZmFxcyp3X2hvdy1kb2VzLWZpcmVmb3gtaGFuZGxlLXNwbGl0LWhvcml6 b24tZG5zX187SXchcnhfTDc1SVRnT1EhUXBZaVltTGZ3NXgwR05Dem41NXFnc1ZlaWs4U2NxdHQ3 UlF6elRHaEc0cGVDcGxURTVpajY3VHQxeFBvbWQtbEpGblRxZyQ+DQoNCj4gLSBMb2NhbCBETlMg Y2FjaGVzIChlLmcuIHBhcnRpdGlvbmluZywgdXNlIG9mIHN0YWxlIHJlY29yZHMpDQo+IC0gUmVz aWxpZW5jZSBhbmQgZmF1bHQtdG9sZXJhbmNlIChlLmcuIHNpbmdsZSBwb2ludHMgb2YgZmFpbHVy ZSkNCj4gLSBTdXBwb3J0IGZvciBkZWJ1Z2dpbmcgYW5kIGFuYWx5c2lzDQo+IC0gRE5TIFB1c2gg KGFjY2VwdGluZyByZXNwb25zZXMgdG8gcXVlcmllcyB0aGF0IGhhdmUgbm90IHlldCBiZWVuDQo+ IGlzc3VlZCkNClNhbWUgdGhpbmcgSSBkb27igJl0IHRoaW5rIHRoYXQgdGhlcmUgaXMgY29uc2Vu c3VzIG9uIHRoaXMuDQoNCldlIGRvbid0IG5lZWQgY29uc2Vuc3VzIHRoYXQgYSB0b3BpYyBpcyB3 b3J0aHdoaWxlIGluIG9yZGVyIHRvIGluY2x1ZGUgaXQgaW4gYSB3b3JraW5nIGdyb3VwIGNoYXJ0 ZXIuICBXZSBtZXJlbHkgbmVlZCB0byBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgc29tZSBwb3NpdGl2 ZSBpbnRlcmVzdCBhbmQgcG90ZW50aWFsIGZvciBhIHRlY2huaWNhbCBjb25zZW5zdXMgdG8gZW1l cmdlIHdpdGhvdXQgZGVyYWlsaW5nIHRoZSB3b3JraW5nIGdyb3VwJ3Mgb3RoZXIgdG9waWNzLg0K DQpJIHBlcnNvbmFsbHkNCnRoaW5rIGl0IGlzIGEgYmFkIGlkZWEsIGJ1dCBJIHNlZW0gdG8gcmVj YWxsIGZyb20gZWFybGllciBkaXNjdXNzaW9ucw0KdGhhdCBvdGhlcnMgYWdyZWVkIHdpdGggbWUu IElNSE8gdGhpcyBiZWxvbmdzIGluIHRoZSByZWxldmFudCwgYnV0IG1vcmUNCmNoYWxsZW5naW5n IGZvciAgY29uc2Vuc3VzIGJ1aWxkaW5nIGNhdGVnb3J5Lg0KDQpJIGRvbid0IHRoaW5rIHRoaXMg dG9waWMgaXMgcGFydGljdWxhcmx5IGNvbnRyb3ZlcnNpYWwsIGFuZCB2ZXJzaW9ucyBvZiB0aGlz IGlkZWEgaGF2ZSBiZWVuIGNvbnNpZGVyZWQgcHJldmlvdXNseSB3aXRob3V0IG1ham9yIGluY2lk ZW50LCBlLmcuIFsyXS4gIFRoaXMgaXMgcHVyZWx5IGEgcGVyZm9ybWFuY2UgcXVlc3Rpb247IHRo ZXJlIGlzIGxpdHRsZSBzZWN1cml0eSByZWxldmFuY2UsIGJlY2F1c2Ugd2UgYXJlIHNwZWFraW5n IGFib3V0IGFuc3dlcnMgZGVsaXZlcmVkIGZyb20gdGhlIHNhbWUgcmVzb2x2ZXIgYW5kIHF1ZXJ5 IHBhdGggYXMgYWxsIHRoZSBvdGhlciBETlMgcmVzcG9uc2VzLg0KDQpJbiBhbnkgY2FzZSwgUkZD IDg0ODQgRG9IIGFscmVhZHkgZGVmaW5lcyBETlMgUHVzaCAoU2VjdGlvbiA1LjMpLCBhbG9uZyB3 aXRoIHNvbWUgcnVsZXMgYWJvdXQgd2hlbiBpdCBjYW5ub3QgYmUgdXNlZC4gIEl0IGRvZXMgbm90 LCBob3dldmVyLCBwcm92aWRlIGFueSBhZGRpdGlvbmFsIGd1aWRhbmNlIHRoYXQgbWlnaHQgc3Vw cG9ydCBwcmFjdGljYWwgdXNlLCBhbmQgaGFzIHNvbWUgc2lnbmlmaWNhbnQgbGltaXRhdGlvbnMu ICBJbmNsdWRpbmcgdGhpcyB0b3BpYyB3b3VsZCBhbGxvdyB1cyB0byBpbXByb3ZlIHRoZSBzcGVj aWZpY2F0aW9uIG9mIEROUyBQdXNoLCBvciBpbmRlZWQgZGVwcmVjYXRlIGl0IGlmIHRoYXQgaXMg dGhlIHRlY2huaWNhbCBjb25zZW5zdXMuDQoNClsyXSBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtd2t1bWFyaS1kbnNvcC1tdWx0aXBsZS1yZXNwb25zZXMtMDU8aHR0cHM6Ly91cmxk ZWZlbnNlLmNvbS92My9fX2h0dHBzOi90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXdrdW1hcmkt ZG5zb3AtbXVsdGlwbGUtcmVzcG9uc2VzLTA1X187IXJ4X0w3NUlUZ09RIVFwWWlZbUxmdzV4MEdO Q3puNTVxZ3NWZWlrOFNjcXR0N1JRenpUR2hHNHBlQ3BsVEU1aWo2N1R0MXhQb21kOFRLMl9ZYVEk Pg0KDQpTbyBsb25nDQotUmFsZg0K4oCULS0NClJhbGYgV2ViZXINCi0tDQpBZGQgbWFpbGluZyBs aXN0DQpBZGRAaWV0Zi5vcmc8bWFpbHRvOkFkZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYWRkPGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRw czovd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWRkX187IXJ4X0w3NUlUZ09RIVFwWWlZ bUxmdzV4MEdOQ3puNTVxZ3NWZWlrOFNjcXR0N1JRenpUR2hHNHBlQ3BsVEU1aWo2N1R0MXhQb21k LWlaaXNQelEkPg0K --_000_A5F1D3AD73D7449199A83CCA02F49EF4cablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <22A27A334B19824DAF318424645595F9@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIFwoQm9keSBD U1wpIjsNCglwYW5vc2UtMToyIDExIDYgNCAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0 aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1z dHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBp bjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0K c3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3Jt YXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJI VE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkFmdGVyIHJlZmxlY3Rpbmcgb24gdGhl IGxpc3QgZGlzY3Vzc2lvbiwgSSBhZ3JlZSB0aGVyZSBhcmUgYXNwZWN0cyBvZiB0aGUgcHJvcG9z ZWQgY2hhcnRlciBvbiB3aGljaCBpdCB3aWxsIGJlIGRpZmZpY3VsdCB0byBhY2hpZXZlIGNvbnNl bnN1cyAoTE9MKS4gU28gbWF5YmUgbGV04oCZcyBqdXN0IHNldCBhc2lkZSB0aGUgc3R1ZmYgd2hl cmUgd2UgYWxsIGtub3cNCiB0aGF0IGlzIHRoZSBjYXNlIGFuZCB0cnkgdG8gZm9jdXMgbW9yZSBu YXJyb3dseSBvbiB0aG9zZSBhcmVhcyB3aGVyZSBnZXR0aW5nIGEgZmV3IHRoaW5ncyBkb25lIG1p Z2h0IGJlIHBvc3NpYmxlLiBTbyBmb3IgZXhhbXBsZSDigJMgaGVyZSBhcmUgc29tZSBvZmYtdGhl LWN1ZmYgdGhvdWdodHMgd2hpY2ggbWF5IG9yIG1heSBub3QgYmUgd2VsbCBjb25zaWRlcmVkIG9u IG15IHBhcnQuIDstKSAod2l0aCBhcG9sb2dpZXMgdG8gcGVvcGxlIHRoYXQgdmlldw0KIHRoaXMg aW4gcGxhaW50ZXh0IG1vZGUgdnMuIEhUTUwgLSBzaW5jZSBJIGhhdmUgYWRkZWQgc3RyaWtldGhy b3VnaCBhbmQgY29sb3JlZCB0ZXh0IG1hcmt1cCDigJMgYmx1ZSB0ZXh0IGlzIG5ldyk6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6Ymxh Y2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGlzIHdvcmtpbmcgZ3JvdXAgd2lsbCBjb25zaWRlciB0ZWNo bmljYWwgZHJhZnRzIG9uIEROUyBjbGllbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Y29uZmlndXJhdGlvbiwgZXNwZWNp YWxseSB3aXRoIGEgZm9jdXMgb24gdGhlIGZvbGxvd2luZyBpdGVtcyB3aGVyZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj50 ZWNobmljYWwgY29uc2Vuc3VzIHNlZW1zIG9idGFpbmFibGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4tDQo8cz5Db21tdW5pY2F0aW5nIGNvbmZpZ3VyYXRpb24gYmV0d2VlbiB0aGUgbmV0d29y aywgb3BlcmF0aW5nIHN5c3RlbSwgYW5kPG86cD48L286cD48L3M+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BcHBsaWNhdGlvbnM8L3Nw YW4+PC9zPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMDA3 MEMwIj5Ib3cgcmVzb2x2ZXJzIGNhbiBzaWduYWwgdGhlaXIgY29uZmlndXJhdGlvbiBhbmQvb3Ig cHJhY3RpY2VzIHRvIG9wZXJhdGluZyBzeXN0ZW1zIGFuZCBhcHBsaWNhdGlvbnMgKGFuZCB1c2Vy cz8pLCB0byBzdXBwb3J0IGRlY2lzaW9uLW1ha2luZyBvciBzZWxlY3Rpb24gYmVoYXZpb3JzIGJ5 IHRob3NlIHBhcnRpZXMuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+LQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMwMDcwQzAiPkF1dG9tYXRlZCBkaXNj b3ZlcnkgJmFtcDsgc2VsZWN0aW9uDQo8L3NwYW4+PHM+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPkRp c2NvdmVyeQ0KPC9zcGFuPjwvcz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+b2YgcmVzb2x2ZXJzPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOiMwMDcwQzAiPiwgd2l0aCBzZWxlY3Rpb24gcG90ZW50aWFsbHkg bWFkZSBiYXNlZCBvbiBkZXRlY3RlZCByZXNvbHZlcg0KPC9zcGFuPjxzPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj5hbmQgdGhlaXINCjwvc3Bhbj48L3M+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPmNhcGFi aWxpdGllcyBhbmQgYmVoYXZpb3JzDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwNzBDMCI+KGJh c2VkIG9uIE9TLCBhcHAgYW5kL29yIHVzZXIgcHJlZmVyZW5jZXMpPC9zcGFuPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l dyZxdW90Oztjb2xvcjpibGFjayI+PGJyPg0KLSBRdWVyeSByb3V0aW5nIGluIGEgbXVsdGktcmVz b2x2ZXIgZW52aXJvbm1lbnQ8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+LSBNdWx0aXBsZSBub24tZXF1 aXZhbGVudCBxdWVyeSBwYXRocywgc3VjaCBhcyBzcGxpdC1ob3Jpem9uIEROUyBvcjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5nZW8tc2Vuc2l0aXZlIGFuc3dlcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwNzBDMCI+LSBEZXRl cm1pbmF0aW9uIC8gZGV0ZWN0aW9uIG9mIHNwbGl0LWhvcml6b24gRE5TIGVudmlyb25tZW50cyBh bmQgc3RhbmRhcmRpemVkIHVzZXMgb2Yg4oCYY2FuYXJ5IGRvbWFpbnPigJkgb3Igb3RoZXIgbWV0 aG9kcyB0byBlbmFibGUgZGV0ZWN0aW9uIG9mIHN1Y2ggZW52aXJvbm1lbnRzPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwNzBDMCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6IzAwNzBDMCI+LSBQb3RlbnRpYWwgdXNlIG9mIGFsdGVybmF0aXZlIGFwcGxpY2F0 aW9uIHBvcnQgbnVtYmVycyBpbiBzb21lIGNvbnRyb2xsZWQgZW52aXJvbm1lbnRzIChlLmcuIG1h bmFnZWQgZW50ZXJwcmlzZSBlbnZpcm9ubWVudHMpLCBpbmNsdWRpbmcgdGhlIHByb3MvY29ucyBh bmQgaW1wbGljYXRpb25zDQogb2Ygc2VjdXJpdHkgZG93bmdyYWRlIGFuZC9vciBkZXRlY3RhYmls aXR5IGluIHRoZXNlIGVudmlyb25tZW50czwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PGJy Pg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHM+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPi0gTG9jYWwgRE5TIGNhY2hlcyAoZS5nLiBwYXJ0aXRpb25p bmcsIHVzZSBvZiBzdGFsZSByZWNvcmRzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcz48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPi0g UmVzaWxpZW5jZSBhbmQgZmF1bHQtdG9sZXJhbmNlIChlLmcuDQo8cz5zaW5nbGUgcG9pbnRzIG9m PC9zPiBmYWlsdXJlPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiMwMDcwQzAiPiBtb2RlcyBmcm9tIGVu Y3J5cHRlZCBETlMgdG8gRG81MyBvciBmcm9tIGEgcHJpbWFyeSBlbmNyeXB0ZWQgRE5TIHJlc29s dmVycyB0byBzZWNvbmRhcnkgb3IgdGVydGlhcnkgcmVzb2x2ZXJzIOKAkyBvciBzb21ldGhpbmcg bGlrZSB0aGF0PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4pDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPi0NCjxzPlN1cHBvcnQ8L3M+IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMDA3MEMw Ij5TdGFuZGFyZHMgLyBhcHByb2FjaGVzDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPmZv ciBkZWJ1Z2dpbmcgYW5kIGFuYWx5c2lzDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwNzBDMCI+ KGUuZy4gdG8gc3VwcG9ydCBkZXZlbG9wbWVudCBvZiBPUyBhbmQgYXBwbGljYXRpb24tbGF5ZXIg ZGlhZ25vc3RpYyB0cm91Ymxlc2hvb3RpbmcgdG9vbHMsIGEgbGEgZGlnLCB3aGV0aGVyIHNvZnR3 YXJlLWRyaXZlbiBvciB1c2VyLXByb21wdGVkKTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ PGJyPg0KPGJyPg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPi0gRE5TIFB1c2ggKGFjY2VwdGluZyByZXNwb25zZXMgdG8g cXVlcmllcyB0aGF0IGhhdmUgbm90IHlldCBiZWVuIGlzc3VlZCkNCjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjojMDA3MEMwIj5bSkwgY29tbWVudDogbm90IHN1cmUgd2h5IHRoaXMgd291bGQgbm90IGJl IGEgY2xpZW50LWRyaXZlbiBhY3Rpdml0eSwgc3VjaCBhcyBsb29raW5nIGF0IGFsbCBwb3NzaWJs ZSBGUUROcyBvbiBhIHNpdGUgdGhhdCBhIHVzZXIgaXMgbGlrZWx5IHRvIGFzayBmb3IgYW5kIHNl bmRpbmcgYWxsIHRob3NlIHF1ZXJpZXMNCiBmcm9tIHRoZSBjbGllbnQgd2hlbiB0aGUgYXBwL3Np dGUgZmlyc3Qgb3BlbnMsIGJhc2VkIG9uIHByaW9yIHVzZXIgYmVoYXZpb3Igb3IgbGlrZWx5IHBh dGh3YXlzIHRocm91Z2ggYW4gYXBwL3NpdGVdPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHM+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPi0gT3NzaWZpY2F0aW9uIGFuZCBldm9sdmFiaWxp dHk8bzpwPjwvbzpwPjwvc3Bhbj48L3M+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5UaGUgZm9sbG93aW5nIHRvcGljcyBh cmUgYWxzbyByZWxldmFudCwgYnV0IHJlcHJlc2VudCBhcmVhcyB0aGF0IGFyZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcz48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48cz48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+c2lnbmlmaWNhbnRseSBtb3JlIGNoYWxsZW5naW5nIGZvciBjb25zZW5zdXMtYnVpbGRp bmc6PG86cD48L286cD48L3NwYW4+PC9zPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjxzcGFuIHN0eWxlPSJ0ZXh0LWRlY29yYXRpb246bm9u ZSI+Jm5ic3A7PC9zcGFuPjwvbzpwPjwvc3Bhbj48L3M+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHM+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPi0gRW5kLXVzZXIgcHJpdmFjeSBhbmQgcGVydmFz aXZlIHN1cnZlaWxsYW5jZTxvOnA+PC9vOnA+PC9zcGFuPjwvcz48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48cz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+LSBEZXRlY3Rpb24gYW5kIHN1cHByZXNz aW9uIG9mIG1hbHdhcmU8bzpwPjwvbzpwPjwvc3Bhbj48L3M+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHM+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPi0gVXNlIG9mIHJlY29yZHMgZnJvbSB1bnRy dXN0ZWQgc291cmNlczxvOnA+PC9vOnA+PC9zcGFuPjwvcz48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48cz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+LSBQb2xpY3kgZW5mb3JjZW1lbnQgYW5kIGNv bnRyb2wgb2YgdGhlIHN0dWIgcmVzb2x2ZXIgY29uZmlndXJhdGlvbjxvOnA+PC9vOnA+PC9zcGFu Pjwvcz48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48cz48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ LSBVc2UgYW5kIGltcGFjdHMgb2YgbGFyZ2UgcmVjdXJzaXZlIHJlc29sdXRpb24gc2VydmljZXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3M+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHM+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+PHNwYW4gc3R5bGU9InRleHQtZGVjb3JhdGlvbjpub25lIj4m bmJzcDs8L3NwYW4+PC9vOnA+PC9zcGFuPjwvcz48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 cz48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBub3QgYXR0ZW1w dCB0byByZXNvbHZlIGRpc2FncmVlbWVudHMgb24gdGhlc2UgdG9waWNzLDxvOnA+PC9vOnA+PC9z cGFuPjwvcz48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48cz48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+YW5kIHdpbGwgcmVxdWlyZSBmdWxsIGNvbnNlbnN1cyBvbiBhbnkgc3RhdGVtZW50cyByZWdh cmRpbmcgdGhlc2UgYXJlYXMuPG86cD48L286cD48L3NwYW4+PC9zPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+VGhpcyB3b3Jr aW5nIGdyb3VwIHdpbGwgY29vcmRpbmF0ZSB3aXRoIGRuc29wIChPUFMgQXJlYSksIGNhcHBvcnQg KEFSVDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5BcmVhKSwgZHByaXZlLCBkaGMsIGFuZCBob21lbmV0IChJTlQgQXJlYSku IEFsbCBsYXN0LWNhbGwgYW5ub3VuY2VtZW50cyB3aWxsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPmJlIGNvcGllZCB0byB0 aGUgcmVsZXZhbnQgd29ya2luZyBncm91cHMgdG8gZW5zdXJlIHRob3JvdWdoIGFuZCBjYXJlZnVs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29s b3I6YmxhY2siPnJldmlldy4gVGhlIHdvcmtpbmcgZ3JvdXAgd2lsbCBhbHNvIGNvb3JkaW5hdGUg d2l0aCB0aGUgU0VDIEFyZWEsIGFuZCB3aWxsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPmJlIGFzc2lnbmVkIGEgc2VjdXJp dHkgYWR2aXNvci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QWRkICZsdDthZGQtYm91bmNlc0Bp ZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFBhdHJpY2sgTWNNYW51cyAmbHQ7bWNtYW51c0BkdWNr c29uZy5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9iPlNhdHVyZGF5LCBOb3ZlbWJlciAxNiwgMjAx OSBhdCAxOjA2IFBNPGJyPg0KPGI+VG86IDwvYj5CZW4gU2Nod2FydHogJmx0O2JlbWFzYz00MGdv b2dsZS5jb21AZG1hcmMuaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5BREQgTWFpbGluZyBs aXN0ICZsdDthZGRAaWV0Zi5vcmcmZ3Q7LCBSYWxmIFdlYmVyICZsdDtkbnNAZmwxZ2VyLmRlJmd0 Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW0FkZF0gQWdlbmRhIGFuZCBSZXZpc2VkIENoYXJ0 ZXIgZm9yIHRoZSBBQkNEIEJvRjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBjaGFydGVyIGp1c3Qgc2VlbXMgbGlrZSBhIHN1 Z2dlc3Rpb24gZm9yIGEgcGVycGV0dWFsIGZvcnVtIHRvIGFyZ3VlIGFuZCwgYWZhaWN0LCBpc24n dCBhY3R1YWxseSBleHBlY3RlZCB0byBwcm9kdWNlIGFueXRoaW5nLi4uIGl0IGp1c3QgaGFzIHNv bWUgdGhpbmdzIHRoYXQgaWYgdGhleSB3ZXJlIHB1Ymxpc2hlZCB3b3VsZCBiZWxvbmcgaW4gdGhl IHByb3Bvc2VkIHdnLiZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5QbGVhc2UgZG9uJ3QgbWFrZSB1cyBjb2xsZWN0aXZlbHkgcmVsaXZlIHRoZSBB REQgc2lkZSBtZWV0aW5nIGV2ZXJ5IGZ1bGwgbWVldGluZy4NCjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgc3VnZ2VzdGlvbjogSWYgdGhlIHByb3BvbmVu dHMgYmVsaWV2ZSB0aGF0IGEgZ3JvdXAgY2FuIHB1Ymxpc2ggYSBkb2N1bWVudCBvbiAoZS4uZy4p ICZxdW90OzxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Q29tbXVuaWNhdGluZyBjb25maWd1cmF0 aW9uIGJldHdlZW4gdGhlIG5ldHdvcmssIG9wZXJhdGluZyBzeXN0ZW0sIGFuZCBhcHBsaWNhdGlv bnMmcXVvdDsgcGxlYXNlIHdyaXRlIGEgY2hhcnRlciB3aXRoIHRoYXQgYXMNCiB0aGUgZ29hbCBv ZiB0aGUgZ3JvdXAgYW5kIHRoZSBCb0YgY2FuIGRvIHRoZSB1c3VhbCB0aGluZyBvZiBkZWNpZGlu ZyB3aGV0aGVyIHRoYXQgaXMgYSBwcm9ibGVtIHdvcnRoIHNvbHZpbmcsIGlzIHdlbGwgdW5kZXJz dG9vZCwgYW5kIGhhcyBhIGNoYW5jZSBvZiBzdWNjZXNzLiBJZiBpdCB3b3JrcyBvdXQgLSByZWNo YXJ0ZXIgdGhlIGdyb3VwIGZvciBuZXcgd29yay48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si Pjxicj4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QXMgaXMgdGhlIGNoYXJ0 ZXIgZmFpbHMgdGhvc2UgdGVzdHMgYnkgcHV0dGluZyBldmVyeXRoaW5nIGluIHNjb3BlIGJ1dCBy ZXF1aXJpbmcgbm90aGluZyBhdCB0aGUgc2FtZSB0aW1lLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4tUGF0cmljazwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRo dSwgTm92IDE0LCAyMDE5IGF0IDE6MTQgUE0gQmVuIFNjaHdhcnR6ICZsdDtiZW1hc2M9PGEgaHJl Zj0ibWFpbHRvOjQwZ29vZ2xlLmNvbUBkbWFyYy5pZXRmLm9yZyI+NDBnb29nbGUuY29tQGRtYXJj LmlldGYub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVGh1LCBOb3YgMTQsIDIwMTkg YXQgNzo0MiBBTSBSYWxmIFdlYmVyICZsdDs8YSBocmVmPSJtYWlsdG86ZG5zQGZsMWdlci5kZSIg dGFyZ2V0PSJfYmxhbmsiPmRuc0BmbDFnZXIuZGU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1vaW4hPGJyPg0K PGJyPg0KT24gMTMgTm92IDIwMTksIGF0IDI6MzIsIEJlbiBTY2h3YXJ0eiB3cm90ZTo8YnI+DQom Z3Q7IFBsZWFzZSByZXZpZXcgdGhlIGFnZW5kYSBhbmQgcHJvcG9zZWQgY2hhcnRlciwgYW5kIGpv aW4gdXMgbmV4dCB3ZWVrIDxicj4NCiZndDsgZm9yIGE8YnI+DQomZ3Q7IGZ1bGwgZGlzY3Vzc2lv bi48YnI+DQombmJzcDtGcm9tIHRoZSBwcm9wb3NlZCBjaGFydGVyOjxicj4NCiZndDsgVGhpcyB3 b3JraW5nIGdyb3VwIHdpbGwgY29uc2lkZXIgdGVjaG5pY2FsIGRyYWZ0cyBvbiBETlMgY2xpZW50 PGJyPg0KJmd0OyBjb25maWd1cmF0aW9uLCBlc3BlY2lhbGx5IHdpdGggYSBmb2N1cyBvbiB0aGUg Zm9sbG93aW5nIGl0ZW1zIHdoZXJlPGJyPg0KJmd0OyB0ZWNobmljYWwgY29uc2Vuc3VzIHNlZW1z IG9idGFpbmFibGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgLSBDb21tdW5pY2F0aW5nIGNvbmZpZ3Vy YXRpb24gYmV0d2VlbiB0aGUgbmV0d29yaywgb3BlcmF0aW5nIHN5c3RlbSwgPGJyPg0KJmd0OyBh bmQ8YnI+DQomZ3Q7IGFwcGxpY2F0aW9uczxicj4NCiZndDsgLSBEaXNjb3Zlcnkgb2YgcmVzb2x2 ZXJzIGFuZCB0aGVpciBjYXBhYmlsaXRpZXMgYW5kIGJlaGF2aW9yczxicj4NCiZndDsgLSBRdWVy eSByb3V0aW5nIGluIGEgbXVsdGktcmVzb2x2ZXIgZW52aXJvbm1lbnQ8YnI+DQpUaGlzIGlzIGFt YmlndW91cy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHRoaXMgaXMgdmVyeSBjbG9zZWx5IHJlbGF0ZWQg dG8gdGhlIG5leHQgZW50cnkgb24gdGhlIGxpc3QsIHNvIHdlIHNob3VsZCB1bmRlcnN0YW5kIHRo ZW0gdG9nZXRoZXIuJm5ic3A7IFBlcmhhcHMgdGhleSBzaG91bGQgYmUgY29tYmluZWQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JZiBpdCBkZXNjcmliZXMgdGhlIGN1cnJlbnQgL2V0Yy9yZXNvbHYuY29uZiB0aGF04oCZ cyA8YnI+DQpmaW5lLDxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhdCB3b3VsZCBiZSBpbi1zY29wZSAoYW5kIHRoZXJlIGhhcyBi ZWVuIHNvbWUgaW5ub3ZhdGlvbiBoZXJlIHJlbGF0ZWQgdG8gcmV0cnkgYmVoYXZpb3IsIGxvYWQg c3ByZWFkaW5nLCBldGMuJm5ic3A7d2hpY2ggY291bGQgYmUgZG9jdW1lbnRlZCkuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1dCBJ IGZlYXIgdGhhdCBpdCBkZXNjcmliZXMgc29tZXRoaW5nIHdoZXJlIHlvdSBhc2sg4oCccmVzb2x2 ZXINCjxicj4NCkHigJ0gZm9yIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19o dHRwOi9leGFtcGxlLmNvbV9fOyFyeF9MNzVJVGdPUSFRcFlpWW1MZnc1eDBHTkN6bjU1cWdzVmVp azhTY3F0dDdSUXp6VEdoRzRwZUNwbFRFNWlqNjdUdDF4UG9tZDl5dHVRX1VnJCIgdGFyZ2V0PSJf YmxhbmsiPg0KZXhhbXBsZS5jb208L2E+IGFuZCDigJxyZXNvbHZlciBC4oCdIGZvciA8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cDovZXhhbXBsZS5uZXRfXzshcnhfTDc1 SVRnT1EhUXBZaVltTGZ3NXgwR05Dem41NXFnc1ZlaWs4U2NxdHQ3UlF6elRHaEc0cGVDcGxURTVp ajY3VHQxeFBvbWQtSXdTV2pZZyQiIHRhcmdldD0iX2JsYW5rIj4NCmV4YW1wbGUubmV0PC9hPi48 bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgdGhpbmsgZGVzaWducyBvZiB0aGlzIGtpbmQgd291bGQgYWxzbyBiZSBpbi1zY29wZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBkb27igJl0IHRoaW5rIHRoYXQgdGhlcmUgaXMgY29uc2Vuc3VzIGZvciBzdWNoIGFuIGFw cHJvYWNoLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBkb24ndCB0aGluayB0aGVyZSBpcyBhIHNpbmdsZSBhcHByb2FjaCBoZXJl OyBpdCBzZWVtcyB0byBtZSB0aGF0IHRoZXJlIGlzIGEgdmFzdCByYW5nZSBvZiBwb3NzaWJsZSBj bGllbnQgYmVoYXZpb3JzIHJlbGF0ZWQgdG8gbXVsdGlwbGUgcmVzb2x2ZXJzLiZuYnNwOyBSZWNv bW1lbmRpbmcgYSBzaW5nbGUgYmVoYXZpb3IgdW5pdmVyc2FsbHkgbWlnaHQgYmUgY29udHJvdmVy c2lhbCwgYnV0IEkgdGhpbmsgdGhlcmUgaXMNCiBwbGVudHkgb2Ygcm9vbSBmb3IgcHJvZHVjdGl2 ZSB0ZWNobmljYWwgZGlzY3Vzc2lvbiBpbiB0aGlzIGFyZWEgd2l0aG91dCB0cmlnZ2VyaW5nIHJl ZmxleGl2ZSBkaXNhZ3JlZW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgLSBNdWx0aXBsZSBub24tZXF1aXZhbGVudCBx dWVyeSBwYXRocywgc3VjaCBhcyBzcGxpdC1ob3Jpem9uIEROUyBvcjxicj4NCiZndDsgZ2VvLXNl bnNpdGl2ZSBhbnN3ZXJzPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBhbiBleGFtcGxlIG9mIHRoZSBraW5kcyBvZiBpc3N1ZXMg dGhhdCBjb21lIHVwIGhlcmUsIGNvbnNpZGVyIE1vemlsbGEncyBkZWZhdWx0IGJlaGF2aW9yIFsx XSwgaW4gd2hpY2ggYW4gTlhET01BSU4gcmVzcG9uc2UgZnJvbSB0aGUgcHJpbWFyeSByZXNvbHV0 aW9uIHBhdGggdHJpZ2dlcnMgYSByZXRyeSBvZiB0aGUgcXVlcnkgb24gYSBzZWNvbmQgcmVzb2x1 dGlvbiBwYXRoLiZuYnNwOyBUaGlzIGlzIGFuIGludGVyZXN0aW5nDQogY2hvaWNlIHdpdGggcGFy dGljdWxhciBwcml2YWN5LCBzZWN1cml0eSwgY29tcGF0aWJpbGl0eSwgYW5kIHBlcmZvcm1hbmNl IHByb3BlcnRpZXMuJm5ic3A7IFBlcmhhcHMgaXQncyB3b3J0aCBzcGVjaWZ5aW5nIHRoaXMgc29s dXRpb24gaW4gbW9yZSBkZXRhaWwsIG9yIHBlcmhhcHMgZGVmaW5pbmcgYSByYW5nZSBvZiBzb2x1 dGlvbnMgd2l0aCBkaWZmZXJlbnQgcHJvcGVydGllcy4mbmJzcDsgSSBiZWxpZXZlIHdlIGNhbiBk aXNjdXNzIHRoZSBwcm9wZXJ0aWVzIG9mDQogZGlmZmVyZW50IHN0dWIgc3RhdGUtbWFjaGluZXMg d2l0aG91dCBkZWJhdGluZyBNb3ppbGxhJ3MgbWV0aG9kIGZvciBjaG9vc2luZyB0aGUgcHJpbWFy eSByZXNvbHZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+WzFdJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0 dHBzOi9zdXBwb3J0Li4ubW96aWxsYS5vcmcvZW4tVVMva2IvZG5zLW92ZXItaHR0cHMtZG9oLWZh cXMqd19ob3ctZG9lcy1maXJlZm94LWhhbmRsZS1zcGxpdC1ob3Jpem9uLWRuc19fO0l3IXJ4X0w3 NUlUZ09RIVFwWWlZbUxmdzV4MEdOQ3puNTVxZ3NWZWlrOFNjcXR0N1JRenpUR2hHNHBlQ3BsVEU1 aWo2N1R0MXhQb21kLWxKRm5UcWckIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9zdXBwb3J0Lm1v emlsbGEub3JnL2VuLVVTL2tiL2Rucy1vdmVyLWh0dHBzLWRvaC1mYXFzI3dfaG93LWRvZXMtZmly ZWZveC1oYW5kbGUtc3BsaXQtaG9yaXpvbi1kbnM8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgLSBMb2NhbCBETlMgY2Fj aGVzIChlLmcuIHBhcnRpdGlvbmluZywgdXNlIG9mIHN0YWxlIHJlY29yZHMpPGJyPg0KJmd0OyAt IFJlc2lsaWVuY2UgYW5kIGZhdWx0LXRvbGVyYW5jZSAoZS5nLiBzaW5nbGUgcG9pbnRzIG9mIGZh aWx1cmUpPGJyPg0KJmd0OyAtIFN1cHBvcnQgZm9yIGRlYnVnZ2luZyBhbmQgYW5hbHlzaXM8YnI+ DQomZ3Q7IC0gRE5TIFB1c2ggKGFjY2VwdGluZyByZXNwb25zZXMgdG8gcXVlcmllcyB0aGF0IGhh dmUgbm90IHlldCBiZWVuIDxicj4NCiZndDsgaXNzdWVkKTxicj4NClNhbWUgdGhpbmcgSSBkb27i gJl0IHRoaW5rIHRoYXQgdGhlcmUgaXMgY29uc2Vuc3VzIG9uIHRoaXMuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBkb24ndCBu ZWVkIGNvbnNlbnN1cyB0aGF0IGEgdG9waWMgaXMgd29ydGh3aGlsZSBpbiBvcmRlciB0byBpbmNs dWRlIGl0IGluIGEgd29ya2luZyBncm91cCBjaGFydGVyLiZuYnNwOyBXZSBtZXJlbHkgbmVlZCB0 byBiZWxpZXZlIHRoYXQgdGhlcmUgaXMgc29tZSBwb3NpdGl2ZSBpbnRlcmVzdCBhbmQgcG90ZW50 aWFsIGZvciBhIHRlY2huaWNhbCBjb25zZW5zdXMgdG8gZW1lcmdlIHdpdGhvdXQgZGVyYWlsaW5n IHRoZQ0KIHdvcmtpbmcgZ3JvdXAncyBvdGhlciB0b3BpY3MuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgcGVyc29uYWxseSA8YnI+ DQp0aGluayBpdCBpcyBhIGJhZCBpZGVhLCBidXQgSSBzZWVtIHRvIHJlY2FsbCBmcm9tIGVhcmxp ZXIgZGlzY3Vzc2lvbnMgPGJyPg0KdGhhdCBvdGhlcnMgYWdyZWVkIHdpdGggbWUuIElNSE8gdGhp cyBiZWxvbmdzIGluIHRoZSByZWxldmFudCwgYnV0IG1vcmUgPGJyPg0KY2hhbGxlbmdpbmcgZm9y Jm5ic3A7IGNvbnNlbnN1cyBidWlsZGluZyBjYXRlZ29yeS48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgdGhpbmsgdGhp cyB0b3BpYyBpcyBwYXJ0aWN1bGFybHkgY29udHJvdmVyc2lhbCwgYW5kIHZlcnNpb25zIG9mIHRo aXMgaWRlYSBoYXZlIGJlZW4gY29uc2lkZXJlZCBwcmV2aW91c2x5IHdpdGhvdXQgbWFqb3IgaW5j aWRlbnQsIGUuZy4gWzJdLiZuYnNwOyBUaGlzIGlzIHB1cmVseSBhIHBlcmZvcm1hbmNlIHF1ZXN0 aW9uOyB0aGVyZSBpcyBsaXR0bGUgc2VjdXJpdHkgcmVsZXZhbmNlLCBiZWNhdXNlIHdlIGFyZQ0K IHNwZWFraW5nIGFib3V0IGFuc3dlcnMgZGVsaXZlcmVkIGZyb20gdGhlIHNhbWUgcmVzb2x2ZXIg YW5kIHF1ZXJ5IHBhdGggYXMgYWxsIHRoZSBvdGhlciBETlMgcmVzcG9uc2VzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhbnkgY2FzZSwg UkZDIDg0ODQgRG9IIGFscmVhZHkgZGVmaW5lcyBETlMgUHVzaCAoU2VjdGlvbiA1LjMpLCBhbG9u ZyB3aXRoIHNvbWUgcnVsZXMgYWJvdXQgd2hlbiBpdCBjYW5ub3QgYmUgdXNlZC4mbmJzcDsgSXQg ZG9lcyBub3QsIGhvd2V2ZXIsIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZ3VpZGFuY2UgdGhhdCBt aWdodCBzdXBwb3J0IHByYWN0aWNhbCB1c2UsIGFuZCBoYXMgc29tZSBzaWduaWZpY2FudCBsaW1p dGF0aW9ucy4mbmJzcDsNCiBJbmNsdWRpbmcgdGhpcyB0b3BpYyB3b3VsZCBhbGxvdyB1cyB0byBp bXByb3ZlIHRoZSBzcGVjaWZpY2F0aW9uIG9mIEROUyBQdXNoLCBvciBpbmRlZWQgZGVwcmVjYXRl IGl0IGlmIHRoYXQgaXMgdGhlIHRlY2huaWNhbCBjb25zZW5zdXMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpbMl0mbmJzcDs8YSBocmVm PSJodHRwczovL3VybGRlZmVuc2UuY29tL3YzL19faHR0cHM6L3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtd2t1bWFyaS1kbnNvcC1tdWx0aXBsZS1yZXNwb25zZXMtMDVfXzshcnhfTDc1SVRnT1Eh UXBZaVltTGZ3NXgwR05Dem41NXFnc1ZlaWs4U2NxdHQ3UlF6elRHaEc0cGVDcGxURTVpajY3VHQx eFBvbWQ4VEsyX1lhUSQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0 bWwvZHJhZnQtd2t1bWFyaS1kbnNvcC1tdWx0aXBsZS1yZXNwb25zZXMtMDU8L2E+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIGxv bmc8YnI+DQotUmFsZjxicj4NCuKAlC0tPGJyPg0KUmFsZiBXZWJlcjxvOnA+PC9vOnA+PC9wPg0K PC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tIDxi cj4NCkFkZCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86QWRkQGlldGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+QWRkQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vdXJs ZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWRk X187IXJ4X0w3NUlUZ09RIVFwWWlZbUxmdzV4MEdOQ3puNTVxZ3NWZWlrOFNjcXR0N1JRenpUR2hH NHBlQ3BsVEU1aWo2N1R0MXhQb21kLWlaaXNQelEkIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hZGQ8L2E+PG86cD48L286cD48L3A+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A5F1D3AD73D7449199A83CCA02F49EF4cablecomcastcom_-- From nobody Sun Nov 17 19:04:10 2019 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 4249712081B for ; Sun, 17 Nov 2019 19:04:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=CQou69JF; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hQj6DVTa 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 ruWYIJxVTNKp for ; Sun, 17 Nov 2019 19:04:07 -0800 (PST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81972120013 for ; Sun, 17 Nov 2019 19:04:07 -0800 (PST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C11DA22108 for ; Sun, 17 Nov 2019 22:04:06 -0500 (EST) Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Sun, 17 Nov 2019 22:04:06 -0500 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=fm3; bh=TNhuWpmr1Y1sTL4kSsJqaOJ9asZ51p1 Vkzu+sXMvgTc=; b=CQou69JFDccHNIdWcT4qqyiqXaZszGgzW7IHK+rfhD12Tq2 dz25K67Icq7p6kbvG5eCxhp+BspVObKUGElbMkbcD+PaVcoRqoAyWGammiKyvhRA kM6zst+i0+ETL5w9MJfmhMWC9HR1hiaNSaS6Q6aKzLWk2sM7JbU35HCsZKI7fDR6 eeQ7Q3iPpGoERYDjMKoHFzjmhSShXI3nqPO5Y/jqRzmUU3HOaIYM/g4KlMnxtXUp tHs2j21FJmjv/7maG6RSACSejTlPe8z7DnPk3aT+O2rh/ayU8KF36MBjC8WXGZ9d V5ZVKh/rzaDMc+lzyGm463+6iktEYnaapXpwOIA== 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=fm1; bh=TNhuWp mr1Y1sTL4kSsJqaOJ9asZ51p1Vkzu+sXMvgTc=; b=hQj6DVTa8kPhBJTMqpe5Id rC6tj0uXXCXx4kfNCPDm7yKgtE6p6a7C/LIQcRhYcoOZUDQqXCm1bwUCjUTHMp8n p1yUgH/guc4h3SXv8eq7G/mTRjENL5nqa2dtcEGCS6bw9FRaQKY75gQZ3iRs7+4r 7ISWmv39AKYjUpxsYZePyuSObl9K2ve7BB4IFKbt8VXjHfXLaCz8l3DwsfofAyd9 7cbyGroC5a3n2mRNu82WBSRyTDXSCz7yTZGE7YbbtwBwfrnWU1w3lfUZcwfFFHra XY4ZN4GO8ORUWp0tMQvrASxL3asvZIHP8D3MSb5UhMV5NEv1GoQrDzPwCqQbpD9w == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeggedgheehucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefofgggkfgjfhffhffvufgtsehttd ertderredtnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucffohhmrghinhepihgvthhfrdhorhhgnecurfgrrh grmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvghtnecuvehluhhs thgvrhfuihiivgeptd X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 79E27E00A3; Sun, 17 Nov 2019 22:04:06 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.1.7-562-gfd0633a-fmstable-20191114v1 Mime-Version: 1.0 Message-Id: <10303a47-6f9c-41f1-94b9-9e3d635c9641@www.fastmail.com> In-Reply-To: References: <680390BE-E819-4951-98EE-C77E9C60E495@piuha.net> <20191117205813.8240D1965255@fafnir.remote.dragon.net> Date: Mon, 18 Nov 2019 11:03:47 +0800 From: "Martin Thomson" To: add@ietf.org Content-Type: text/plain Archived-At: Subject: Re: [Add] Draft on the use of multiple recursive 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, 18 Nov 2019 03:04:09 -0000 On Mon, Nov 18, 2019, at 10:51, Ted Hardie wrote: > My apologies that this didn't get communicated in the draft well; we'll > try to make it clearer in later versions. Section 5.3 is entitled "Poor distribution strategies", but I realize that the text never outright tees up the idea that these are ideas that are explicitly bad. You have to read more closely to get that. https://tools.ietf.org/html/draft-arkko-abcd-distributed-resolver-selection-00#section-5.3 From nobody Sun Nov 17 19:04:40 2019 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 B3B04120044 for ; Sun, 17 Nov 2019 19:04:38 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Y5skp4RmyJn6 for ; Sun, 17 Nov 2019 19:04:36 -0800 (PST) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (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 864DC120048 for ; Sun, 17 Nov 2019 19:04:36 -0800 (PST) Received: by mail-lj1-x230.google.com with SMTP id p18so17079128ljc.6 for ; Sun, 17 Nov 2019 19:04:36 -0800 (PST) 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=dbDL23sHdaPTrHuUcKOgj6+p01SIOECUtRZwD7haif4=; b=AM35K5GiUPX2fKUvpZYog6kW34DKcZOit5AyooVZnILgHihuazXXgk8guQW9VEBbPI Dxoe9P/gpwqrIKBrblBQJPcFN/QweyuZ27YWZiD9Bb/PXyQSshGXvkShCAhR++lIuuyT uyx6caZBUoKhihd5qVSlyir/6W96Z8eg43E2Wf9v3u5H5vYPixATqu/stWIWgppgsHG/ 3b9IB2IUiPIbOvkFalLNzD7EoHK8+iVTS9kyNVjbn9a1rJJFgdJIYoL3vl7XGMkg5+yR iLD76LZwMTa3CA3rGLbsa3uRneQwrgvREUiZlhvaIVMLt2g4B+4QGoBgo78Iji182VZD czSg== 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=dbDL23sHdaPTrHuUcKOgj6+p01SIOECUtRZwD7haif4=; b=LljnX1kCYTMHisZaEVIkVNMMEtNTyQD0tRs5JGSabI+CFHPhGHq2+IYlCLbI1vEYwr hLEJ/yYQH88nMbj90smafQ6P8D3AzD8dqP99+GPnZF0zPW0u2pO0XTFASS8ewNElczU4 h4NYdzXxHodkr/y/6/LKEVDX2gw6rwvr99ZrTGTes96Y3zZOWGuNldhipB3I0endEMlu bmdmUAskXu35vmXknxazdD0XhJqdIj/gfFQ2nIFk34e5g2/Nhk0E3XyS+06lzo5CGcAB EXT5e4Rw+XnAZlwgt9cgVeG0Fg0Vdc/jTI/ZfHCwVBFZUkbAQ85M7zgAa+E9+z7sluXi E+Nw== X-Gm-Message-State: APjAAAVlSmnciREoLHj3z5zwpIL2duto7kXrtjtd+/swGD/2LbYVmksT aaTLVI2t/f2eg7xyYNzbgHd+AKxA9x3Aw/DxvsALKw== X-Google-Smtp-Source: APXvYqwIEAQosg5FFvx5sb1RkFxLLryYfcRFTHNT/ww4z8KZMwpWdchfnT8a6fDVGJgnW4ZTJOjp49MiWw1fbphQBFc= X-Received: by 2002:a2e:7301:: with SMTP id o1mr15993594ljc.16.1574046274842; Sun, 17 Nov 2019 19:04:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sun, 17 Nov 2019 19:03:58 -0800 Message-ID: To: Patrick McManus Cc: Brian Dickson , Ben Schwartz , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000012864b0597963582" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 03:04:39 -0000 --00000000000012864b0597963582 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 17, 2019 at 7:02 AM Patrick McManus wrote: > DoH does not require any particular port number - the server specifies it > as part of the URI Template and there is no default template. You cannot > make another port number the default for https (which doh does required) > without minting another scheme, which seems kind of pointless when you can > simply explicitly use another port as part of the template if you like. > > Handcuffing the protocol to introduce intentional network signaling would > weaken the confidentiality properties of HTTPS - i.e. it is quite explicit > that any HTTPS content (or purpose) is not visible to the network and allow > network attackers to trivially launch downgrade attacks. That isn't in the > interest of securing a protocol. > This more or less reflects my view as well. While I was not a core participant in the design of DoH and decision to have it be on 443 (though that just seems like the obvious design) I do not consider changing the port number or adding some other mechanism to make DoH easier to block to be an improvement. -Ekr > This thread is probably a good example of how ABCD would not be a > productive working group. > > > On Sun, Nov 17, 2019 at 7:41 PM Brian Dickson < > brian.peter.dickson@gmail.com> wrote: > >> >> - The ability of an on-path network operator, such as an enterprise, >> to detect and/or block "rogue" DoH servers which are not on any TRR list >> >> > unregistered is rogue now? > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --00000000000012864b0597963582 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 17, 2019 at 7:02 AM Patri= ck McManus <mcmanus@ducksong.com= > wrote:
=
DoH does not require any particular port number - the= server specifies it as part of the URI Template and there is no default te= mplate. You cannot make another port number the default for https (which do= h does required) without minting another scheme, which seems kind of pointl= ess when you can simply explicitly use another port as part of the template= if you like.

Handcuffing the protocol to introduc= e intentional network signaling would weaken the confidentiality properties= of HTTPS - i.e. it is quite explicit that any HTTPS content (or purpose) i= s not visible to the network and allow network attackers to trivially launc= h downgrade attacks. That isn't in the interest of securing a protocol.=

This more or less reflects my = view as well. While I was not a core participant in the design of DoH and d= ecision to have it be on 443 (though that just seems like the obvious desig= n) I do not consider changing the port number or adding some other mechanis= m to make DoH easier to block to be an improvement.

-Ekr


This thread is probably a good e= xample of how ABCD would not be a productive working group.

<= /div>

On Sun, Nov 17, 2019 at 7:41 PM Brian Dickson <brian.peter.dickson@gma= il.com> wrote:
  • The ability of a= n on-path network operator, such as an enterprise, to detect and/or block &= quot;rogue" DoH servers which are not on any TRR list
<= /div>

unregistered is rogue now?
=C2=A0

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--00000000000012864b0597963582-- From nobody Sun Nov 17 19:12:15 2019 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 65350120841 for ; Sun, 17 Nov 2019 19:12:13 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 tKlAcMZCLM90 for ; Sun, 17 Nov 2019 19:12:11 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 7545D120013 for ; Sun, 17 Nov 2019 19:12:11 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 5FB8F6600BC; Mon, 18 Nov 2019 05:12:10 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lf30phENjE-C; Mon, 18 Nov 2019 05:12:09 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id AE8C66600B1; Mon, 18 Nov 2019 05:12:08 +0200 (EET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Mon, 18 Nov 2019 11:12:05 +0800 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Rob Sayre X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 03:12:13 -0000 Rob, The draft attempts to both talk about the centralisation issues = standalone, but also (correctly, IMHO) notes that there are sometimes = interdependencies between issues.=20 My crystal ball sees a future where DNS query traffic is much more = encrypted than it is today, and that=E2=80=99s a good thing. But my = crystal ball is undecided with respect to whether the DNS system will be = hugely centralised =E2=80=94 which I would consider as a problem =E2=80=94= or more distributed (but perhaps in a different way than today). I = think we are at crossroads, and I would very much like to see the = distributed future, and that is the reason I=E2=80=99m calling for = attention to this issue. I think there are promising directions for = this. But it will take work, and it may be that some people=E2=80=99s = plans need to change because of that. Jari From nobody Sun Nov 17 19:22:18 2019 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 AA30F120848 for ; Sun, 17 Nov 2019 19:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m7xfQXv0f0AT for ; Sun, 17 Nov 2019 19:22:15 -0800 (PST) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 305651200DE for ; Sun, 17 Nov 2019 19:22:15 -0800 (PST) Received: by mail-vk1-xa34.google.com with SMTP id k24so3742074vko.7 for ; Sun, 17 Nov 2019 19:22:15 -0800 (PST) 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=kifGEM7hH4oKsciXLmF8AtkmOHYYGmp5JnqGwYsq/Gk=; b=QwLLyZ/MMPHaahOOuDgAw2jJ8tdoroYHJ885la/IBjiB3vEbQkxYyusTz/cCjG1hHO Om1Khn3ZWcE57Q0fh229+kk5PQpPe47wUwKPvA4KK2XfaE9bKgCE1+tdh8MY0G0a96kg K7KlraInyp59DDJTF8eA9tXrbf2YsjTDTXZwXPPZqAYe/Bc7kwd9kbpkyDIr+rBAhJdo cKRP/2aPzrpg8NmDXh002JSggFQGTXWYS72NJjD9er4CCVdDIRZa0xqRwigpq41m6SNd ielxEHgrYe4kNCfaiUEC+ehBn939YvQeU81aZLaIggQe+1d2lyXQXEG0/89O35EQQBDL /VLA== 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=kifGEM7hH4oKsciXLmF8AtkmOHYYGmp5JnqGwYsq/Gk=; b=pXn70B02ZxM8FwaK+OPcJ4SFF5lJSY+jWqxyW+zDry1A6CfkcAT1lft0t4NHDIYNP0 8+BGIrDpsGpN35c9y5ko7CZiRzmpYof72bCfuRFiYIfZ7MA6VER/0ptGuNkG1ZJ9uY02 +CRDAnH0a3C9ny5za8Vjmzrhdgxsra3Vo7815YPXrbK1idqJKnLKZ0Hka6nsq5MaJKAZ UOKCWjzz/NjckIvSLSrHWO/DMNF/gqIRT7Gmv6MlMWunSW6uF/GSC3SAxoC2Vgd4Cwrx 0VO7rAyaYgWdVEZjvA33OkPTsXG1XN91A9FYo+mGOLlei7cFYyJcOxZ52ID8LnXoFvc3 ay7w== X-Gm-Message-State: APjAAAX6+GzJfYQ3JH1ag1UJPP5c31TPuZY6sLov5eQghIxbK0lpZgIh mHq2Yo/KPHAt+tDhnsTzqTqELh3uSb2TSQQkd8o= X-Google-Smtp-Source: APXvYqxBqJH4Dp1YkENhzpA2gcouSfC99E/FTt9C2pFZ5whyzozXSzBmpbA1BYlpzjHtzgm0FCSy9jDAZ3N2CGBcv1E= X-Received: by 2002:a1f:944a:: with SMTP id w71mr15249015vkd.60.1574047334235; Sun, 17 Nov 2019 19:22:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Brian Dickson Date: Mon, 18 Nov 2019 11:21:57 +0800 Message-ID: To: Eric Rescorla Cc: Patrick McManus , Ben Schwartz , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000003785b305979674c0" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 03:22:17 -0000 --0000000000003785b305979674c0 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 18, 2019 at 11:04 AM Eric Rescorla wrote: > > This more or less reflects my view as well. While I was not a core > participant in the design of DoH and decision to have it be on 443 (though > that just seems like the obvious design) I do not consider changing the > port number or adding some other mechanism to make DoH easier to block to > be an improvement. > > -Ekr > At least as far as concerns Firefox, whose TRR list involves well-known resolvers who AFAIK don't plan on running anything else on 443, I have a question about your view: If changing the port number DOES NOT make DoH easier to block for Firefox's deployment model, would changing port number then be acceptable (if perhaps not favored)? I believe the port number is irrelevant for blocking DoH towards well-known public resolvers, and thus changing the port number has no impact on blocking. (Blocking based solely on IP addresses would be sufficient, with the caveat that a carve-out of allowing port 53 might be done by on-path adversaries.) Brian --0000000000003785b305979674c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 18, 2019 at 11:04 AM Eric= Rescorla <ekr@rtfm.com> wrote:
=

This more or les= s reflects my view as well. While I was not a core participant in the desig= n of DoH and decision to have it be on 443 (though that just seems like the= obvious design) I do not consider changing the port number or adding some = other mechanism to make DoH easier to block to be an improvement.
=

-Ekr

= At least as far as concerns Firefox, whose TRR list involves well-known res= olvers who AFAIK don't plan on running anything else on 443, I have a q= uestion about your view:

If changing the port numb= er DOES NOT make DoH easier to block for Firefox's deployment model, wo= uld changing port number then be acceptable (if perhaps not favored)?
=

I believe the port number is irrelevant for blocking Do= H towards well-known public resolvers, and thus changing the port number ha= s no impact on blocking.
(Blocking based solely on IP addresses w= ould be sufficient, with the caveat that a carve-out of allowing port 53 mi= ght be done by on-path adversaries.)=C2=A0

Brian
--0000000000003785b305979674c0-- From nobody Sun Nov 17 19:42:39 2019 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 37CC912089E for ; Sun, 17 Nov 2019 19:42:32 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 VjWnClVJfvyT for ; Sun, 17 Nov 2019 19:42:30 -0800 (PST) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450: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 6E41F12087C for ; Sun, 17 Nov 2019 19:42:30 -0800 (PST) Received: by mail-lf1-x130.google.com with SMTP id l14so5880047lfh.10 for ; Sun, 17 Nov 2019 19:42:30 -0800 (PST) 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=XDMf3f915jX1EFB5RH0RFtLTLus4xc6vBoyPTLU4Ht4=; b=xcFItDCjrZLRb/HDnI0+/TUk0+YijDD9vkzmyy5t0AtTI/N4KIIQbJe1XejinHku1m F9LGAFKU9HdZx914xkglBo1qOUbuFyi4KXgcdDJg9ysCZAsYa+l/u5UIsDzmwJXre9iC wnei+nOfQSZbw2AEhYzYl3hF3OU9k8Uqp/zX2XGYG2Qs3rJcUlRf4hEHvqRQ2h+ridZG Qx56uKWa42TfBEzwDbVFkYjnry2K0WPVjC/EwRfjJoIbxSTf8vYmBgguD/kJufc6zAqs z2lKqC1G1OCSxY6d8Sdric8ZgwEGVyBBBENH0xro/MyF4d8oqCxv9Cjra4CCRwIiliXP L+gw== 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=XDMf3f915jX1EFB5RH0RFtLTLus4xc6vBoyPTLU4Ht4=; b=ksrMCPXtPHlk9K33UutGkNf8neBKcByYNnwoFfVBTQpB4wkMG77V4bdnM/agIKRgB6 ErVVxkb4ThPUR3sF+8S8KwrlIXXavzL9MtMpt3tUc4CRE/ecVeguqCPlSOAKpxgbyoJ+ choM1zcronf9lNTkbUd7ZIA7mLiQHOEYvqXv4L3YnNPaCaklOFWB7xO/ENpeLyA85rua Q6XOMsVamNFhVWvBd8paCGWPSDv4upQKYagHtMzolNijYmGc8WceZP6Xgx6UzyiS8O1A yZ65E9pxHrMGCxhbPuHrSd6eR6kv9oAlm+EJ7yfSZk5dTNY+13MCzIq9w8pSCwyK/XBO vPbA== X-Gm-Message-State: APjAAAWB2rqkS3qi1IUyidTztdiUwXtxTepKx3Hwc/rmq1xDsGFB2+Xz Qezf0ZUOZtI7BwtDM8XeFpxHOUoRepK2tC91ya7AGA== X-Google-Smtp-Source: APXvYqzgc1QGCR8mpdx82SqWvUt+On4kF/W9yx2Wqh++LAaI+7wmzlGsgOh6xDHGe3oZEzQdqXWvVAO8alBKxhwAZQY= X-Received: by 2002:a19:cbcc:: with SMTP id b195mr18497126lfg.129.1574048548663; Sun, 17 Nov 2019 19:42:28 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Rescorla Date: Sun, 17 Nov 2019 19:41:51 -0800 Message-ID: To: Brian Dickson Cc: Patrick McManus , Ben Schwartz , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000009a480d059796bc8e" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 03:42:37 -0000 --0000000000009a480d059796bc8e Content-Type: text/plain; charset="UTF-8" On Sun, Nov 17, 2019 at 7:22 PM Brian Dickson wrote: > > > On Mon, Nov 18, 2019 at 11:04 AM Eric Rescorla wrote: > >> >> This more or less reflects my view as well. While I was not a core >> participant in the design of DoH and decision to have it be on 443 (though >> that just seems like the obvious design) I do not consider changing the >> port number or adding some other mechanism to make DoH easier to block to >> be an improvement. >> >> -Ekr >> > > At least as far as concerns Firefox, whose TRR list involves well-known > resolvers who AFAIK don't plan on running anything else on 443, > They don't presently do so, but I'm not aware of any statement that they never plan to, and there are clearly some advantages to muxing HTTP and DNS on the same transport. I have a question about your view: > > If changing the port number DOES NOT make DoH easier to block for > Firefox's deployment model, would changing port number then be acceptable > (if perhaps not favored)? > As Patrick says, there's nothing preventing people from running DoH on a separate port, as it's part of the URL template. I do not believe we should change the default port. -Ekr --0000000000009a480d059796bc8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 17, 2019 at 7:22 PM Brian= Dickson <brian.peter.d= ickson@gmail.com> wrote:


On Mon, Nov 18, 2019= at 11:04 AM Eric Rescorla <ekr@rtfm.com> wrote:

This more or less reflects my view as well. While I was = not a core participant in the design of DoH and decision to have it be on 4= 43 (though that just seems like the obvious design) I do not consider chang= ing the port number or adding some other mechanism to make DoH easier to bl= ock to be an improvement.

-Ekr

At least as far as concerns Firefox, who= se TRR list involves well-known resolvers who AFAIK don't plan on runni= ng anything else on 443,

They don't presently do so, but I'm not aware of any statement tha= t they never plan to, and=C2=A0 there are clearly some advantages to muxing= HTTP and DNS on the same transport.


I have a question about your view:

=
If changing the port number DOES NOT make DoH easier to block fo= r Firefox's deployment model, would changing port number then be accept= able (if perhaps not favored)?

As Patrick says, there's nothing preventing people from running D= oH on a separate port, as it's part of the URL template. I do not belie= ve we should change the default port.

-Ekr

--0000000000009a480d059796bc8e-- From nobody Sun Nov 17 19:45:18 2019 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 E4FEF120096; Sun, 17 Nov 2019 19:45:16 -0800 (PST) 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 q-4dlWsmO4gP; Sun, 17 Nov 2019 19:45:16 -0800 (PST) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA37E12004C; Sun, 17 Nov 2019 19:45:15 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 059F191757; Sun, 17 Nov 2019 22:45:15 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24018.5067.5500.609408@gro.dd.org> Date: Sun, 17 Nov 2019 22:45:15 -0500 From: Dave Lawrence To: ADD Mailing list , doh@ietf.org Reply-To: abcd-chairs@ietf.org Archived-At: Subject: [Add] Note takers & Jabber Scribe for ABCD BoF 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, 18 Nov 2019 03:45:17 -0000 If you are willing to be either a note taker or the Jabber scribe for the ABCD Bof on Tuesday at 13:30-15:00 in Padang, please let us know. It'd be great to get this nailed down in advance of the meeting rather than having to wrangle it at the start. Thanks in advance to the hordes of expected volunteers for your service to the community! From nobody Sun Nov 17 19:50:00 2019 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 443AE120825 for ; Sun, 17 Nov 2019 19:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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=N1XcxsII; dkim=pass (2048-bit key) header.d=comcast.com header.b=LJLGNRu8; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=MAKzm4Gu 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 K_k2DSSY5Mp8 for ; Sun, 17 Nov 2019 19:49:53 -0800 (PST) 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 A2A68120818 for ; Sun, 17 Nov 2019 19:49:53 -0800 (PST) Received: from pps.filterd (m0184891.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAI3kv0Z009474 for ; Sun, 17 Nov 2019 22:49:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=ExphjYpMxj3oZXdayZAgi3ee85ozvsCC957W5n4QD+8=; b=N1XcxsIIdYgTbM6NmRXAQjbJKKfQps57CXBo13WY/arYQb7zsP9PLsLA4SqvnHmU1noP sF1s1JPrW3bLY6qa/G50kWBHfER5tZF7V746qnM5CFHqwluqSvn4/m3xuUc9qC6NzeqQ DWj0nUN2oUj1gq46hjihuFOBd6fqGjxSBmo87r0F6xsrPdDfm3iiCHZw0kitIaNrLxv4 Ktd9J+L7Q671jUJvQKTrUxbDWwNW4L9AT3Y5qPkl1FwZHF/MBzuZtGSGKQmxg4/v13xj wML5xbaQ9prDz5Iv3aY3qAK9Shym6XNAUHik2Bblvg3hEXVNL9eqEjPCBl26D6b+lDJQ bQ== Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) by mx0b-00143702.pphosted.com with ESMTP id 2waerg9hyv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Sun, 17 Nov 2019 22:49:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1574048965; x=2437962565; 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=ExphjYpMxj3oZXdayZAgi3ee85ozvsCC957W5n4QD+8=; b=LJLGNRu8rCgxA6naRBmgsANhyqV0i/qZjBLhI7FqRVxJPN5yEiDXWrv6acMyxN5S CrCMVlPUCRMNwYdSPEnO4mykv4CaZlosfln6YTWUZF/xhXssH68HLXN6lwM0E9fO QmsH7r9L5LpJ7igs20t3ZSBX4XXeHf6Ee48L5aFvyVSj9eVXV8ifk4gGnJvklol1 X6kRVRr2Ja//Sbwfyz5xlyhnQT/D1ofob/H7bLFqgTR9jxs99Q8kfkSEC/C22liy z26Ymv/wuTWjvZGdQgj9YQqTr/GrLshbpk2e2LNtfC7xwirXQg4RhamxkDPY0xlR ZravYIUqE/lluV0EVUeFDw==; X-AuditID: a2962c47-555ff700000112ce-09-5dd214c5bd91 Received: from copdcexc33.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 15.5F.04814.5C412DD5; Sun, 17 Nov 2019 20:49:25 -0700 (MST) Received: from COPDCEX17.cable.comcast.com (147.191.124.148) by copdcexc33.cable.comcast.com (147.191.125.132) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Sun, 17 Nov 2019 20:49:49 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX17.cable.comcast.com (147.191.124.148) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 17 Nov 2019 20:49:49 -0700 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (104.47.32.52) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 17 Nov 2019 22:49:46 -0500 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB3863.namprd11.prod.outlook.com (10.255.161.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2430.25; Mon, 18 Nov 2019 03:49:44 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 03:49:44 +0000 From: "Livingood, Jason" To: ADD Mailing list Thread-Topic: [Add] Draft on deployment models for Internet infrastructure Thread-Index: AQHVnPX7OynTyGyp40y6czo8LJvZGaeOteEAgAFzWID//891gA== Date: Mon, 18 Nov 2019 03:49:44 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-originating-ip: [2001:67c:1232:144:fcaa:fd79:9cb8:c6a7] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 66993506-cdbf-4018-a7f5-08d76bda5979 x-ms-traffictypediagnostic: BY5PR11MB3863: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(39860400002)(376002)(366004)(136003)(346002)(189003)(199004)(102836004)(186003)(316002)(6246003)(2906002)(305945005)(25786009)(486006)(6512007)(6486002)(58126008)(76176011)(6436002)(476003)(46003)(11346002)(99286004)(2616005)(446003)(91956017)(4744005)(81166006)(81156014)(8676002)(76116006)(256004)(14454004)(7736002)(478600001)(33656002)(6116002)(5660300002)(8936002)(66476007)(71200400001)(71190400001)(86362001)(80792005)(6506007)(66556008)(66446008)(6916009)(66946007)(64756008)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB3863; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ypMcchxvas8UKICcygi2tPR1wnK0QwBFdaZPcXG0h5QgupVU375YjCoINDoed7aG6mHQ4B+TEOyIc2Z5ZBMmirrNZ7MYF2rg7YvQpiFi1rETZB3XdaJwjPKBap6++zYCdNfH1b/p75zvgExqX4za0vScgvwh/YxS/47G8Yk0cGJ/fP7Y/QR/tNNwEgloCvg7nm5SaoexAMI9Rxn7OD6BtfckfCvk8ou8M0iybrfnYlB49bFH472yxTgTNI/Yu4wJmw/1eZ9OH1WdX/S6bH0U8A8F/dNwByogFHr214AAJqpdedWDnHXTIwu6K4L36TIeZjPV9lRloU9MglEwm1dnsKJlmqChMvZVUo4WHnqIEQTnHJXEKkR+K8RE6LFl2NO/uTLOFjM+WkxpQuQkNTL/KnJN17vPitH2NFZGx794NxPPTMxODj9vSrII92VMJbKX x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EJ92yn3SP6gRRdCmUfGZt08jQkV/apGZ0nOfajIPyLUQAQrstRm/r5cjQIMfqpEwvuu+XP2s37/l/Y2xiou1GPF++loedIpZAXoiP86xhWfA1Db951C4ebwp7J0RDts7ojpBIzgFhN42mTnDQgqNhZaGozEwHM5q889/5VLjHgKV0fMJrsf3f8Ehm5zhLQeFUNFFAYSI6DIgeholNjySbkgMPCHyui5U3gJItUrPnWaF5qC/d50VFNRvgY+XhtE0Seu475A7m4ZXLMrjh1nNh4kM+tuzwgAfE1SR8qerWvQmj2iccLNPe4gb6AoIo1/oHzwl6Dng+2XwUXQNwAV01g== 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=okclCRyNcEhuN0vxcHGDZrm3HgsACh1ICv7NUZbAOvE=; b=F+gJ8lyRHWTawvnbIu4t8NAIH2DrcsAJceiOia3ch6vpYz3mkanp7gMikUCcPmPmwdwr2eliGWpiUfeRu1+U0V8LTwmYdkqgwXwems5tajCcuG0ft27k/C///ZQQHvNW1x4TnTWCTkhjg1oaNK4cqla2pcCuwabL1VccpU1GfVPuAn/yOXUirA32uIpkImSbWgNm2bLyVZMv/1YgQ+In3uwx/prJHx5BXneVms70rY7qWQzaANFSzg4rvyVp6iuIEesbPmIRRcw0jfwRG0/8s7F7LS5TS4O8dyWa5ZDb7bzggeVmjY5Fn3cI5ivgvukvVbI0Tn9ptTRm4Pfs82/GkQ== 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=okclCRyNcEhuN0vxcHGDZrm3HgsACh1ICv7NUZbAOvE=; b=MAKzm4Gum50XsxJNZlppJBqIT8rkXOe5HuFC1WePNrAToOIY/7CfGtYMtscTJ91AVahSsa8yKK8B7RIvcVbYhYtrL4hQzniyKA4gjFRJAfWbWXZEDYo13LsKGRl/RVGE3O9Cnsas1WlJJRcMEzQ7+WPRES8xxzObtU3coUn3Jn0= x-ms-exchange-crosstenant-network-message-id: 66993506-cdbf-4018-a7f5-08d76bda5979 x-ms-exchange-crosstenant-originalarrivaltime: 18 Nov 2019 03:49:44.2463 (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: IoHV0EUkg0EVLqH/8FWkGf4zfrjxRMUH7n85GMJT5KbbqHqFQeNo994DnagPDr0qeP2xu0x3UGlMYzyWzBv2wjeoolOGZjGQXWFMYUPlUoY= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB3863 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <4489E59C82C7774887B53E3D4DF5150D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA23Se0hTURwHcM69e9yNVqep9WNp1MqssM2FWVJJmL0zQiMoGnrV4yOXyt2S tCDBiFoYlSG4DGvOJLUCk0xbRTZLM3zbH0MdsxLFHuaMFLLyehcEef76nHO+53ceHIZWesQq Ji3DRLgM1qCWyEXxXEnhuibfLn1I12f1pt+t9yXb0G6bbYo6iI7moS2mVI6wpiiSTDKMJEK+ 7L+2JYEkZ3JkB8sZcmKIgbBzx/hkEjGkZRNOO2cZ7Zx14s1U6tWqMTqrSH5qYHyQzkMTMjOS MYBDYaj4opi3EjsouNGgEJxPwbkhiRnJZ9yHYKqiFgmdZgQOz4hU6FynYLSvzBsbRPDS1YT4 9RIcBv23e2jevngFlPfXUbx98B64c6+aEsb3wlXPU68jodnhnLUIB0Ktu0rKW4Gj4Gdrhfd8 vQieXV7AW4aPQdvbXhFvhBfBjzdCTRovBueHUkq4GwabvZ0W7Acj73/N1GEYP6yFF9PRwtIk KDNbvfFwKJvuRIIDoKv0ktfR0NLvkgheC922fJHgdLA2O8WCV4HnY493K3+w1nXMPhDgBjGM v65C/L5KfBw+90YImaVQWeAWXUGhln9ObZlJ0XgNPGjQCsO7YbS9iBa8HK5fcksts4+yEFqK P4huIXElUujC1mt0G0I0oaGajboaNPMVrUXBux6jsXZ9I8IMUs9T9A106pViNtuYc6IRAUOr fRUHBjv0SkUSm5NLuMw47qSBGBvREkakXqw46yrVK3EKayLphGQR7u8sxchUeSi9xh4fZI8t LLGfmT+8PfHwzh9a/0rVO0ewp01X/11b/Lw2P3ZfQOXR8sDgra/sFr/hlO6UuG89E5abrs7N RZOnpdeqvzh3fJJlhccNmYP21ZVEhI8qCnaFXcid/FrzMGFlvUz1RDp8/lBijjrSdsQBEs3d NatDfC7uJzFH3O5HsWqRMZXVraU5I/sHiEMfb4YDAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-17_05:2019-11-15,2019-11-17 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 03:49:56 -0000 PiBTbyB5b3UgaGF2ZSBwb3RlbnRpYWxseSA2LTclIG9mIHRyYWZmaWMgZ29pbmcgdG8gYSBzaW5n bGUgcmVzb2x2ZXIgdGhhdCBtYXkgaGF2ZSBiZWVuIHNwcmVhZCBhY3Jvc3MgMTAwcyBvZiByZXNv bHZlcnMgcHJldmlvdXNseS4NCg0KW0pMXSBJIHRob3VnaHQgSSB3b3VsZCBzaGFyZSBzb21lIHBy ZWxpbWluYXJ5IHN0YXRzIGZyb20gb3VyIChDb21jYXN0KSBuZXR3b3JrIGluIHRoZSBVUyDigJMg aXJvbmljYWxseSB1c2luZyBzb21lIG5ldHdvcmsgZ2VhciBwcm9kdWNlZCBieSBOb2tpYSwga2lu ZCBzcG9uc29ycyBvZiBJRVRGLTEwNuKApiBXZeKAmXZlIGp1c3Qgc3RhcnRlZCBtZWFzdXJpbmcg dGhpbmdzIHNvIHdl4oCZcmUgbm90IDEwMCUgc3VyZSB0aGUgbWV0aG9kb2xvZ3kgaXMgY29ycmVj dCDigJMgc28gdGhlc2Ugc3RhdHMgbWF5IGJlIHRvdGFsbHkgd3JvbmcuIDstKSBBcyB3ZWxsLCBz aW5jZSB3ZeKAmXJlIGluIHRoZSBlYXJseSBkYXlzIG9mIGRlcGxveW1lbnQgb24gYSBnbG9iYWwg YmFzaXMgaXQgc2VlbXMgbGlrZWx5IHRoZXNlIHN0YXRzIHdpbGwgY2hhbmdlIHJhcGlkbHkuDQoN Ck9mIGFsbCB0aGUgRG9IIHRyYWZmaWMgaGVhZGluZyBvZmYtbmV0LCB3aGljaCBpcyB0aW55IHZv bHVtZSBjb21wYXJlZCB0byBEbzUzOg0KLSBDbG91ZGZsYXJlICYgR29vZ2xlIGNvbXByaXNlIDkw JSBvZiB0aGUgdHJhZmZpYyAoc2ltcGx5IHJlZmxlY3RpbmcgRmlyZWZveCAmIENocm9tZSBjbGll bnQgZGVwbG95bWVudHMgdGhhdCBkcml2ZSBhZG9wdGlvbiAtIG5vdCBzdXJwcmlzaW5nIHRvIG1l KQ0KLSBTb21lIG90aGVyIG9uZXM6IEFkR3VhcmQuY29tLCB0aWFyLmFwcCwgQ2xlYW5Ccm93c2lu ZywgUG93ZXJETlMsIE5leHRETlMsIFNlY3VyZUROUy5ldSwgUXVhZDksIE9wZW5ETlMsIEFwcGxp ZWRQcml2YWN5Lm5ldCwgRE5TV2FyZGVuDQoNCkphc29uDQoNCg0K From nobody Sun Nov 17 21:50:26 2019 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 CDA1E12086C for ; Sun, 17 Nov 2019 21:50:24 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-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 bk1eoBHpjpEu for ; Sun, 17 Nov 2019 21:50:21 -0800 (PST) Received: from mail-qv1-xf2c.google.com (mail-qv1-xf2c.google.com [IPv6:2607:f8b0:4864:20::f2c]) (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 AA123120043 for ; Sun, 17 Nov 2019 21:50:21 -0800 (PST) Received: by mail-qv1-xf2c.google.com with SMTP id cg2so6037536qvb.10 for ; Sun, 17 Nov 2019 21:50:21 -0800 (PST) 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=dZkMNTKBGnwOfyn43j+Pm3Tj18XuHlNBYJsf9EvlX0w=; b=MVlWA2rjAcXxvkW7NWmludShuG9qOz2iumX7QMw5kmCZfPiwDJ8n83WjW7MWl9hxhH gy4jSdoDEOqD4k70Bnsgx+5DZVI8lmL8AB/EU66HLUXQ9Yjr+BPEOuCR2CjzV2sU676V BuDPUzZ01q3RkniOvh7Gpl+Lk+XD5698xZpItaSyCQD6fhdFH3/SVOAU7XiFrxNTV0Za 2zrxWwgcNW7+dC4c3kmvxMC8XOyiq5NCX8/UAI/8SpHG+CFqVaXkPKztlUmAuRMS/I6W QHj1JXNOzxyIn0MYXIH2XSVXPnjf11qpH1QfHbVp+m2w2cpSNEgJmy4oeOhY1Uw4vdP6 Y1Ww== 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=dZkMNTKBGnwOfyn43j+Pm3Tj18XuHlNBYJsf9EvlX0w=; b=pup+Mfxk8pQ3yghFpu+QojOvmDRAIRQYjA+IcnUehtlvQYBcRf22oKMZWC3MtcSxXF i191Cu1xAojZunnxZpc7zy+XhAca0+ri+LfiBXt4gSLdh0MZdCVyLEqoGrGohqr6eVh3 GgRKQZbPvVdyrwfHH+XB9p5FXZ1A5i7H12djElq91XJAM8ClxGNE3BAXlgklZy94jUJG icoFtxWmmeF8dvpgPRJfK1CXgp5l/1IDtrKABA5cTAgFlv+2rSahEH25OviP0N0cEn3D Ty6j+mQcJtj9kuugB6Q0KmJ4BUbFklJVos4aT5P9mCTYr3WoWPvJ2v8Vh0jcLpnvo30P TyCw== X-Gm-Message-State: APjAAAUilbszy4UIDR3iIKmXcGRdib1iz2TzNmR36t8MRuBhdY2Ot3LS 1D3EHzm063ur28hKhuCgVNaVhw== X-Google-Smtp-Source: APXvYqzyoVMrRU6q9F9+KWHanMfYAqXUSh0hUlgLRB+OwSCVbFqWl29H8dfN/t8a8R/dD5UqXfj7kg== X-Received: by 2002:a0c:f114:: with SMTP id i20mr24495119qvl.167.1574056220558; Sun, 17 Nov 2019 21:50:20 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:452d:641f:4592:1697? ([2601:18b:300:36ee:452d:641f:4592:1697]) by smtp.gmail.com with ESMTPSA id x1sm8153332qke.125.2019.11.17.21.50.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 21:50:20 -0800 (PST) From: Ted Lemon Message-Id: <1E524D44-E988-4E95-8C71-30C5D5BF7225@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_6968630E-B796-46E6-8B41-01DD346186BA" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.1\)) Date: Mon, 18 Nov 2019 00:50:17 -0500 In-Reply-To: Cc: Ben Schwartz , ADD Mailing list To: Brian Dickson References: X-Mailer: Apple Mail (2.3608.40.2.2.1) Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 05:50:25 -0000 --Apple-Mail=_6968630E-B796-46E6-8B41-01DD346186BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 17, 2019, at 9:18 PM, Brian Dickson = wrote: > I think product (coffee/tea) comparisons aren't good analogies, I = think standards things like railway track gauge, or the NTSC upgrade to = support HDTV, or wireless frequency stuff, are better choices. > E.g. There is some good history on why subways and railroads use = different standards for track gauge, at least in some cities, IIRC. > A good use case example would be bridges or tunnels used for multiple = vehicle types, where being able to operate switches that apply to one = set of colinear tracks but not the other, would be particularly useful, = something only possible with different rail gauges running literally one = inside the other. No, the coffee/tea analogy is actually more right. If you have a rail = car with the wrong gauge, it won=E2=80=99t run on the track. DoH will = work fine with any port number. This is not an opinion=E2=80=94it=E2=80=99= s a fact. DoH is not useful for its intended purpose if any port other = than 443 is specified. Again, not opinion, fact. So when you say =E2=80=9Cuse a different port,=E2=80=9D you are saying = =E2=80=9Cdrink tea, not coffee.=E2=80=9D You are essentially saying = =E2=80=9Cdon=E2=80=99t use DoH.=E2=80=9D We=E2=80=99ve heard a couple of interesting actual issues raised: - Isn=E2=80=99t this a violation of law in some jurisdictions? - Doesn=E2=80=99t this tend to increase centralization? I think both of these are interesting questions. It=E2=80=99s not = clear to me how the IETF answers the first one. If it=E2=80=99s = against the law to use or publish DNS names in DoH in some jurisdiction, = then the user or publisher will have to behave accordingly, either = violating the law or following it according to the situation. We have = no control over that, and I can=E2=80=99t see how we can do anything one = way or another about that. When people talk about this as a problem, in = that the IETF is not respecting local law, that=E2=80=99s a category = error. IETF doesn=E2=80=99t write laws=E2=80=94it writes standards. = It=E2=80=99s completely out of scope for us to figure out how these = standards may or may not violate laws in some jurisdictions. The second question is a very good question, and I think something we = should really be thinking carefully about. I agree that this is an = important concern. It bothers me that if people think this is an = important concern, they are then going to =E2=80=9Clet=E2=80=99s change = the port number or disable DoH=E2=80=9D as a way around that problem. = Changing the port number or disabling DoH won=E2=80=99t solve that = problem. Changing the port number will definitely be ignored by = anybody who needs DoH for its intended purpose, so it=E2=80=99s a no-op. = Disabling DoH won=E2=80=99t happen if someone wants it, because it=E2=80= =99s up to them to decide, not up to us. So if this is a real problem that we want to solve, we should stop = talking about changing the port number. --Apple-Mail=_6968630E-B796-46E6-8B41-01DD346186BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 17, 2019, at 9:18 PM, Brian Dickson <brian.peter.dickson@gmail.com> wrote:
I think product (coffee/tea) = comparisons aren't good analogies, I think standards things like railway = track gauge, or the NTSC upgrade to support HDTV, or wireless frequency = stuff, are better choices.
E.g. There is some good history on = why subways and railroads use different standards for track gauge, at = least in some cities, IIRC.
 A good use case example would = be bridges or tunnels used for multiple vehicle types, where being able = to operate switches that apply to one set of colinear tracks but not the = other, would be particularly useful, something only possible with = different rail gauges running literally one inside the = other.

No, = the coffee/tea analogy is actually more right.  If you have a rail = car with the wrong gauge, it won=E2=80=99t run on the track.  DoH = will work fine with any port number.  This is not an = opinion=E2=80=94it=E2=80=99s a fact.   DoH is not useful for its = intended purpose if any port other than 443 is specified. Again, not = opinion, fact.

So when you say =E2=80=9Cuse a different port,=E2=80=9D you = are saying =E2=80=9Cdrink tea, not coffee.=E2=80=9D   You are = essentially saying =E2=80=9Cdon=E2=80=99t use DoH.=E2=80=9D

We=E2=80=99ve heard a = couple of interesting actual issues raised:

- Isn=E2=80=99t this a violation of law = in some jurisdictions?
- Doesn=E2=80=99t this tend = to increase centralization?

I think both of these are interesting questions.   = It=E2=80=99s not clear to me how the IETF answers the first one.   = If it=E2=80=99s against the law to use or publish DNS names in DoH in = some jurisdiction, then the user or publisher will have to behave = accordingly, either violating the law or following it according to the = situation.  We have no control over that, and I can=E2=80=99t see = how we can do anything one way or another about that.  When people = talk about this as a problem, in that the IETF is not respecting local = law, that=E2=80=99s a category error.  IETF doesn=E2=80=99t write = laws=E2=80=94it writes standards.   It=E2=80=99s completely out of = scope for us to figure out how these standards may or may not violate = laws in some jurisdictions.

The second question is a very good question, and I think = something we should really be thinking carefully about.  I agree = that this is an important concern.  It bothers me that if people = think this is an important concern, they are then going to =E2=80=9Clet=E2= =80=99s change the port number or disable DoH=E2=80=9D as a way around = that problem.  Changing the port number or disabling DoH won=E2=80=99= t solve that problem.   Changing the port number will definitely be = ignored by anybody who needs DoH for its intended purpose, so it=E2=80=99s= a no-op.   Disabling DoH won=E2=80=99t happen if someone wants it, = because it=E2=80=99s up to them to decide, not up to us.

So if this is a real = problem that we want to solve, we should stop talking about changing the = port number.

= --Apple-Mail=_6968630E-B796-46E6-8B41-01DD346186BA-- From nobody Sun Nov 17 21:51:46 2019 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 7956412086C for ; Sun, 17 Nov 2019 21:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isoc.org 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 1xtXmuOqd7Bl for ; Sun, 17 Nov 2019 21:51:42 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-eopbgr820084.outbound.protection.outlook.com [40.107.82.84]) (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 89BB3120043 for ; Sun, 17 Nov 2019 21:51:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hJoCl9wiuWO0VfXN+LmzC0/az7ohrvVo2Oeswr+eGYa6RtZS7XP0XHC98iCxhFELa+HuZgy0iyfrK24nWh9O4A7fmpf47oUeAE1aCbVMNfLju33moSz95PT+sBbG4HuhXVnTknze7HMOIyAJ4ekLeBVFnmUDwliOTG2TtpaMum8H7evhivOICMGYMN0qifgA3CD2RHd516ZbCFS5fbOQNE/XlUHBB3LoRMS6nH+kODZ4BRyvgeNSe2SEuwJdwHbiq5OOGXv0PjQ5gpFnkZuxDB2ZDfmtjHEGqhPpQAd4TEBo+J0rjtM0N3UvKJ/dvo95afnq9BEh6BbdwE3a5PBOBA== 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=gH4NuPiFE8/DW2jj/EpcoleQyiYAts5QE4Nv/ms8fuA=; b=Tn60bKsadEI+iyp9VfpGGJbjhoVY27THCGJJ5IBRvHRdmY81s7wlCmFMj5zWeyPKwsd3CK+6FxzkcErhfD6ivdHRh1jbuKOicPNkb4eHWL4vmXyrxAeXc/vjm8N75gDEnUMi3To8bUUQgOKIdTrB10ViwCBMDpZgjryaKNgixE9CDPV4Zod9ZhOWmjtcPrU9b5GHA18bNzfD3GRAc8a6+180V32cstdb2htNgDR2Ak/RbGkKu6Hpd4NOk4JjJCuqKf7SmM1ByLIz6AKQWRoxEft4NtTZQBsBdxpGX499tWgpt7tJCaF6ngqiPLUf0v4yS42YiJ3J3GXXerbkIRvrJA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=isoc.org; dmarc=pass action=none header.from=isoc.org; dkim=pass header.d=isoc.org; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isoc.org; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gH4NuPiFE8/DW2jj/EpcoleQyiYAts5QE4Nv/ms8fuA=; b=3TYte9XcbYwJ4S87ZFKT1AaOvscKjJoUKRD7oOuL+UiXw+xMm+TPNxjVNLERgQRwsKkrz3bcBz0H4+Q1TmkpAGB3tq5OMb7XJin4iia1etyPeUXsJC53OUVoHsfEylaze2HqnMexl7Zdl9nsdrGy6Q7xTTv/cLEN4aeEWVzZFxM= Received: from CH2PR06MB6743.namprd06.prod.outlook.com (20.180.9.24) by CH2PR06MB6455.namprd06.prod.outlook.com (20.180.12.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Mon, 18 Nov 2019 05:51:41 +0000 Received: from CH2PR06MB6743.namprd06.prod.outlook.com ([fe80::b4e1:d7cf:a544:2bd5]) by CH2PR06MB6743.namprd06.prod.outlook.com ([fe80::b4e1:d7cf:a544:2bd5%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 05:51:41 +0000 From: Joseph Lorenzo Hall To: Patrick McManus CC: Vittorio Bertola , ADD Mailing list Thread-Topic: [Add] Agenda and Revised Charter for the ABCD BoF Thread-Index: AQHVmcqxuyCwo+9dyUShchx02o1fo6ePRCSAgAA4U4CAAKAwgIAAEYEAgABGwQA= Date: Mon, 18 Nov 2019 05:51:40 +0000 Message-ID: <20D27080-7049-4D42-B020-6F574FD45140@isoc.org> References: <299277505.7138.1574037347987@appsuite-gw2.open-xchange.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=hall@isoc.org; x-originating-ip: [167.99.120.44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 53f68c83-42c0-4a03-6137-08d76beb6287 x-ms-traffictypediagnostic: CH2PR06MB6455: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(136003)(39840400004)(376002)(396003)(366004)(199004)(189003)(99286004)(316002)(6436002)(6506007)(26005)(186003)(7736002)(66066001)(53546011)(102836004)(76176011)(4326008)(71200400001)(71190400001)(5660300002)(14454004)(81156014)(81166006)(6486002)(8936002)(86362001)(478600001)(8676002)(6916009)(6246003)(6512007)(54896002)(236005)(2906002)(36756003)(91956017)(6116002)(3846002)(76116006)(229853002)(54906003)(66446008)(256004)(25786009)(64756008)(486006)(2616005)(33656002)(11346002)(476003)(66946007)(66476007)(66556008)(446003); DIR:OUT; SFP:1101; SCL:1; SRVR:CH2PR06MB6455; H:CH2PR06MB6743.namprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: isoc.org does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +YCRI4NFv5zQOYJoZT2TxhChub5iVM6L71jStqDNxoRYKuJwv/UAXQ3IchDRKqJuDQvAmJNRLjGSGKwQMFWMLTEiv8iQ824dTliWcWLGr4uz+qM+W5W2dwIokqkyD19+AT+Z1fUQWBg/RITNf3fyPwJrG2bHgRNSlpjT/5EhghzDqcd0w9kROsuOUVpFBECUNN2VSYlilNp9+TV44t5Gp+V3xGxPmCGX5LxjUVufIhJwhXYjhs5LphNm80XiK1sh0IW9742Asa9yo/bt5StiJnBvDE+6of0/u/cYuuAHYz6weQ8FxQRHpdJCUTf5fePkxCM8ScAMvvdxUOYfVXw9mIC3w0od0MNvBtIcaZlwxq/N65Ici74Ba14hLfMmFE5KmCqoQBRtbsnZolj7F1C6qDN4gZVk6KPmaXcs41w0lHxbHhgLlp7Ui+K9i9Qo6Q0E x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_20D2708070494D42B0206F574FD45140isocorg_" MIME-Version: 1.0 X-OriginatorOrg: isoc.org X-MS-Exchange-CrossTenant-Network-Message-Id: 53f68c83-42c0-4a03-6137-08d76beb6287 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 05:51:40.9749 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 89f84dfb-7285-4810-bc4d-8b9b5794554f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: XZhjSBcEk8IPUbnegK08vtnyBTEDRHEN/8ePhw7XNrpy+7vd4Thx+wZKaLGeruta X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR06MB6455 Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 05:51:45 -0000 --_000_20D2708070494D42B0206F574FD45140isocorg_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KEFmZmlsaWF0aW9uIGZvciBpZGVudGlmaWNhdGlvbiBwdXJwb3NlcyBvbmx5OyBJIGFtIG5vdCBz cGVha2luZyBvbiBiZWhhbGYgb2YgSVNPQywgYnV0IG9ubHkgZm9yIG15c2VsZikNCg0KT24gTm92 IDE4LCAyMDE5LCBhdCA5OjM4IEFNLCBQYXRyaWNrIE1jTWFudXMgPG1jbWFudXNAZHVja3Nvbmcu Y29tPG1haWx0bzptY21hbnVzQGR1Y2tzb25nLmNvbT4+IHdyb3RlOg0KDQoNCg0KT24gTW9uLCBO b3YgMTgsIDIwMTkgYXQgODozNSBBTSBWaXR0b3JpbyBCZXJ0b2xhIDx2aXR0b3Jpby5iZXJ0b2xh QG9wZW4teGNoYW5nZS5jb208bWFpbHRvOnZpdHRvcmlvLmJlcnRvbGFAb3Blbi14Y2hhbmdlLmNv bT4+IHdyb3RlOg0KDQooT2YgY291cnNlIG5vbi13ZWxsLWJlaGF2ZWQgcHJvdmlkZXJzIHdpbGwg YWx3YXlzIGRvIHdoYXRldmVyIHBvc3NpYmxlIHRvIGNhbW91ZmxhZ2UgdGhlaXIgdHJhZmZpYywg IFsuLl0NCg0KU2Vla2luZyBjb25maWRlbnRpYWwgMiBwYXJ0eSBjb21tdW5pY2F0aW9uIHdpdGgg SFRUUFMgaXMgbm90IG5vbi13ZWxsLWJlaGF2ZWQgLSBpdCBpcyBleGFjdGx5IHdoYXQgSFRUUFMg c2Vla3MgdG8gZG8uDQoNCkhlYXIsIGhlYXIuIEkgYW0gYmFmZmxlZCBhdCB0aW1lcyBhdCB3aHkg dGhpcyBiYXNpYyBwcm9wZXJ0eSBzZWVtcyB0byBiZSB1cCBmb3IgZGlzY3Vzc2lvbjsgb3Zlci1I VFRQUyBtZWFucyBleGFjdGx5IHRoYXQgKG9mIGNvdXJzZSwgcmVzb2x2ZXJzIGNhbiBzcGVjaWZ5 IG90aGVyIHBvcnRzIGJ1dCBIVFRQUyBkZWZhdWx0cyB0byB0aGUgb25lIHdlIGtub3cgYW5kIGxv dmUpLg0KDQpJIGFncmVlIHdpdGggUGF0cmljayB0aGF0IHRoaXMgaXMgb25lIG9mIGEgbnVtYmVy IG9mIGFzcGVjdHMgb2YgdGhlIG9uZ29pbmcgQUJDRC9BREQgZGlzY3Vzc2lvbiB0aGF0IHNlZW1z IHRvIGluZGljYXRlIHdlIHdvdWxkIGJlIOKAnHNwaW5uaW5nIHRoZSB3aGVlbHPigJ0gKG5vdCBn ZXR0aW5nIG11Y2ggcHJvZHVjdGl2ZSBkb25lKSBpbiBhIFdHLiBJIGxpa2Ugd2hlcmUgTGl2aW5n b29kIGlzIGdvaW5nIG9uIHRoaXMgdGhyZWFkIHdpdGggc3VnZ2VzdGVkIGNoYW5nZXMgdG8gdGhl IHByb3Bvc2VkIGNoYXJ0ZXIgdG8gbWFrZSB0aGUgd29yayBoZXJlIG1vcmUgY3Jpc3AsIGJ1dCBl dmVuIHRoYXQgc3RpbGwgc2VlbXMgbGlrZSBhIHZhc3Qgc2V0IG9mIHBvc3NpYmlsaXRpZXMgYW5k IHRoYXTigJlzIGEgbG90IG9mIHJvcGUgdG8gZ2V0IG91cnNlbHZlcyB3cmFwcGVkIGFyb3VuZCBp bi4NCg0KYmVzdCwgSm9lDQoNCg== --_000_20D2708070494D42B0206F574FD45140isocorg_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0 ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCihBZmZpbGlhdGlvbiBmb3IgaWRlbnRpZmljYXRp b24gcHVycG9zZXMgb25seTsgSSBhbSBub3Qgc3BlYWtpbmcgb24gYmVoYWxmIG9mIElTT0MsIGJ1 dCBvbmx5IGZvciBteXNlbGYpPGJyIGNsYXNzPSIiPg0KPGRpdj48YnIgY2xhc3M9IiI+DQo8Ymxv Y2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+T24gTm92IDE4LCAy MDE5LCBhdCA5OjM4IEFNLCBQYXRyaWNrIE1jTWFudXMgJmx0OzxhIGhyZWY9Im1haWx0bzptY21h bnVzQGR1Y2tzb25nLmNvbSIgY2xhc3M9IiI+bWNtYW51c0BkdWNrc29uZy5jb208L2E+Jmd0OyB3 cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2 IGNsYXNzPSIiPg0KPGRpdiBkaXI9Imx0ciIgY2xhc3M9IiI+DQo8ZGl2IGRpcj0ibHRyIiBjbGFz cz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9Imdt YWlsX3F1b3RlIj4NCjxkaXYgZGlyPSJsdHIiIGNsYXNzPSJnbWFpbF9hdHRyIj5PbiBNb24sIE5v diAxOCwgMjAxOSBhdCA4OjM1IEFNIFZpdHRvcmlvIEJlcnRvbGEgJmx0OzxhIGhyZWY9Im1haWx0 bzp2aXR0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20iIGNsYXNzPSIiPnZpdHRvcmlvLmJl cnRvbGFAb3Blbi14Y2hhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgY2xhc3M9ImdtYWlsX3F1b3RlIiBzdHlsZT0ibWFyZ2luOjBweCAwcHgg MHB4IDAuOGV4O2JvcmRlci1sZWZ0OjFweCBzb2xpZCByZ2IoMjA0LDIwNCwyMDQpO3BhZGRpbmct bGVmdDoxZXgiPg0KPHUgY2xhc3M9IiI+PC91Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+KE9mIGNvdXJzZSBub24td2VsbC1iZWhhdmVkIHByb3ZpZGVycyB3 aWxsIGFsd2F5cyBkbyB3aGF0ZXZlciBwb3NzaWJsZSB0byBjYW1vdWZsYWdlIHRoZWlyIHRyYWZm aWMsJm5ic3A7IFsuLl08L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+U2Vl a2luZyBjb25maWRlbnRpYWwgMiBwYXJ0eSBjb21tdW5pY2F0aW9uIHdpdGggSFRUUFMgaXMgbm90 IG5vbi13ZWxsLWJlaGF2ZWQgLSBpdCBpcyBleGFjdGx5IHdoYXQgSFRUUFMgc2Vla3MgdG8gZG8u PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9 IiI+DQo8L2Rpdj4NCjxkaXY+SGVhciwgaGVhci4gSSBhbSBiYWZmbGVkIGF0IHRpbWVzIGF0IHdo eSB0aGlzIGJhc2ljIHByb3BlcnR5IHNlZW1zIHRvIGJlIHVwIGZvciBkaXNjdXNzaW9uOyBvdmVy LUhUVFBTIG1lYW5zIGV4YWN0bHkgdGhhdCAob2YgY291cnNlLCByZXNvbHZlcnMgY2FuIHNwZWNp Znkgb3RoZXIgcG9ydHMgYnV0IEhUVFBTIGRlZmF1bHRzIHRvIHRoZSBvbmUgd2Uga25vdyBhbmQg bG92ZSkuPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdj5JIGFncmVlIHdp dGggUGF0cmljayB0aGF0IHRoaXMgaXMgb25lIG9mIGEgbnVtYmVyIG9mIGFzcGVjdHMgb2YgdGhl IG9uZ29pbmcgQUJDRC9BREQgZGlzY3Vzc2lvbiB0aGF0IHNlZW1zIHRvIGluZGljYXRlIHdlIHdv dWxkIGJlIOKAnHNwaW5uaW5nIHRoZSB3aGVlbHPigJ0gKG5vdCBnZXR0aW5nIG11Y2ggcHJvZHVj dGl2ZSBkb25lKSBpbiBhIFdHLiBJIGxpa2Ugd2hlcmUgTGl2aW5nb29kIGlzIGdvaW5nIG9uIHRo aXMgdGhyZWFkIHdpdGggc3VnZ2VzdGVkDQogY2hhbmdlcyB0byB0aGUgcHJvcG9zZWQgY2hhcnRl ciB0byBtYWtlIHRoZSB3b3JrIGhlcmUgbW9yZSBjcmlzcCwgYnV0IGV2ZW4gdGhhdCBzdGlsbCBz ZWVtcyBsaWtlIGEgdmFzdCBzZXQgb2YgcG9zc2liaWxpdGllcyBhbmQgdGhhdOKAmXMgYSBsb3Qg b2Ygcm9wZSB0byBnZXQgb3Vyc2VsdmVzIHdyYXBwZWQgYXJvdW5kIGluLjwvZGl2Pg0KPGRpdj48 YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+YmVzdCwgSm9lPC9kaXY+DQo8YnIgY2xhc3M9IiI+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_20D2708070494D42B0206F574FD45140isocorg_-- From nobody Sun Nov 17 21:54:56 2019 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 A041412090B for ; Sun, 17 Nov 2019 21:54:53 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 KLuzYpmXHqDD for ; Sun, 17 Nov 2019 21:54:52 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 1DCB21208F2 for ; Sun, 17 Nov 2019 21:54:52 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id j5so17511114qtn.10 for ; Sun, 17 Nov 2019 21:54:52 -0800 (PST) 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=SNkd6WVTj4rIzpS1KNoCrp4GkBd4ONkhMp3XKhhbRVo=; b=fws0ic2y5G9kaZ+KAZxjAaP6JzLJf5/PZ+Us3eGeZo0jjyaKV4RxJcHJ4e239cwxLw Cd+8KFHnZR8i83uj4zsVSGJmVOwpCTMGsDJ81P4L0I1WXLamdBm+mcrq11LM7ss6/yxb sh5Kd/oJVPOcKfYWtisLqZl7kk6R4pJ/RNpog5CbSGQ09ZgmWcKmzjVBPCRRfKFjPv1W jOHsJUdrBbfL+jSIuLJGVGE9+reQCzhAtNFCifAcyYIKWYeJOOpTnieto9zk2iedVKdw RThfdBEnlOa89BKkuN1qDLIe4TT9sKV168mVpIFbgvYVXWef9MwZiwBkaFgi6gdxC0Cc hRaQ== 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=SNkd6WVTj4rIzpS1KNoCrp4GkBd4ONkhMp3XKhhbRVo=; b=RBzc7ljpRxcfn+9GkzywehNx7EeGt36KDtiNVXxg5qSGX3SzXDx/6KdVgxk+EJ3tUi uaFBKeuhKhbVwloaZy7SbE0ghy6DMNQD9CkhBfR+YxLteVbvBKxvbHntc4drMlck2VGb khYsh9X/gitgTb94JJDmMY/H62cbXpcC58UrKFxszS7g4OIPppGUMNJqpIl9JkqJgVuO 840gsmPqim/mc6MNdkD+ZQ3nhm8j1Vt7tSkavtc8BYrBLtnfTuBjyxpMdw0byzB4ZFcw 3NKbJb/XG+5UIVcpeymKr/RXF0WNFqvRFV2pNm32htXFefbWPx1pW3bNZfPxp7+2S9pe zpFA== X-Gm-Message-State: APjAAAVlhYqkjM8Y4jgug0l2dT6QR9enkye9aYETUoMiKvQqVRSFsito 6QTKdIAdSEc6PGdk3EEH94UlCg== X-Google-Smtp-Source: APXvYqxpd4V0X2DwyDuOauaZoXVMEhB1NvXDmBjzvdtQtjT+aYZtAwEQ0bmYwdOlBLmDEKHbzsOQOQ== X-Received: by 2002:aed:3f63:: with SMTP id q32mr26582969qtf.340.1574056491178; Sun, 17 Nov 2019 21:54:51 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:452d:641f:4592:1697? ([2601:18b:300:36ee:452d:641f:4592:1697]) by smtp.gmail.com with ESMTPSA id p85sm8006008qke.79.2019.11.17.21.54.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 21:54:50 -0800 (PST) From: Ted Lemon Message-Id: <46A8E055-C14B-4927-B348-1B4C44F417DF@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_76BB853B-B300-4608-AE32-A53D448490AC" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.1\)) Date: Mon, 18 Nov 2019 00:54:49 -0500 In-Reply-To: Cc: ADD Mailing list To: "Livingood, Jason" References: <254AEFB0-F930-466B-8BB6-707D5CE72657@fl1ger.de> X-Mailer: Apple Mail (2.3608.40.2.2.1) Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 05:54:55 -0000 --Apple-Mail=_76BB853B-B300-4608-AE32-A53D448490AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 17, 2019, at 9:57 PM, Livingood, Jason = wrote: > - Potential use of alternative application port numbers in some = controlled environments (e.g. managed enterprise environments), = including the pros/cons and implications of security downgrade and/or = detectability in these environments This is presuming a solution. Can we change it to just talk about the = problem? - The problem of detecting and preventing the use of DoH in managed = environments where the network operator needs control of DNS queries. > - Resilience and fault-tolerance (e.g. single points of failure modes = from encrypted DNS to Do53 or from a primary encrypted DNS resolvers to = secondary or tertiary resolvers =E2=80=93 or something like that) I have no idea what this means. Is this about dealing with the = possibility that DoH will be blocked by the network? Or that the DoH = server will be unreachable for other reasons? --Apple-Mail=_76BB853B-B300-4608-AE32-A53D448490AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 17, 2019, at 9:57 PM, Livingood, Jason <Jason_Livingood@comcast.com> wrote:
- Potential use of alternative application port numbers in = some controlled environments (e.g. managed enterprise environments), = including the pros/cons and implications of security downgrade and/or = detectability in these environments

This is presuming a solution.  Can we = change it to just talk about the problem?

- The problem of detecting and = preventing the use of DoH in managed environments where the network = operator needs control of DNS queries.

- Resilience and fault-tolerance (e.g. single points of failure modes from encrypted DNS to Do53 or = from a primary encrypted DNS resolvers to secondary or tertiary = resolvers =E2=80=93 or something like that)

I = have no idea what this means.   Is this about dealing with the = possibility that DoH will be blocked by the network?  Or that the = DoH server will be unreachable for other reasons?

= --Apple-Mail=_76BB853B-B300-4608-AE32-A53D448490AC-- From nobody Sun Nov 17 22:00:01 2019 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 1C0CA12086C for ; Sun, 17 Nov 2019 22:00:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IgjhinNg1Wkd for ; Sun, 17 Nov 2019 21:59:58 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 72F57120106 for ; Sun, 17 Nov 2019 21:59:58 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id 1so17383701iou.4 for ; Sun, 17 Nov 2019 21:59:58 -0800 (PST) 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=EryRThPvfeLw72zBmYmKu24vA/EXZDW0dusfh6+VhdE=; b=Gv4j73KkWdNv5gOq4jC69PMLKqvwOw5T/9lNXPlfCDBt6DI0t5nHqNYeOU7wfANEOC eZ4yYiZ2BmJPHFpXVT2r+0ysZjEh5yqU5F06i8Zkfgt35LjeAW1qICU6IHk7UMbldvUP hRQhnTYfIDlSSYKpE/FFfJ0w7gOazY1r+fR7jOCbHT4p+Xt7FkhSoiIFrWOdtvHCcISE JoEBXb+C/D0zNkfFXg94z7CINQkb+n35MDsnRQjJHiGgZbHiRadw+eAtQHQKPzVKeHx/ 77kT1FxIVvPZ+jWRYq65BuAx52ViI8ZKhlqrVcFmDmpdtKrplP41rOI5W0+yB5TtD9gy 0LTg== 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=EryRThPvfeLw72zBmYmKu24vA/EXZDW0dusfh6+VhdE=; b=o4mR42kiBZNmsdY4QBd7a+JpbbXp1bIEr2I6cJcRJf2NKvDQfjFyXRIi21kawe2PHo MOM/+UaaAWZfZjU6NHGvRUk9vY80Y4sC1y5ZTVkb0D56qBMDWvaxqEORYUnoTqT5mm4g TMqPzKvp8z71rvfIl1XwfFPpWZjhOG1YzBLqFkxeHtBeYpUTS84iJFTdNgH/7DB7Qljs xICw9OuINlRu1jr+ukEadfvCV5n69yh3e9ETJWSqORsqQRyRRkFz8vbzbQCaNM38hdjb 0gT587ZN2SKeXE40x8J2wbx6KUN58f/D47R8v2Lu0wOlPGV/AuXmPyd6UBvTkde1flbM Gpew== X-Gm-Message-State: APjAAAVoGe0mh3HR9AZ0pQ61mZbR/kWRILOqBuS3h2bw5hqfRPZtiZil JXjdGLbxELOGIs7ESuEGefdbbsiCTEcBFDwSn20= X-Google-Smtp-Source: APXvYqxpm6o5z6I9DwE6AEJms719ixVcct7RR1zFiFxtQIKal5dAF9zjsO8Q6dLiOhtTYbsmhHDsoF2+qhA106/cXa0= X-Received: by 2002:a02:3f60:: with SMTP id c32mr11609007jaf.30.1574056797369; Sun, 17 Nov 2019 21:59:57 -0800 (PST) MIME-Version: 1.0 References: <299277505.7138.1574037347987@appsuite-gw2.open-xchange.com> <20D27080-7049-4D42-B020-6F574FD45140@isoc.org> In-Reply-To: <20D27080-7049-4D42-B020-6F574FD45140@isoc.org> From: Rob Sayre Date: Sun, 17 Nov 2019 21:59:45 -0800 Message-ID: To: Joseph Lorenzo Hall Cc: Patrick McManus , Vittorio Bertola , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000437c4a059798a817" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 06:00:00 -0000 --000000000000437c4a059798a817 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Nov 17, 2019 at 9:51 PM Joseph Lorenzo Hall wrote: > > I agree with Patrick that this is one of a number of aspects of the > ongoing ABCD/ADD discussion that seems to indicate we would be =E2=80=9Cs= pinning > the wheels=E2=80=9D (not getting much productive done) in a WG. I like wh= ere > Livingood is going on this thread with suggested changes to the proposed > charter to make the work here more crisp > I agree that some of Livingood's additions are a little better. But his edits seem to remove out-of-bounds topics, which seems misguided. I also think that a lot of the proposals basically amount to "you have to use my resolver!!". Those are misguided, and ultimately undermine the IETF itself. thanks, Rob --000000000000437c4a059798a817 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Nov 17, 2019 at 9:51 PM Joseph Lo= renzo Hall <hall@isoc.org> wrote= :

I agree with Patrick that this is one of a number of aspects of the on= going ABCD/ADD discussion that seems to indicate we would be =E2=80=9Cspinn= ing the wheels=E2=80=9D (not getting much productive done) in a WG. I like = where Livingood is going on this thread with suggested changes to the proposed charter to make the work here more crisp

I agree that some of Livingood's add= itions are a little better. But his edits seem to remove out-of-bounds topi= cs, which seems misguided.

I also think that a= lot of the proposals basically amount to "you have to use my resolver= !!". Those are misguided, and ultimately undermine the IETF itself.=C2= =A0

thanks,
Rob

--000000000000437c4a059798a817-- From nobody Sun Nov 17 22:08:33 2019 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 762B8120887 for ; Sun, 17 Nov 2019 22:08:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.498 X-Spam-Level: X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K4ebqSanFrF6 for ; Sun, 17 Nov 2019 22:08:30 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5842120106 for ; Sun, 17 Nov 2019 22:08:30 -0800 (PST) Received: from dhcp-8a04.meeting.ietf.org (dhcp-8a04.meeting.ietf.org [31.133.138.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id A08692421173; Mon, 18 Nov 2019 06:08:28 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: <46A8E055-C14B-4927-B348-1B4C44F417DF@fugue.com> Date: Mon, 18 Nov 2019 06:08:26 +0000 Cc: ADD Mailing list Content-Transfer-Encoding: quoted-printable Message-Id: References: <254AEFB0-F930-466B-8BB6-707D5CE72657@fl1ger.de> <46A8E055-C14B-4927-B348-1B4C44F417DF@fugue.com> To: Ted Lemon X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 06:08:31 -0000 > On 18 Nov 2019, at 05:54, Ted Lemon wrote: >=20 >>=20 >> - Resilience and fault-tolerance (e.g. single points of failure modes = from encrypted DNS to Do53 or from a primary encrypted DNS resolvers to = secondary or tertiary resolvers =E2=80=93 or something like that) >=20 > I have no idea what this means. Is this about dealing with the = possibility that DoH will be blocked by the network? Or that the DoH = server will be unreachable for other reasons? I thought this meant end client behaviour/policy. ie If/when DoH fails = (for some definition of fail), try DoT then Do53. Or give up. Or try = Do53, then DoT. Or some other combination of these fallbacks. How = could/should resolvers (for some definition of resolver) be configured = and/or provisioned to reflect local policy or end user preference about = these possibilities? From nobody Sun Nov 17 22:12:50 2019 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 AB7041208A1 for ; Sun, 17 Nov 2019 22:12:48 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 M3yG47j5V0Hd for ; Sun, 17 Nov 2019 22:12:47 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 2212412089E for ; Sun, 17 Nov 2019 22:12:47 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id t20so18968284qtn.9 for ; Sun, 17 Nov 2019 22:12:47 -0800 (PST) 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=w32pVxDcxFU+MaBrj3HNdQ/Ie6fl4xnEGatBQoaJRhI=; b=I7Ym58RQFYSxeZqSuLuyupW34hEWOemQzb2MEcZNRjIEGb4TXx8CZEmTtQ6M4rtDZZ PuU3ayeQIyYyTq5a8BrCyMXgGAh6/piLishgP/MqcpmYj0pR5rwPh1FNiaQB7qXTeAPc dRPXU4WmVk6YfzDGljUnUe20wBTNziA42dptPdjZPy/u8APpfMdcFPxc4iERD7zKunwy CX9F0H9g3PR4tj94PtMORfWpbMNBQSn4SR/DAnr4OPYO1I/F+c6hpUvJadv2OgtR4uek A4F0RlMfPor7UxhkuyytEPE2PsxVyslLENVy0RflwAVbuwMZpO/DN13iNTn0hviOzSB9 UTJw== 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=w32pVxDcxFU+MaBrj3HNdQ/Ie6fl4xnEGatBQoaJRhI=; b=Lmd4ppVnxo7znoxK7USSaApC8dr7EiZONPybpXxQKQJVM2CAXvE2mCMClYZpnXP8Em KdMWNdZtZ0ZgCnwdbPtlhffjgfuftq/tbDIrQkf6GddC4xSK1SL0mUQ8hgufdVFCX0xe QAxRQ2C3T0Ebw2RS66L+CHkvnYRPp1iCad7lTZ35+tt9Fv5PGP4rmsRgK/ZerhA0bBLY UmNKokzFiyEk+V8fUeklKrus7+wAQkbrnOJSoqg9MlB27nts7WdAwy+dTCY+j1g6Lpn5 8/04occWOD8y2bRW2O7d9jFtphd4KLjKKIAYQmusTkeJI4qpc7KKNiVlYZ2xoP6J3njw eP6g== X-Gm-Message-State: APjAAAUXqVgeh/BYDE8yYqpHYGP7VUI8wgRdjZFnwbvvQNPD+PZ0W99Y cBI21+soFeiV/yFgeQiZacJVllIbTdj6sQ== X-Google-Smtp-Source: APXvYqx2MqJvjfZ5NauUf0n6XFPhDcW4WAWbkM7qZDxXoaAnO8U17xLh/70a5UYv1l2QYGAIgHeURQ== X-Received: by 2002:ac8:47c9:: with SMTP id d9mr25887502qtr.163.1574057566201; Sun, 17 Nov 2019 22:12:46 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:452d:641f:4592:1697? ([2601:18b:300:36ee:452d:641f:4592:1697]) by smtp.gmail.com with ESMTPSA id i10sm9001490qtj.19.2019.11.17.22.12.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 17 Nov 2019 22:12:45 -0800 (PST) From: Ted Lemon Message-Id: <0178A644-1D5E-44D7-AB27-D3F8BFB5D3C3@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5689E1D1-2EDA-4D2A-B09C-3EE617DE5F93" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.1\)) Date: Mon, 18 Nov 2019 01:12:43 -0500 In-Reply-To: Cc: ADD Mailing list To: Jim Reid References: <254AEFB0-F930-466B-8BB6-707D5CE72657@fl1ger.de> <46A8E055-C14B-4927-B348-1B4C44F417DF@fugue.com> X-Mailer: Apple Mail (2.3608.40.2.2.1) Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 06:12:49 -0000 --Apple-Mail=_5689E1D1-2EDA-4D2A-B09C-3EE617DE5F93 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 18, 2019, at 1:08 AM, Jim Reid wrote: > I thought this meant end client behaviour/policy. ie If/when DoH fails = (for some definition of fail), try DoT then Do53. Or give up. Or try = Do53, then DoT. Or some other combination of these fallbacks. How = could/should resolvers (for some definition of resolver) be configured = and/or provisioned to reflect local policy or end user preference about = these possibilities? It=E2=80=99s not clear to me that we need to do this, but I think it = would be okay to have a charter item about researching it. The reason I = say we may not need to do it is that it=E2=80=99s not clear to me that = there=E2=80=99s one answer we could dictate. I suspect that it is more = of a security policy decision. So what might be useful is an = exploration of what policies might make sense. However, my intuition = is that the actual work on this topic will be done by vendors, not in = the IETF, because the only way to really get clarity on the correct = behavior is to have users winning or losing as a result of this. So = unless the vendors want to discuss this in the IETF, I think this is = just going to create confusion. If a WG in the IETF spends a lot of = time writing documents about this without input from the vendors, the = best case scenario is that the documents will coincidentally reflect = what the vendors learn as they deploy this. --Apple-Mail=_5689E1D1-2EDA-4D2A-B09C-3EE617DE5F93 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 18, 2019, at 1:08 AM, Jim Reid <jim@rfc1035.com> wrote:
I thought this meant end client behaviour/policy. ie If/when = DoH fails (for some definition of fail), try DoT then Do53. Or give up. = Or try Do53, then DoT. Or some other combination of these fallbacks. How = could/should resolvers (for some definition of resolver) be configured = and/or provisioned to reflect local policy or end user preference about = these possibilities?

It=E2=80=99s not clear to me that we need to do this, but I = think it would be okay to have a charter item about researching it. =  The reason I say we may not need to do it is that it=E2=80=99s not = clear to me that there=E2=80=99s one answer we could dictate.   I = suspect that it is more of a security policy decision.  So what = might be useful is an exploration of what policies might make sense. =   However, my intuition is that the actual work on this topic will = be done by vendors, not in the IETF, because the only way to really get = clarity on the correct behavior is to have users winning or losing as a = result of this.  So unless the vendors want to= discuss this in the IETF, I think this is just going to create = confusion.   If a WG in the IETF spends a lot of time writing = documents about this without input from the vendors, the best case = scenario is that the documents will coincidentally reflect what the = vendors learn as they deploy this.

= --Apple-Mail=_5689E1D1-2EDA-4D2A-B09C-3EE617DE5F93-- From nobody Sun Nov 17 22:17:26 2019 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 B04761208A4 for ; Sun, 17 Nov 2019 22:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 vGvia3sB6qTM for ; Sun, 17 Nov 2019 22:17:23 -0800 (PST) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 3F6CF1208A1 for ; Sun, 17 Nov 2019 22:17:23 -0800 (PST) Received: by mail-ua1-x92d.google.com with SMTP id i31so4850033uae.13 for ; Sun, 17 Nov 2019 22:17:23 -0800 (PST) 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=po8FQH+Fh2YjROKLpGEG+av8kCDrQ/GigW2LAu8rOWM=; b=PhOw/+Tn7PmY1LwsgZ7NqVnlJtznisFpIrUGEmydPsxLvAQQzzl7i60d0aw8iUHel2 Oq9xXHCmBJTMJqzf7I0XoUD3vI4QaNva2/rxcu+CmQjc4458f9j0K6WoQBEb49BKDGwg s9WO+S7b1M2KtMchZDxeYlOnqWS2xUb9xPCOa6Va9sPrBgltMsH/G6FloeV3WRx8LbNe BWDmLkwTy/uDModzIi4AgMap62jCUihXtN21TdaRAZiXHLtSfHRbPTuwEyjdJKxIjlHA ab3kfTyDaNr36TLzs6rDKWxxHM7PAPOcWEPcK/a0pUnFzTzDZhp2iiuSmuJ5F3OmJGXj AjnA== 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=po8FQH+Fh2YjROKLpGEG+av8kCDrQ/GigW2LAu8rOWM=; b=UN3PBf1swgLHlgztlzY/VA0MSWHAXJLjYJ1rdYU38oTBwboNElQV9HsvQcxqyOz5Z4 tLau70D6kJ0J6JJkMJGjISJHKMVdvsuhrQDVwy+qnvgBrlwRzxu9QxiMurGz4l4YeR5l bVBf27Vz228K9oVxu7mDKdD9T2zA2oFDx9NDbwIW/72Wv8WmPQAjT9LrkVAhE56BH/FN NxF866DqyiVmKQRrW0i/+lyxg00rdBiCm8Dj2bOYHzAjt++eAqCmfAv6dF/0TCXHOYh6 iEXiMAsjHHedBpQap9cHT+0j+ZQDbW1wnAWsM5YVEy5EoI8Yk60/hgzIedCQj7EUAz8v 3gtQ== X-Gm-Message-State: APjAAAWjWpBiqgGFr5Na6tmhZo3AhhfXtSWsqnLkxX+sqA6Tz8XTcTBN /IXEw3pnSQ77jJZR1QblwslK14KPUOwC1C/PUHs0ZMAMH/tTTg== X-Google-Smtp-Source: APXvYqzKD11k68/jzWypEs03jCj47lsJ+4/Dnj3MkxkqLNb1jJwPFHYqy0RFqOpF2wFJ9vomC414j6mUhf1aaxmKqY4= X-Received: by 2002:ab0:5ea9:: with SMTP id y41mr15649005uag.114.1574057841035; Sun, 17 Nov 2019 22:17:21 -0800 (PST) MIME-Version: 1.0 References: <1E524D44-E988-4E95-8C71-30C5D5BF7225@fugue.com> In-Reply-To: <1E524D44-E988-4E95-8C71-30C5D5BF7225@fugue.com> From: Brian Dickson Date: Mon, 18 Nov 2019 14:17:04 +0800 Message-ID: To: Ted Lemon Cc: Ben Schwartz , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000788e06059798e680" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 06:17:25 -0000 --000000000000788e06059798e680 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2019 at 1:50 PM Ted Lemon wrote: > On Nov 17, 2019, at 9:18 PM, Brian Dickson > wrote: > > I think product (coffee/tea) comparisons aren't good analogies, I think > standards things like railway track gauge, or the NTSC upgrade to support > HDTV, or wireless frequency stuff, are better choices. > E.g. There is some good history on why subways and railroads use differen= t > standards for track gauge, at least in some cities, IIRC. > A good use case example would be bridges or tunnels used for multiple > vehicle types, where being able to operate switches that apply to one set > of colinear tracks but not the other, would be particularly useful, > something only possible with different rail gauges running literally one > inside the other. > > > I'm going to ask follow-up questions here, because I don't think I understand what you're meaning, and want to understand. (The hallmark of useful discussion is the listening and comprehension, rather than the talking part.) > No, the coffee/tea analogy is actually more right. > > If you have a rail car with the wrong gauge, it won=E2=80=99t run on the = track. > So, what I'm talking about in the analogy, is two tracks running in parallel, occupying what amounts to a single "right of way", or passageway. Only one of the two tracks can be used at a time. For demonstration purposes, suppose one track is 44.3 inches wide, and the other track is 65.3 inches wide (call them https, and newdoh). I'm proposing that both the client and server switch to port NEW_VALUE (in the example that would correspond to 653, for identification purposes only)= . The analogy is only useful when both the client and server use the new value, i.e. the rail car also has the new gauge. DoH rail cars would have 65.3 gauge. HTTPS rail cars would have 44.3 gauge. The two ends of the passageway would have switches for the 65.3 gauge only, to divert it (analogous to being able to identify and/or block on the basis of port -- or to not block it, if the network policy were permissive.) > DoH will work fine with any port number. > This is not an opinion=E2=80=94it=E2=80=99s a fact. > I believe you are conflating the DoH Template URI, and the content of the template. I am proposing a new Template port number, irrespective of what is in the template. (I.e. that post-template communications is not port-dependent, as that is all specified in the template.) I think there is no disagreement on whether the DoH traffic after being configured by the template is port-neutral. The issue is the first port, which is necessarily required for the DoH configuration step (which may still require a bootstrap via DNS to find the IP address of the server name at which the Template is served.) > DoH is not useful for its intended purpose if any port other than 443 is > specified. Again, not opinion, fact. > I am unsure what fact you are implying, as the "intended purpose" is pretty vague. If you mean "privacy-enhanced DNS using TLS encryption", we disagree, as the only issue is whether the TLS connection can be established. If it is established, privacy is assured by TLS. If you mean the stuff about Additionally, the use of the HTTPS default port 443 and the ability to mix DoH traffic with other HTTPS traffic on the same connection can deter unprivileged on-path devices from interfering with DNS operations and make DNS traffic analysis more difficult. ... then that is a "can", not a "will", and is entirely dependent on whether the resolver operator has any HTTPS content other than DNS. If it does not, then the port number is moot, since the preconditions are not met. This whole discussion that I started, is premised entirely on facts, regarding DoH public resolvers not doing any other HTTPS on the IP addresses serving DoH. This, IMHO, is what makes the port number question germane, and ripe for discussion. I see no solid reason to insist on the Template being served on port 443. While I'd prefer the default port used by the resulting templates (and thus by the DoH TLS connections) be different, I haven't given it enough thought to figure out if the port number INSIDE the template is as important. Maybe this is where we are talking past each other, and if so, that is probably my fault, and I apologize. So, to restate: I'm suggesting changing the standardized port FOR THE TEMPLATE RETRIEVAL, without speaking to the in-template URI port number. > > So when you say =E2=80=9Cuse a different port,=E2=80=9D you are saying = =E2=80=9Cdrink tea, not > coffee.=E2=80=9D You are essentially saying =E2=80=9Cdon=E2=80=99t use = DoH.=E2=80=9D > No, I really am saying, different rail gauge, and pick the hot beverage that suits you. Brian --000000000000788e06059798e680 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 18, 2019 at 1:50 PM Ted L= emon <mellon@fugue.com> wrote= :
On Nov 17, 2019, at 9:18 PM, Brian Dickson <= brian.pe= ter.dickson@gmail.com> wrote:
I think product (coffee/tea) comparisons aren't good = analogies, I think standards things like railway track gauge, or the NTSC u= pgrade to support HDTV, or wireless frequency stuff, are better choices.
E.g. There is some good history on why subways and = railroads use different standards for track gauge, at least in some cities,= IIRC.
=C2=A0A good use case example would be bri= dges or tunnels used for multiple vehicle types, where being able to operat= e switches that apply to one set of colinear tracks but not the other, woul= d be particularly useful, something only possible with different rail gauge= s running literally one inside the other.

I'm going to ask follow-up ques= tions here, because I don't think I understand what you're meaning,= and want to understand.
(The hallmark of useful discussion is th= e listening and comprehension, rather than the talking part.)
=C2= =A0
No, the coffee/tea analogy is actually more = right. =C2=A0
=C2=A0
If you have a rail car with the wrong gauge, it won=E2=80=99t run on the = track. =C2=A0

So, what I'm = talking about in the analogy, is two tracks running in parallel, occupying = what amounts to a single "right of way", or passageway. Only one = of the two tracks can be used at a time.
For demonstration purpos= es, suppose one track is 44.3 inches wide, and the other track is 65.3 inch= es wide (call them https, and newdoh).

I'm pro= posing that both the client and server switch to port NEW_VALUE (in the exa= mple that would correspond to 653, for identification purposes only).
=

The analogy is only useful when both the client and ser= ver use the new value, i.e. the rail car also has the new gauge.
=
DoH rail cars would have 65.3 gauge. HTTPS rail cars would h= ave 44.3 gauge.

The two ends of the passageway wou= ld have switches for the 65.3 gauge only, to divert it (analogous to being = able to identify and/or block on the basis of port -- or to not block it, i= f the network policy were permissive.)=C2=A0
=C2=A0
DoH will work fine with any port number.=C2=A0=C2=A0
This is not an opinion=E2=80=94it=E2= =80=99s a fact. =C2=A0

I believ= e you are conflating the DoH Template URI, and the content of the template.=
I am proposing a new Template port number, irrespective of what = is in the template.
(I.e. that post-template communications is no= t port-dependent, as that is all specified in the template.)
I th= ink there is no disagreement on whether the DoH traffic after being configu= red by the template is port-neutral.

The issue is = the first port, which is necessarily required for the DoH configuration ste= p (which may still require a bootstrap via DNS to find the IP address of th= e server name at which the Template is served.)=C2=A0
=C2=A0
DoH is not useful for its intended purpose if any po= rt other than 443 is specified. Again, not opinion, fact.

I am unsure what fact you are implying, as the &= quot;intended purpose" is pretty vague.

If yo= u mean "privacy-enhanced DNS using TLS encryption", we disagree, = as the only issue is whether the TLS connection can be established. If it i= s established, privacy is assured by TLS.

If you m= ean the stuff about
Additionally, the use of the HTTPS default por=
t 443 and the ability
   to mix DoH =
traffic with other HTTPS traffic on the same connection
   can deter unprivileged on-path devices from interfering with DNS
   operations and make DNS traffic analysis more difficult.

... then that=
 is a "can", not a "will", and is entirely dependent on=
 whether the resolver operator has any HTTPS content other than DNS.=


If it does not, then the port nu=
mber is moot, since the preconditions are not met.
=

This whole discussion that I started, is premise=
d entirely on facts, regarding DoH public resolvers not doing any other HTT=
PS on the IP addresses serving DoH.

= 
This, IMHO, is what makes the port number question germane, and r=
ipe for discussion. I see no solid reason to insist on the Template being s=
erved on port 443.

While I=
'd prefer the default port used by the resulting templates (and thus by=
 the DoH TLS connections) be different, I haven't given it enough thoug=
ht to figure out if the port number INSIDE the template is as important.

Maybe this is where we are talking past each other, and if so, that i=
s probably my fault, and I apologize.
=

So, to restate: I'm suggesting changing the =
standardized port FOR THE TEMPLATE RETRIEVAL, without speaking to the in-te=
mplate URI port number.
=C2=A0

So when you say =E2=80=9Cuse a different port,=E2=80= =9D you are saying =E2=80=9Cdrink tea, not coffee.=E2=80=9D =C2=A0 You are = essentially saying =E2=80=9Cdon=E2=80=99t use DoH.=E2=80=9D

No, I really am saying, different rail gauge, = and pick the hot beverage that suits you.

Brian=C2= =A0
--000000000000788e06059798e680-- From nobody Sun Nov 17 22:34:29 2019 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 7C08912089E for ; Sun, 17 Nov 2019 22:34:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_NONE=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 Q0G4ru67MxzL for ; Sun, 17 Nov 2019 22:34:26 -0800 (PST) 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 065131200B3 for ; Sun, 17 Nov 2019 22:34:26 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47GfLk5FPzz3Fn; Mon, 18 Nov 2019 07:34:22 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1574058862; bh=bAPThdCqtSRYcneUrHht5CvTv/4pDgeRa8ilFr6QEHw=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=L2fsRDR8Z2g8XHxi+A25PA4CsPmsElwqpvOSEJYxP7cocpOEvsTpKM/aGxUw/OHyk D7oWU+lMbHaaSfvBQn6GDWMzF98EkM5GsWdMH8PnOWWdydwAqjcy4Th6XHEJX91uzY l4c/BS0mrsXHlXCooTPsuF7umulwr4KcV2sSmP9o= 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 fQnIKhAFs2c4; Mon, 18 Nov 2019 07:34:21 +0100 (CET) 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; Mon, 18 Nov 2019 07:34:21 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 6646260011A1; Mon, 18 Nov 2019 01:34:20 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 6529782DF4; Mon, 18 Nov 2019 01:34:20 -0500 (EST) Date: Mon, 18 Nov 2019 01:34:20 -0500 (EST) From: Paul Wouters To: Vittorio Bertola cc: S Moonesamy , add@ietf.org In-Reply-To: <2105867190.7141.1574038197898@appsuite-gw2.open-xchange.com> Message-ID: References: <6.2.5.6.2.20191116232455.10209e78@elandnews.com> <2105867190.7141.1574038197898@appsuite-gw2.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 06:34:28 -0000 On Mon, 18 Nov 2019, Vittorio Bertola wrote: > I still find it weird that people at the IETF challenge jurisdiction and national sovereignty so directly. Whether we like it or not, that concept is what keeps the world together and more or less at peace, granting peoples the right to self-govern. In the end, a good architecture for the DNS would support the ability of each country to make and enforce rules over their citizens' use of it. The opposite, in the end, is only going to replace one jurisdiction with another, which is unacceptable to even the most democratic governments. What I think is the strength of DNS is its hierarchy. If I trust Canada, I can use things within .ca. If I don't trust The Netherlands, I can avoid using .nl. Each TLD has its own sovereignty. The problem arises when the jurisdiction I'm in is trying to limit the other jurisdictions I can communicate with. DNS censorship is the way this is done, and DoH helps avoiding being caught in this. Paul From nobody Sun Nov 17 22:46:37 2019 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 017AE1208B5 for ; Sun, 17 Nov 2019 22:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k0xUzRdAUXWu for ; Sun, 17 Nov 2019 22:46:34 -0800 (PST) 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 1F35E1200B3 for ; Sun, 17 Nov 2019 22:46:34 -0800 (PST) Received: by mail-il1-x12a.google.com with SMTP id m5so15002285ilq.0 for ; Sun, 17 Nov 2019 22:46:34 -0800 (PST) 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=YYktDUk1mK3LrjySc5vavGBLqGNU8ZsKCpqMgpN7eUU=; b=fNALxa0rNd2lVZ79/lxO7Ii8EJzt+qkFaF1FUhK1P8y8Ps0t/Dpay/AI6ppNHq7jf/ KdZYmKADQDOlvttFkpkhL7JUDY5vLzIB1GcemBU/mmQWqZ6RYKRe050T93Mf0K3H+7G5 HZ3c/Hk2bwGZfrtA7qkFIFDuDmIO/nUW51fH3WsWCMyeE1DB1Yu69Gi9PwyRT5ty/5IX 0PrlR11hQw/eUhyVt6YQgw0DXTlI1BUin/a2bvI6Dcz9+/sh2lC2PaqLWl15iA1iEehb eaPWUtjmkxvJuz7ywNn8HhvexyZJSQWp3+60uOoFDD+Zv1U6YXAZQKPN9xv6+2fsMm0n 4/Jg== 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=YYktDUk1mK3LrjySc5vavGBLqGNU8ZsKCpqMgpN7eUU=; b=FfpA3pvIt3i7RZ8tnOGThUKuIeSHru2Jza/RHcc0RoLDOb9uZ7nRx+edMKM1UU0C1H NZTt35mAEvtsnPEM5LWOhirK9cikNnUUb5KtwS2stjVwxAaXF0Mf5iMFpPddWcKJvWwe lVV+qFh4dAiPWVmbh+4RBfauIAJoeGu64BLN0qJOOKLZUI3cPk+aVFP09PlQHPrjfDhT eGgWEnqQSonWU03UCtUJcV0zrzVmwKgTsh3uV/4gAVCbGo63mbBIPfH/kVB0IxMwxadn g2lTcJhLPfYAQid1nDd/dR9+D+ugzFFQk1lgOeyZZp7iIBQzjHmFXOuZA7ND1BC77qs1 kPEQ== X-Gm-Message-State: APjAAAUVF6una5HAfJ4gRXxH/6+blq6b6oqp1K4mpxCSGGswvcZIXNpB UQ5RCtzN39b1jyB+fLOOh17xb2XPFeoC5Ex+uhHsmSjv X-Google-Smtp-Source: APXvYqymzXirDihoSu6nKX692CsQ9/S3OonHM3y2JQObCOck7fjnZhhxSrjRv+fSM+LCZDn1g+MxsVFNHPDALfLIj4c= X-Received: by 2002:a92:48cf:: with SMTP id j76mr13710796ilg.189.1574059593264; Sun, 17 Nov 2019 22:46:33 -0800 (PST) MIME-Version: 1.0 References: <6.2.5.6.2.20191116232455.10209e78@elandnews.com> <2105867190.7141.1574038197898@appsuite-gw2.open-xchange.com> <24018.1739.610788.280101@gro.dd.org> In-Reply-To: <24018.1739.610788.280101@gro.dd.org> From: Rob Sayre Date: Sun, 17 Nov 2019 22:46:22 -0800 Message-ID: To: Dave Lawrence Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000e9756e0597994e15" Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 06:46:36 -0000 --000000000000e9756e0597994e15 Content-Type: text/plain; charset="UTF-8" On Sun, Nov 17, 2019 at 6:49 PM Dave Lawrence wrote: > Vittorio Bertola writes: > > I still find it weird that people at the IETF challenge jurisdiction > > and national sovereignty so directly. > > You were careful with your words and I appreciate that. > I'd like to understand the use case better. Is the idea that some software companies are selling DNS filtering software to any government, and letting those governments configure the policy? thanks, Rob --000000000000e9756e0597994e15 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Sun, Nov 17, 2019 at 6:49 PM Dave = Lawrence <tale@dd.org> wrote:
<= /div>
Vittorio Bertola wri= tes:
> I still find it weird that people at the IETF challenge jurisdiction > and national sovereignty so directly.

You were careful with your words and I appreciate that.=C2=A0

I'd like to understand the use case better.

Is the idea that some software companies are selling D= NS filtering software to any government, and letting those governments conf= igure the policy?

thanks,
Rob
--000000000000e9756e0597994e15-- From nobody Sun Nov 17 23:26:27 2019 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 32F091208DE for ; Sun, 17 Nov 2019 23:26:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.751 X-Spam-Level: X-Spam-Status: No, score=-1.751 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1536-bit key) header.d=iecc.com header.b=Ve9j7BBI; dkim=pass (1536-bit key) header.d=taugh.com header.b=I7DEHpHo 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 Kihi0vS7ZrRZ for ; Sun, 17 Nov 2019 23:26:24 -0800 (PST) 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 2AA581208DC for ; Sun, 17 Nov 2019 23:26:23 -0800 (PST) Received: (qmail 45835 invoked from network); 18 Nov 2019 07:26:22 -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=b309.5dd2479e.k1911; i=printer-iecc.com@submit.iecc.com; bh=IbmWN5AK9qgo9q9PoZ0AyUkDxAvuWcJDCqsK16KK1Us=; b=Ve9j7BBI877ZFOsu9BmrIs6UrU87ot9ZnckxnSNSFgpHsi9xGySGZPzTcea0rmdH2YFLNPO+xnyWgHuaS43G6LXUf1KUszE3BE6t3IcnMUe9gRVoJU0Lcg9sPn0Qqh5A0SRR4Wxp+/qzW/0fw0ybTisjzUkfaqiH7DasIFVifUlwrHcULNC+ws/YrR2UUHAOLsIBfFRrf2E7dW5413V/An6ZZAKflEGMNnmWw3rja1TW1oY2gSaZ+TvV/NvWlChv 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=b309.5dd2479e.k1911; olt=printer-iecc.com@submit.iecc.com; bh=IbmWN5AK9qgo9q9PoZ0AyUkDxAvuWcJDCqsK16KK1Us=; b=I7DEHpHoSOS1zMBpjk8qnWqFCKKokX4H2NTUe683KfgGjMuPJH9Z2SrXjXXoTmpcVzXb2ApKBabCQZLZEm0bU1Wn+bV6F37ROsRXZAjq25EtcG5JncJeZDt5jZ0JOZ8TWBTiuC3XMFC1NN/yL5yJhVi/GVafNrAHzTv48R/t0zyrITIWDJNUS/XtO19Cl/+d1cT+k+LFJ93rdJLW9ylwr7/F+PaBu+fxYnQLAfnp/GkglmAn6mw+P/+LUf21PuaK Received: from dhcp-8506.meeting.ietf.org ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPSA (TLS1.2 ECDHE-RSA AES-256-GCM AEAD, printer@iecc.com) via TCP6; 18 Nov 2019 07:26:21 -0000 Received: by dhcp-8506.meeting.ietf.org (Postfix, from userid 501) id BA352F6835F; Mon, 18 Nov 2019 15:26:19 +0800 (+08) Date: 18 Nov 2019 15:26:19 +0800 Message-Id: <20191118072619.BA352F6835F@dhcp-8506.meeting.ietf.org> From: "John Levine" To: add@ietf.org Cc: brian.peter.dickson@gmail.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] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 07:26:25 -0000 In article you write: >This the question, very briefly: *Is it too late to discuss changing the >port for DoH from 443 to a unique port number?* It's pretty clear to me from the discussion is that the answer to this question depends on what you think DoH is for. Good luck getting agreement on either. From nobody Sun Nov 17 23:50:42 2019 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 329F112007C for ; Sun, 17 Nov 2019 23:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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=RFrkzYP+; dkim=pass (2048-bit key) header.d=comcast.com header.b=0paBQHTD; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=V1WLpFun 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 3a3RQt3A1LkP for ; Sun, 17 Nov 2019 23:50:39 -0800 (PST) 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 D1DD6120041 for ; Sun, 17 Nov 2019 23:50:38 -0800 (PST) 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 xAI7kKg7013135 for ; Mon, 18 Nov 2019 02:50:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=GzfJPq+2T4lki8JEkFXFvakS+Kho7fvjIT8Ba6p/plY=; b=RFrkzYP+1Xtn7rSZkSPqMtdrHOI+VQScwAfnQraCQOctdZcw8NYnCs10JDU7akbD7qht 6S8dERcnrZE8VefF1w+FHpBaiTEIVJM0p04gaZeKleOWquHvP4j265rycn+mKmavTgJ1 fsabCuzgtYWSAIxu3DQyrCKBW0U/fhF38GGjKB1qveOnqUTksk540ykXp+EhKGaHY8uA RZ1HvnziIfYYAdEUrEsia+7Ln3gHzl9Tonsro2PvqBDl1jBgfC9Vao1UYwaEx+e2wC79 HowSOA85Up/jxi4falTm1mGVdJhom1rjNdddctIM0qVaNaDAefyngxQ8SoI/jQ94MZ9s PA== Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) by mx0b-00143702.pphosted.com with ESMTP id 2waeuvac7q-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 18 Nov 2019 02:50:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1574063434; x=2437977034; 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=GzfJPq+2T4lki8JEkFXFvakS+Kho7fvjIT8Ba6p/plY=; b=0paBQHTDl9ISFNNjNmHCA8wHGAxbIQYZ3d5x1qWXg7KjrcvA7qDjkTIf19w5xj3p 8/dlGSgupEDv9Pz/awtWNP0fy2Pn1a/xOTQjnqW3/AYKFbnP6lD5H/aEjOzudtky y3M0f+2VkWVc+CaKGZGJXhi5tpvJrLU4WSkMvxSjRYjBRCyrbEuNHyJQRDqjaOV1 gxJ6zcNFZmLcf45mdvGyi18ym2+ADtk0u0eAc5yLFPOiIe2Lp+e9OmEvmRDyGV0n JLXq9WxNhRtapt9Kox79SFtthB4RE2K09e5xtxXsY6yn1PnzFgKuhHt7q8XMtO2y aE/QL8QqLmlFPxqLWzkdBQ==; X-AuditID: 60721c4c-a4bff70000003748-8e-5dd24d4a4b40 Received: from PACDCEX21.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id E6.44.14152.A4D42DD5; Mon, 18 Nov 2019 02:50:34 -0500 (EST) Received: from PACDCEX09.cable.comcast.com (24.40.1.132) by PACDCEX21.cable.comcast.com (24.40.1.144) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 02:50:33 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX09.cable.comcast.com (24.40.1.132) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 18 Nov 2019 02:50:33 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (104.47.40.56) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 02:50:32 -0500 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB4466.namprd11.prod.outlook.com (52.132.254.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.29; Mon, 18 Nov 2019 07:50:31 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 07:50:30 +0000 From: "Livingood, Jason" To: Ted Lemon , Jim Reid CC: ADD Mailing list Thread-Topic: [Add] Agenda and Revised Charter for the ABCD BoF Thread-Index: AQHVndatXYjml60U3EOPY7fPIsqgxqeQcrOA///HfgA= Date: Mon, 18 Nov 2019 07:50:30 +0000 Message-ID: References: <254AEFB0-F930-466B-8BB6-707D5CE72657@fl1ger.de> <46A8E055-C14B-4927-B348-1B4C44F417DF@fugue.com> <0178A644-1D5E-44D7-AB27-D3F8BFB5D3C3@fugue.com> In-Reply-To: <0178A644-1D5E-44D7-AB27-D3F8BFB5D3C3@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-originating-ip: [31.133.152.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 28b29482-7b88-41c8-025f-08d76bfbfc3a x-ms-traffictypediagnostic: BY5PR11MB4466: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(39860400002)(346002)(366004)(396003)(136003)(376002)(189003)(199004)(15404003)(2616005)(64756008)(80792005)(11346002)(6246003)(86362001)(186003)(7736002)(446003)(229853002)(71190400001)(71200400001)(478600001)(2906002)(6306002)(54896002)(6512007)(486006)(476003)(236005)(256004)(14444005)(99286004)(5660300002)(6436002)(6486002)(25786009)(76176011)(8676002)(81156014)(8936002)(53546011)(110136005)(102836004)(4326008)(91956017)(76116006)(6506007)(66066001)(316002)(58126008)(66476007)(3846002)(14454004)(26005)(66946007)(81166006)(66556008)(66446008)(33656002)(6116002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB4466; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: jTJj07uEkNimO/4xCEy/KVrxruG5Oe4u9YOtP93uX1vsDAf7DGIq6DWj4NaMaOoE6yF/1IhLx5stS6f4nf52EqbI9xzfThOCvlp/ZZGVDuKgJQu9Bm96LGERztIks4IOpzcSb7X5K0FHmrhoT+bnpZhuowyufDLRxzW69QnseZz2R/tk/Ka4DlH35ozg8LOByVDiG5XVyowrb6JNGUoum1w+01lAWTqKLAKZ4c73p+zyK+ENTNUgePCjNjnOYhq+ajf6Oy94aw7Lwz0BA9YAlDLtWbtze0NZ/K/nNEwz1YJ/kdryQ/Fj+saZDVKHPKfEgs5OidJWwCPzIcAP46i26NOgSONVk+/d9oA8I3rBa8rspl+pJIhjp+1Gck8LG8D/R8l88tUamK0+ZcP+whrs2GL2qhUI8dt/eA+2vMo1cJkcsty+9P/FijY/r0zblWHL x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W+NWlV2WyESDiaZ+oUZA1fu+MeFtpRnyoie3CeR0tYJaqsNIPjCnMudbP6jwIPs1w+sTu3nFsmgk/HuTVnC/4UQ+82oJXQxKfNyAuGFnv3HjIvQet377ByjunZ03G5PwtAPeoxYabXMTTzKgCvNDwdYOT59yaLAYuxwl3lIndorlGIBP+313kqGxDet6bYyFAtyNoZvN/iGKmcAgWcDyQxnK0XPp5w9stpqEHN8kE3CXo44UKvpKq3yITlnN/96FeT6WDAKqonx0RSKLQ4NQd5F1qGD3Hb8CnEHFzpRTI6z7QXAoUj/o8Rmb+5wvPPbNZtUz34LQk8K6GVOgzrCoRg== 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=B8FHf0WyJ/HTxRiBrKdi7R/DzMxgIDF3ss9vBkFQhrQ=; b=FEr1/FUWZ+S+I+oFEDYqf1wqpPLdolTChN9FzdiOEmhe67uvefnGRQ+zxfM6Zpav986eX7IvJOfqhPxidvnRSber7fTr+OVdj7NN5GZFjK4Davvh5zFtGiTSVn98J2OvhsVBpXebW0rS2xxsgAdNZbUbRh4Aq8o/dXMYGiDU4Csz9iPX1qD0vwxjc4WkK5U9Er0cDA76btLHD/b22Ryu8ZGWWrq2pOOgZl8e/GGLoO7b2b01UPH+aQ2smrOLHY23Md45NIJh56nz4nJeJREAoskWA6pYAzRDOW+/8QMKBKHwNRsR3/ORYvff6UI3PSnIDnJB6XCNnvWfvp69n7YeMA== 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=B8FHf0WyJ/HTxRiBrKdi7R/DzMxgIDF3ss9vBkFQhrQ=; b=V1WLpFunhI4wzFZYEjgf5Ma0TKRzQ95GsEsXb+h7aSWDkZLMsWDEwAdKQFmIlQA+11r62O9K0WDGKz3wlNuGL6vLLTq3s0m5rlCWMjCo9Q9tSyMSb+3oGcVbbwjPQuzWffHxQMRXhGVUkrtlKTeKpVb7SXg5wENKJyE5rcJ3+Ho= x-ms-exchange-crosstenant-network-message-id: 28b29482-7b88-41c8-025f-08d76bfbfc3a x-ms-exchange-crosstenant-originalarrivaltime: 18 Nov 2019 07:50:30.6879 (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: Tnaw5sJH5bAJaY+B3EMva+5jTmHw5hiTa/4g9AAljc/HBlTSTueWYgXrRE0zUvcNbZVMZEyx6M3MJtQQu3Ghp35UZTVqh/sx2QB8+rpeX4s= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4466 x-originatororg: cable.comcast.com Content-Type: multipart/alternative; boundary="_000_D4DC473FF3D74A088308319A4F3675C1cablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA22Sa0iTURjHO++7y6s5OC7NJyvSiWGSLk1sha0CkyUtLIIisnzT43VeeDct +2RhN9egRMSmoekwMzXyiyJRuDQrw1sKUqnk1tTUBLXUwsrtXSDk+fR7nv//uZzDYWjpI5E3 k5KhI1wGq5GJXAVx2iOKoGh1X+yupjYvxZ/OBpGiyxanmKprow7Sqqs91WKVybREqToHvtIx 9Jk8FKFL5giriySJJENLlK4+/52ICyQxkyOHWU6Te4JoCLu2ze5MIJqUHMLJ12wjX7NPXD+V PPiiXJw1rrrUN28W5iFLVAFiGMBh0PVUXIBcGSlupcDwqZjmgxYEV25bVhSXlWAAQXOvmhfa V/i6QcgHRRTUt88560cRdMxXUPYSEQ6HoQf9tJ09cAQ87bQhO9PYD/KtQ478BqyEmZIxEe85 AJbJeornfZBfetfhEWB/aJpuE9hZgiPhqmXWOWyMhpaXPx3FLng/mOcMDkZ4Iyy8raP4YV7w wVruYMAYTM+6aZ49YcLyW2h/AE8sh9ZlNV+aAFUFlU67L9yoGhHyvBX6yvWIZzX8bC50tgmE 2qFpMc9pYHtV6OTtMDh10+nZApVNPY6dAS8LYXzxpsg+V4pTYXpAeQftNq7a1Lii0DgJvr2m jI4bu8Obe1YBn94BT1rkvNsXivSfxTwHwLWy+05WgVHfSK/2VCCmFrntDQ8OCQkLDlUE7wlv RPYPzG052oxmi1VmhBkkc5NkRPXFSoVsjjY33YyAoWUekmOjPbFSSQKbe5lwmee5bA3RmtFm RiDzkqyrr4iV4iRWR9IIySLcP5ViXLzzkF8gnpgordGsT92QUBg0H+fTGGANW3/xyPNf1VPh J390uJ+jbpw6u2T7Yzk09eZ1t+7Wudbv4JeMFwO8U2rfLYTGP9R/OR3vry16XzKiDNyWzYiX PTYN10f3yutm9pe4NBz/OKmM3ux3JyQ1uqb2cc64Wc3GpJfAzrPDZdaeJYNJJtAmsyGBNKdl /wJ1DitevAMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_01:2019-11-15,2019-11-17 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 07:50:41 -0000 --_000_D4DC473FF3D74A088308319A4F3675C1cablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SG9uZXN0bHkgSSB3YXMgdW5zdXJlIHdoYXQgaXQgbWVhbnQgYXMgd2VsbCDigJMgSSB3YXMgcmVh bGx5IGp1c3QgZ3Vlc3NpbmcgYXQgd2hhdCBtaWdodCBoYXZlIGJlZW4gaW50ZW5kZWQgYnkg4oCc UmVzaWxpZW5jZSBhbmQgZmF1bHQtdG9sZXJhbmNl4oCdIGluIHRoZSBsYXRlc3QgZHJhZnQgY2hh cnRlci4gOy0pIFNvIEkgd2FzIGp1c3QgdGhyb3dpbmcgb3V0IGlkZWFzIHRvIHByb2dyZXNzIGRp c2N1c3Npb24gb24gdGhlIGNoYXJ0ZXIuDQoNCkZyb206IEFkZCA8YWRkLWJvdW5jZXNAaWV0Zi5v cmc+IG9uIGJlaGFsZiBvZiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+DQpEYXRlOiBNb25k YXksIE5vdmVtYmVyIDE4LCAyMDE5IGF0IDI6MTMgUE0NClRvOiBKaW0gUmVpZCA8amltQHJmYzEw MzUuY29tPg0KQ2M6IEFERCBNYWlsaW5nIGxpc3QgPGFkZEBpZXRmLm9yZz4NClN1YmplY3Q6IFJl OiBbQWRkXSBBZ2VuZGEgYW5kIFJldmlzZWQgQ2hhcnRlciBmb3IgdGhlIEFCQ0QgQm9GDQoNCk9u IE5vdiAxOCwgMjAxOSwgYXQgMTowOCBBTSwgSmltIFJlaWQgPGppbUByZmMxMDM1LmNvbTxtYWls dG86amltQHJmYzEwMzUuY29tPj4gd3JvdGU6DQpJIHRob3VnaHQgdGhpcyBtZWFudCBlbmQgY2xp ZW50IGJlaGF2aW91ci9wb2xpY3kuIGllIElmL3doZW4gRG9IIGZhaWxzIChmb3Igc29tZSBkZWZp bml0aW9uIG9mIGZhaWwpLCB0cnkgRG9UIHRoZW4gRG81My4gT3IgZ2l2ZSB1cC4gT3IgdHJ5IERv NTMsIHRoZW4gRG9ULiBPciBzb21lIG90aGVyIGNvbWJpbmF0aW9uIG9mIHRoZXNlIGZhbGxiYWNr cy4gSG93IGNvdWxkL3Nob3VsZCByZXNvbHZlcnMgKGZvciBzb21lIGRlZmluaXRpb24gb2YgcmVz b2x2ZXIpIGJlIGNvbmZpZ3VyZWQgYW5kL29yIHByb3Zpc2lvbmVkIHRvIHJlZmxlY3QgbG9jYWwg cG9saWN5IG9yIGVuZCB1c2VyIHByZWZlcmVuY2UgYWJvdXQgdGhlc2UgcG9zc2liaWxpdGllcz8N Cg0KSXTigJlzIG5vdCBjbGVhciB0byBtZSB0aGF0IHdlIG5lZWQgdG8gZG8gdGhpcywgYnV0IEkg dGhpbmsgaXQgd291bGQgYmUgb2theSB0byBoYXZlIGEgY2hhcnRlciBpdGVtIGFib3V0IHJlc2Vh cmNoaW5nIGl0LiAgVGhlIHJlYXNvbiBJIHNheSB3ZSBtYXkgbm90IG5lZWQgdG8gZG8gaXQgaXMg dGhhdCBpdOKAmXMgbm90IGNsZWFyIHRvIG1lIHRoYXQgdGhlcmXigJlzIG9uZSBhbnN3ZXIgd2Ug Y291bGQgZGljdGF0ZS4gICBJIHN1c3BlY3QgdGhhdCBpdCBpcyBtb3JlIG9mIGEgc2VjdXJpdHkg cG9saWN5IGRlY2lzaW9uLiAgU28gd2hhdCBtaWdodCBiZSB1c2VmdWwgaXMgYW4gZXhwbG9yYXRp b24gb2Ygd2hhdCBwb2xpY2llcyBtaWdodCBtYWtlIHNlbnNlLiAgIEhvd2V2ZXIsIG15IGludHVp dGlvbiBpcyB0aGF0IHRoZSBhY3R1YWwgd29yayBvbiB0aGlzIHRvcGljIHdpbGwgYmUgZG9uZSBi eSB2ZW5kb3JzLCBub3QgaW4gdGhlIElFVEYsIGJlY2F1c2UgdGhlIG9ubHkgd2F5IHRvIHJlYWxs eSBnZXQgY2xhcml0eSBvbiB0aGUgY29ycmVjdCBiZWhhdmlvciBpcyB0byBoYXZlIHVzZXJzIHdp bm5pbmcgb3IgbG9zaW5nIGFzIGEgcmVzdWx0IG9mIHRoaXMuICBTbyB1bmxlc3MgdGhlIHZlbmRv cnMgd2FudCB0byBkaXNjdXNzIHRoaXMgaW4gdGhlIElFVEYsIEkgdGhpbmsgdGhpcyBpcyBqdXN0 IGdvaW5nIHRvIGNyZWF0ZSBjb25mdXNpb24uICAgSWYgYSBXRyBpbiB0aGUgSUVURiBzcGVuZHMg YSBsb3Qgb2YgdGltZSB3cml0aW5nIGRvY3VtZW50cyBhYm91dCB0aGlzIHdpdGhvdXQgaW5wdXQg ZnJvbSB0aGUgdmVuZG9ycywgdGhlIGJlc3QgY2FzZSBzY2VuYXJpbyBpcyB0aGF0IHRoZSBkb2N1 bWVudHMgd2lsbCBjb2luY2lkZW50YWxseSByZWZsZWN0IHdoYXQgdGhlIHZlbmRvcnMgbGVhcm4g YXMgdGhleSBkZXBsb3kgdGhpcy4NCg0K --_000_D4DC473FF3D74A088308319A4F3675C1cablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6TWVubG8tUmVndWxhcjsNCglwYW5vc2UtMToyIDEx IDYgOSAzIDggNCAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9y bWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNv bm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJ bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6 ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij5Ib25lc3RseSBJIHdhcyB1bnN1 cmUgd2hhdCBpdCBtZWFudCBhcyB3ZWxsIOKAkyBJIHdhcyByZWFsbHkganVzdCBndWVzc2luZyBh dCB3aGF0IG1pZ2h0IGhhdmUgYmVlbiBpbnRlbmRlZCBieSDigJxSZXNpbGllbmNlIGFuZCBmYXVs dC10b2xlcmFuY2XigJ0gaW4gdGhlIGxhdGVzdCBkcmFmdCBjaGFydGVyLiA7LSkgU28gSSB3YXMg anVzdCB0aHJvd2luZyBvdXQgaWRlYXMNCiB0byBwcm9ncmVzcyBkaXNjdXNzaW9uIG9uIHRoZSBj aGFydGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTQuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+QWRkICZsdDthZGQtYm91bmNl c0BpZXRmLm9yZyZndDsgb24gYmVoYWxmIG9mIFRlZCBMZW1vbiAmbHQ7bWVsbG9uQGZ1Z3VlLmNv bSZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+TW9uZGF5LCBOb3ZlbWJlciAxOCwgMjAxOSBhdCAyOjEz IFBNPGJyPg0KPGI+VG86IDwvYj5KaW0gUmVpZCAmbHQ7amltQHJmYzEwMzUuY29tJmd0Ozxicj4N CjxiPkNjOiA8L2I+QUREIE1haWxpbmcgbGlzdCAmbHQ7YWRkQGlldGYub3JnJmd0Ozxicj4NCjxi PlN1YmplY3Q6IDwvYj5SZTogW0FkZF0gQWdlbmRhIGFuZCBSZXZpc2VkIENoYXJ0ZXIgZm9yIHRo ZSBBQkNEIEJvRjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiBOb3YgMTgsIDIwMTksIGF0IDE6MDggQU0sIEppbSBSZWlkICZsdDs8YSBocmVm PSJtYWlsdG86amltQHJmYzEwMzUuY29tIj5qaW1AcmZjMTAzNS5jb208L2E+Jmd0OyB3cm90ZToN CjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXIiPkkg dGhvdWdodCB0aGlzIG1lYW50IGVuZCBjbGllbnQgYmVoYXZpb3VyL3BvbGljeS4gaWUgSWYvd2hl biBEb0ggZmFpbHMgKGZvciBzb21lIGRlZmluaXRpb24gb2YgZmFpbCksIHRyeSBEb1QgdGhlbiBE bzUzLiBPciBnaXZlIHVwLiBPciB0cnkgRG81MywgdGhlbiBEb1QuIE9yIHNvbWUgb3RoZXIgY29t YmluYXRpb24NCiBvZiB0aGVzZSBmYWxsYmFja3MuIEhvdyBjb3VsZC9zaG91bGQgcmVzb2x2ZXJz IChmb3Igc29tZSBkZWZpbml0aW9uIG9mIHJlc29sdmVyKSBiZSBjb25maWd1cmVkIGFuZC9vciBw cm92aXNpb25lZCB0byByZWZsZWN0IGxvY2FsIHBvbGljeSBvciBlbmQgdXNlciBwcmVmZXJlbmNl IGFib3V0IHRoZXNlIHBvc3NpYmlsaXRpZXM/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl04oCZcyBub3QgY2xlYXIg dG8gbWUgdGhhdCB3ZSBuZWVkIHRvIGRvIHRoaXMsIGJ1dCBJIHRoaW5rIGl0IHdvdWxkIGJlIG9r YXkgdG8gaGF2ZSBhIGNoYXJ0ZXIgaXRlbSBhYm91dCByZXNlYXJjaGluZyBpdC4gJm5ic3A7VGhl IHJlYXNvbiBJIHNheSB3ZSBtYXkgbm90IG5lZWQgdG8gZG8gaXQgaXMgdGhhdCBpdOKAmXMgbm90 IGNsZWFyIHRvIG1lIHRoYXQgdGhlcmXigJlzIG9uZSBhbnN3ZXIgd2UgY291bGQgZGljdGF0ZS4g Jm5ic3A7DQogSSBzdXNwZWN0IHRoYXQgaXQgaXMgbW9yZSBvZiBhIHNlY3VyaXR5IHBvbGljeSBk ZWNpc2lvbi4gJm5ic3A7U28gd2hhdCBtaWdodCBiZSB1c2VmdWwgaXMgYW4gZXhwbG9yYXRpb24g b2Ygd2hhdCBwb2xpY2llcyBtaWdodCBtYWtlIHNlbnNlLiAmbmJzcDsgSG93ZXZlciwgbXkgaW50 dWl0aW9uIGlzIHRoYXQgdGhlIGFjdHVhbCB3b3JrIG9uIHRoaXMgdG9waWMgd2lsbCBiZSBkb25l IGJ5IHZlbmRvcnMsIG5vdCBpbiB0aGUgSUVURiwgYmVjYXVzZSB0aGUgb25seQ0KIHdheSB0byBy ZWFsbHkgZ2V0IGNsYXJpdHkgb24gdGhlIGNvcnJlY3QgYmVoYXZpb3IgaXMgdG8gaGF2ZSB1c2Vy cyB3aW5uaW5nIG9yIGxvc2luZyBhcyBhIHJlc3VsdCBvZiB0aGlzLiAmbmJzcDtTbyB1bmxlc3Mg dGhlIHZlbmRvcnMNCjxpPndhbnQ8L2k+Jm5ic3A7dG8gZGlzY3VzcyB0aGlzIGluIHRoZSBJRVRG LCBJIHRoaW5rIHRoaXMgaXMganVzdCBnb2luZyB0byBjcmVhdGUgY29uZnVzaW9uLiAmbmJzcDsg SWYgYSBXRyBpbiB0aGUgSUVURiBzcGVuZHMgYSBsb3Qgb2YgdGltZSB3cml0aW5nIGRvY3VtZW50 cyBhYm91dCB0aGlzIHdpdGhvdXQgaW5wdXQgZnJvbSB0aGUgdmVuZG9ycywgdGhlIGJlc3QgY2Fz ZSBzY2VuYXJpbyBpcyB0aGF0IHRoZSBkb2N1bWVudHMgd2lsbCBjb2luY2lkZW50YWxseQ0KIHJl ZmxlY3Qgd2hhdCB0aGUgdmVuZG9ycyBsZWFybiBhcyB0aGV5IGRlcGxveSB0aGlzLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_D4DC473FF3D74A088308319A4F3675C1cablecomcastcom_-- From nobody Sun Nov 17 23:56:50 2019 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 E3C511200B2 for ; Sun, 17 Nov 2019 23:56:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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=rrCvAyuc; dkim=pass (2048-bit key) header.d=comcast.com header.b=JoTq8/zE; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=d5jWIl1f 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 mX16MFv6Gwkd for ; Sun, 17 Nov 2019 23:56:47 -0800 (PST) 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 AC39812007C for ; Sun, 17 Nov 2019 23:56:47 -0800 (PST) Received: from pps.filterd (m0184890.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAI7ugte001160 for ; Mon, 18 Nov 2019 02:56:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=h93is5XLBmQJFDleUZLGlPi/ej4WgsY+Ka293TZTt/A=; b=rrCvAyucj9P/wVzPRktIakRlXp5HnXJ4Dm0FLYGtUKS7jLbWb7i35oHYLyB46Iw6ykJy 5Ea6K5+znIZkZocYOyvyT/2GxUSxXY78CQn2gqIzYQx7iY/Y8BOuyfxIgT1inC1dz2r0 KZSbt5u1T7Wyx/Ox48eWE4RcafNb01ak1tUM0GG46pOD1flPFVnNmjVvWmlfUUv4cadS kbEzxkdfbAx1wXFOvx/vPPmekRi3EWd8HZ16zwN98YZpM9k3eJOduRXTkIoiD3W631k3 Fzdv9pZZCdbW1fH0mlAZJwYLbo3/UrzfNEKHCBrGZWBG1zI3KOxO74voSW+TZ8udrbtk 6A== Received: from vaadcmhout01.cable.comcast.com (vaadcmhout01.cable.comcast.com [96.114.28.75]) by mx0b-00143702.pphosted.com with ESMTP id 2wae3gap40-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 18 Nov 2019 02:56:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1574063802; x=2437977402; 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=h93is5XLBmQJFDleUZLGlPi/ej4WgsY+Ka293TZTt/A=; b=JoTq8/zELZZmKwReyKYOi6gDyVQM/Ji3tNaVmqgolY8rq0/0kb9h57PnPZmy/DUa JJfj7O7hyaD4pvEri1VKeMcA3poqesr9GjdNp7Xgzjrc1sXPTetlWE8NbAykWoMu Vnd9qCyZF1GkkIbquMZ83e3IV1xzua1xVCIleNFxibbn0qFhbDuRytMiQYvzrFcs xuvK3BtbPyQA8Fi/7FqC45kSR2oTF2WdiPB37z4vshLIagcTWyAU1yt0+AccL6ii j14HTIHm9algXISFl/AV6AqxTfTIgPVjtvM8JuC4e5F+JV4ELX7eQ0vex5CPQXQs Xh1/NMrD0NkM5qKrXMzEOA==; X-AuditID: 60721c4b-f29ff7000000279f-f3-5dd24ebab6c0 Received: from PACDCEX16.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by vaadcmhout01.cable.comcast.com (SMTP Gateway) with SMTP id 84.B0.10143.ABE42DD5; Mon, 18 Nov 2019 02:56:42 -0500 (EST) Received: from PACDCEX48.cable.comcast.com (24.40.2.147) by PACDCEX16.cable.comcast.com (24.40.1.139) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 02:56:41 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX48.cable.comcast.com (24.40.2.147) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 18 Nov 2019 02:56:41 -0500 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (104.47.40.55) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 02:56:41 -0500 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB4466.namprd11.prod.outlook.com (52.132.254.212) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.29; Mon, 18 Nov 2019 07:56:38 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 07:56:38 +0000 From: "Livingood, Jason" To: Ted Lemon CC: ADD Mailing list Thread-Topic: [EXTERNAL] Re: [Add] Agenda and Revised Charter for the ABCD BoF Thread-Index: AQHVnDttw5Xi8KlSJ0qQiU8WuHP22aeP47wAgACNLYD//841AA== Date: Mon, 18 Nov 2019 07:56:38 +0000 Message-ID: References: <254AEFB0-F930-466B-8BB6-707D5CE72657@fl1ger.de> <46A8E055-C14B-4927-B348-1B4C44F417DF@fugue.com> In-Reply-To: <46A8E055-C14B-4927-B348-1B4C44F417DF@fugue.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-originating-ip: [31.133.152.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 020e8214-e8b1-4ca9-4c1e-08d76bfcd741 x-ms-traffictypediagnostic: BY5PR11MB4466: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(396003)(366004)(346002)(39860400002)(376002)(199004)(189003)(25786009)(76176011)(6436002)(6486002)(8676002)(81156014)(99286004)(5660300002)(316002)(58126008)(66476007)(4326008)(66066001)(6506007)(91956017)(76116006)(81166006)(6116002)(33656002)(66446008)(66556008)(14454004)(3846002)(66946007)(26005)(102836004)(8936002)(186003)(86362001)(6246003)(7736002)(446003)(229853002)(64756008)(2616005)(11346002)(80792005)(305945005)(6512007)(486006)(2906002)(476003)(256004)(14444005)(478600001)(71190400001)(71200400001)(6916009); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB4466; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BgBARt5AVkTmLEnKDQIZRcQ/mfIChEEPh3PJzykc9lLQ1SIEpIpRwi9R0vgMtRAlj7Lp0bVEKlRsMudRbKOU3OUbBfVncNbt8OXmJRyO7t2HIZ3FcZCuWKdRIUSRFXd13GzNPg5s2PXog+2NgyfU4+sKitELBNEkw4PkJDAwKXFRLDg+AvLjq5NhTCE4g+yZ61clu42wohwbLuQuTrHgL7spJScdgt5Ol7ZwwDEJ5ZznqJCdKsqw6wgv7P1Bf8mm07JixXn8uyc/E3e3l0Zi9hLBXohWctxbpUriCMiy6y2PXeYohP5JAGdVEBeAI5JctMkiwMcFvO9BKwbaKE92nWE5w9R6kIeOWc2OW/EA/2D9rLDMVzpB3SYaGk6dg+RfRRcnqdFrOt9AEyPBMURlhbOkK4UoaLBchtLPYU2Lt9mS+BdXA5zrAf3mNOannA5E x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=YMGsjOYdU2Ob69gEw0VU+He8t3Z233OR8UVmSJXe7eE+1BAVLa3rGAYLQIowIm9ydN5ufHIE8LrUVf/JdPXj1OOyanIREW0jyf7/alWYkz1dBM9wqBl5jAPCKg5MhLxphJhsxA43aUtV8m1dJs22Bd1NhQJNrQbYrSyio5E0w+W2jbWWJsezHM7W8FR7UoAJx4MkfmT2CkUrSJ6C9dSf9SseZtAb1ertLHp8efi2LeVraLnBVRMagRL4mHZFLVjNplytQwvI6S/ayuKhg0gSl+z6qk2ZaTSX3jcpDz+1gl/M+5nC84Y56IWfFIrMg25KCOOwyfoHHRdoOI/hF+VwBQ== 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=67nIz0KeTs0SC8RORX5ouMOQe9hEVH2/gCZPCAsd1NI=; b=AjzzRTB2Kh8bjGZFfinxXCsCB+lKkc3hYPhXQa5KEj7bq0+GSlG7WCH2H9xJ9WKCNLuag+Jz6JVMZsy4Jl12xbiAafhzSsEAMdl502/KvaIG3n9FxOIc4ZqVJsTmW9nfhnyGZWsXzt+AI6CjmZXKbY2rH80aCitE4Dhwkraaizv4E7jOI1Jy/KLKnB3F06uU0/Ho+allLBzPKuXaxZo9w6ZTEeDyMmhc+tALMh3t6dpInCSQqeTdr8SDhEHN4VmNOVay757yTlmMx0Vu0NDqXKuENiLf414YjB0xx0T9h+h44i9GzSt/21dazdAlXygl/HpwNKa/xc4ySeq7VJP49g== 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=67nIz0KeTs0SC8RORX5ouMOQe9hEVH2/gCZPCAsd1NI=; b=d5jWIl1fIanbi4WNIxqlEOaU9iPfMOoJLERvhQQebHKN1S2+aMIz3wzlOsKxBozWk63RZKcPXZQnk17w7J9sOf5j1ujQSYOC54gGk+pbxIcE7OZ+gwDsOd83XsYfTSvh5Q9J01Rf3Z7LXWSV59hjmKnhdAKRYf3Cvk+bTeCKN0o= x-ms-exchange-crosstenant-network-message-id: 020e8214-e8b1-4ca9-4c1e-08d76bfcd741 x-ms-exchange-crosstenant-originalarrivaltime: 18 Nov 2019 07:56:38.2126 (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: t/ebmj8lKO2BvMTfofV+2GnGzqhOYI2GAXgYcB2hMcO+5BtssIeA3AGDIJ/Z9taPctY3FZqV6CaUvTU+0L5hDCZdEnTrQEV6ep6Eqnr3TP0= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4466 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <96F838B98A8014409FC25EA17650C583@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA22SaUhUURiGO3e26zJxGjW/TClHjDRzUlxGUJNStMIp7F8g4w2PaY4Ld0xS CKwEt36IWKApLiOaCypKuWSlg2IuqJlmilKpBIYLIq645J07QpDn1/O977edw6EFsl2RDR0T n0TYeEYjF5sKI7Q3lJfbVaPhVwrWLykPBurFysW6biqACnk2UikJqajYpu5Q99KQb1I0S5ik QBJF4rXE3/T8f8f3PolKYEkQw2pSwoiGMMencZmRRBOTTFjFsW0Ux/aJyKaiXy0rE/Vmj6t0 9eI0VGSWjUxowB7Q1bkjyEamtAx3UdD9slXEB+0IilfyjcE4gqK1VYoPehCMV1dJuHoZzqfg zybNG7MIWt5XCDlDjL1gpmxMwLElPg/Fg3UUxwLsAOnzM4c6TVvgUNjKiuJTVLBUWybk+Ros pg8bWIgdYbLxQMyxFAfCQp5ews86oGC7c8hgmGA/2B3/beiP8GnY7D+aZQ1T8yUUf1EMFR3D Ap6tYGFuX8TtYIUV0LUXypdGgi673JhuDxm6HyKe7WC0JAfxHArVuZlG3RlqZpYkPMfCam+W Ub8A3xczjaNsobxlxLAz4AkRZLROUtxcGX4IS+P+uciz8J9NCw8dAXaChnYFL4fAXEeTmGd7 yM/5JSk0vMQp6CuYF5YiUQ0y9/FydXPzcHVXunp7NiHuT7K2t1pR/XawHmEayc2lL4JHw2Ui JlmbEqdHQAvkllLV7Ei4TBrJpKQSNkHNPtIQrR6dpYVya+l+XWm4DD9gkkgsIYmEPXIp2sQm Dbn7UFLvsHUr+e3+xOWh571NEx9PwNctfZ/jfs5di5/nphqzPvm6q3dXm2PFXxp2RlZ65IpB p+u6d0+aPabjlrfTXbYc1Kkn86bnAl67BDX198VtVKpuCu2+rbmPbbSpG3cvOuU9rbVNKfVr +KCfi//s+2b/rU6FTNqkwwNn9rquyoXaaMbNWcBqmb+8WI7/jwMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_01:2019-11-15,2019-11-17 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] [EXTERNAL] Re: Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 07:56:49 -0000 RnJvbTogVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPg0KPj4gLSBQb3RlbnRpYWwgdXNlIG9m IGFsdGVybmF0aXZlIGFwcGxpY2F0aW9uIHBvcnQgbnVtYmVycyBpbiBzb21lIGNvbnRyb2xsZWQg ZW52aXJvbm1lbnRzIChlLmcuIG1hbmFnZWQgZW50ZXJwcmlzZSBlbnZpcm9ubWVudHMpLCBpbmNs dWRpbmcgdGhlIHByb3MvY29ucyBhbmQgaW1wbGljYXRpb25zIG9mIHNlY3VyaXR5IGRvd25ncmFk ZSBhbmQvb3IgZGV0ZWN0YWJpbGl0eSBpbiB0aGVzZSBlbnZpcm9ubWVudHMNCg0KPiBUaGlzIGlz IHByZXN1bWluZyBhIHNvbHV0aW9uLiAgQ2FuIHdlIGNoYW5nZSBpdCB0byBqdXN0IHRhbGsgYWJv dXQgdGhlIHByb2JsZW0/DQoNCj4gLSBUaGUgcHJvYmxlbSBvZiBkZXRlY3RpbmcgYW5kIHByZXZl bnRpbmcgdGhlIHVzZSBvZiBEb0ggaW4gbWFuYWdlZCBlbnZpcm9ubWVudHMgd2hlcmUgdGhlIG5l dHdvcmsgb3BlcmF0b3IgbmVlZHMgY29udHJvbCBvZiBETlMgcXVlcmllcy4NCg0KW0pMXSBUaGF0 IGNvdWxkIHdvcmsgYXMgd2VsbC4gSSB3b25kZXIgdGhvdWdoIGlmIHRoZXJlIGFyZSB1c2UgY2Fz ZXMgd2hlcmUgYW4gZW50ZXJwcmlzZSBtYXkgbm90IHdhbnQgdG8gcHJldmVudCBEb0ggd3JpdCBs YXJnZSwganVzdCB0byBvZmYtbmV0IERvSCBzZXJ2ZXJzIChzL2RldGVjdGluZyBhbmQvZGV0ZWN0 aW5nIG9yID8pLiBBcyBJIHRob3VnaHQgYWJvdXQgaXQsIHBlcmhhcHMgdGhlcmUgaXMgdmFsdWUg aW4gZG9jdW1lbnRpbmcgd2h5IGVudGVycHJpc2VzIG1pZ2h0IHdhbnQgdG8gZG8gdGhpcywgYXMg d2VsbCBhcyB0aGUgc2VjdXJpdHkgJiBwcml2YWN5IHByb3MgYW5kIGNvbnMgb2YgZG9pbmcgc28s IGV0Yy4gQWdhaW4sIG5vdCBzdXJlIEkgaGF2ZSBhIHBvc2l0aW9uIG9uIHRoaXMgZGVsaXZlcmFi bGUgLSBJJ20ganVzdCB0cnlpbmcgdG8gc2VlIGlmIGl0J3MgcG9zc2libGUgdG8gZmxlc2ggb3V0 IHNvbWUgb2YgdGhlIGNoYXJ0ZXIgaXRlbXMgYW5kIGZyYW1lIHRoZW0gc28gdGhhdCBwZXJoYXBz IGNvbnNlbnN1cyBvbiBpdCBtYXkgYmUgcG9zc2libGUuDQoNCg0KDQoNCg0KDQoNCg== From nobody Mon Nov 18 00:04:48 2019 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 134F11200B7 for ; Mon, 18 Nov 2019 00:04:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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=Il+8JQcW; dkim=pass (2048-bit key) header.d=comcast.com header.b=M+P/adBS; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=ZxQLzD8w 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 gu6_RMGL1hDr for ; Mon, 18 Nov 2019 00:04:44 -0800 (PST) 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 895201200B2 for ; Mon, 18 Nov 2019 00:04:44 -0800 (PST) Received: from pps.filterd (m0184889.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAI81pe3031003 for ; Mon, 18 Nov 2019 03:04:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=20190412; bh=0Y16pTuiNDKY86uboOkO/GlPW0wr66bpGKXe/NWCdeE=; b=Il+8JQcW2btj99tY+RvCQTB1Pc1QUo68vds5m4iPzlYeNPeElPKyW7G8M4IbOB0DqhJ1 PowksG4hAzl50RzbTsR14zw94IcpFbtkuFtAiUi6lQqDLaivH+j8fOyr96qUaPslslCv Q9nAh2BO3egBY8wHaqEPU02icaLuM/wL3PgTszl3aw+mO7vqEDyzzXAWNDzQfxBHWAdn CtMkdFk3jqANyK7Y4Y+0ZNRkr2bkEnRvNukO5FPqjj1L8KrNQ5LAbCROtqmuYufsV/EH vFx/qVMzZ3DGZXvmm1qJMAk78l1n73KmHsCCgqMrTPISJrkx5Bai21yMD6NoY1fwNKkq xA== Received: from vaadcmhout02.cable.comcast.com (vaadcmhout02.cable.comcast.com [96.114.28.76]) by mx0b-00143702.pphosted.com with ESMTP id 2wabubkcnv-9 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 18 Nov 2019 03:04:43 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1574064283; x=2437977883; 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=0Y16pTuiNDKY86uboOkO/GlPW0wr66bpGKXe/NWCdeE=; b=M+P/adBS324rIe9SDM1/w13a8k2r1QjdOaF0CprtDffkhVodKHX6A3U+//7K/iPc MKciItLeFkeruzrrcHiEcMwgeIYiWmIdOYmpA4HvlnmLqGfpSxPbGitxC7ba1/VX G4uN9HBVl+MuHwuKzmDNyXxRd1yyBQjsTe3UOE3zKjaSMKTo85+U7Y1LhiIiqDjQ J7/KyvrNPSVyj/1UnV5kTHFev7j2RQ3u2PjxqyQhWJgWSkv9DwpHbHfP1gffRhIl 5Bn8CEexXqiy3URyVAORme8epGuCg3up14zm9DePHwcz+wLU5s1TykPsRX8LlWNA PkPSJtmmMEo32UnYZi60Qw==; X-AuditID: 60721c4c-a33ff70000003748-f0-5dd2509bb8cb Received: from PACDCEX19.cable.comcast.com (vaadcmhoutvip.cable.comcast.com [96.115.73.56]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by vaadcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 08.74.14152.B9052DD5; Mon, 18 Nov 2019 03:04:43 -0500 (EST) Received: from PACDCEX11.cable.comcast.com (24.40.1.134) by PACDCEX19.cable.comcast.com (24.40.1.142) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 03:04:42 -0500 Received: from PACDCEXEDGE01.cable.comcast.com (76.96.78.71) by PACDCEX11.cable.comcast.com (24.40.1.134) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 18 Nov 2019 03:04:42 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (104.47.41.55) by webmail.comcast.com (76.96.78.71) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 03:04:41 -0500 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB4053.namprd11.prod.outlook.com (10.255.72.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Mon, 18 Nov 2019 08:04:39 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 08:04:39 +0000 From: "Livingood, Jason" To: Rob Sayre , ADD Mailing list Thread-Topic: [Add] Agenda and Revised Charter for the ABCD BoF Thread-Index: AQHVnTvcw5Xi8KlSJ0qQiU8WuHP22aePdZWAgACgMICAABGBAIAARsEAgAACQoD//88SAA== Date: Mon, 18 Nov 2019 08:04:39 +0000 Message-ID: <509F49E3-6B10-4AAE-8C65-1B5B144193FD@cable.comcast.com> References: <299277505.7138.1574037347987@appsuite-gw2.open-xchange.com> <20D27080-7049-4D42-B020-6F574FD45140@isoc.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-originating-ip: [31.133.152.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7c4367bc-ff6e-4b3b-2cdd-08d76bfdf627 x-ms-traffictypediagnostic: BY5PR11MB4053: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(396003)(136003)(39860400002)(366004)(346002)(376002)(189003)(199004)(186003)(6436002)(6512007)(4744005)(58126008)(110136005)(66556008)(99286004)(66446008)(478600001)(26005)(5660300002)(102836004)(64756008)(66476007)(256004)(66946007)(53546011)(6506007)(76176011)(6116002)(3846002)(66066001)(71190400001)(71200400001)(91956017)(76116006)(86362001)(81156014)(81166006)(486006)(476003)(2616005)(8936002)(11346002)(446003)(316002)(8676002)(6486002)(33656002)(80792005)(14454004)(6306002)(7736002)(54896002)(2906002)(25786009)(6246003)(236005)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB4053; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ZoBg2ej3QySjd0ptd3WP0V5BkKvCFxtLTbBbxzB1h1760HXGvqAVhgfiq+h3GrhYB4YtFfpuVGExvF4kQ5JeqfgylIPm0MaBVNmCbqqYZ0f4To3MMxFa+VrJK4qjiRWnNbmgMWecMgflscNgx53j5piFNv6w8ycnpjIeBrrDkKOCR7bgpD1XJPKuMWmsgSLL0iE80mYwb1cpgyvgbAI2GSpGq8JETNOglpRjROnOL5ETXhwqOn+hCDRtmTV4MiM7saR5eZXFoxSjSvHA6Kste2ZKSUy4MzZESaihDhLirGUf9QyHYWhUetaJytG2slLoN+IIZmf5TYaejZitoNGu11nSlkVqlMbFLyk+gQJHgGKDb7+dPbZmtGxVSOhEIe/a9frZvqeA2JVWh5WMbAjwgYZqHY9hrGgJv7OOwsjNsu4F/fvyiq43faeeE1H/ZF+z x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VeHKiTDByeClGC+QGhtQqv/j6JiN2SGKPo01uYo+bvJxsUOQztJgCtZoo7+bREvI9cNBE/3+sS3TJIlUmR8n2O6zPdd4kSDxTnFgwo1sjgLjaoigNXjP+X+NdvavlNW6eNkKeVqRvZjD3cwl6KUtuVpKof/3tVQtjRRvlvVWKBAaoBx7oLfvmm+wS0qmAetllot3WYLCLabijqF7+OOmupAT4idT7kuUypiKeGZCMj/XizC7YmOoPPH93mN188aVtQWlmHDV4KNdB7gcFyWOZwRUwOCy3q2J19+I85jYzyA/DvaC868wJP0UHWLWiq1pZFZ4UwB3jwfN87lKUf34NA== 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=Z4gTxoEznyUh5Pd0VjWLP9y33ZASCkkZj/wKvoElyzs=; b=LcvuyXKS01kD3VNX2aEyWEmXVEpniFq74QfIf841nNpPJuvZ+pKcpvOnnJg9MrqjtsVzToNZstYvHIE81T/7quvyXducLOhhQCXWQYdcnFk9BYmUq5C15MUvY4twSUKPwtOqbhRIFjPd+0m3LwE9tU2tRSNvf8mRgqPHbfpDLnFQN55ZvkTrV+IcZq3woiSlc4c//Yqizqm/RERn2U23nmEITuFF2jxaHsT1LD00K4fVURRJ5P9xB5of+dLJqak4d/qpPXh9eln8PLFZ+Ls+ZKE53HN2HcH6ris53RCGcjUUHa7rL3GEyKgZqcB3FFdwUEKrhv7W9sn9FLHXJtt/ow== 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=Z4gTxoEznyUh5Pd0VjWLP9y33ZASCkkZj/wKvoElyzs=; b=ZxQLzD8wt+AyZNtM1wHm8ksW9/UcFA1Y7XdISRm7fXMJVMQKoqZliM8fQTgcmT+VpgMy+7HAf+CeogElAq0etbhXWKrzxMx71jtomxhD5XEpgw4kQUsPLxOsQMGSwJbZWrXEWAQFvAVACJKsJU43ZWurIUKwOD4bI90McrY1ZFY= x-ms-exchange-crosstenant-network-message-id: 7c4367bc-ff6e-4b3b-2cdd-08d76bfdf627 x-ms-exchange-crosstenant-originalarrivaltime: 18 Nov 2019 08:04:39.3346 (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: Ln3tAmsdrBmO+SW/Qij29O3k168K2RSb5lbDozaJDhPVRqJI27nbCbWqQDZlmWt4YuY9o9iu1ZSmR1Rwg3NB+D5f9pTJeJ7kRThw5HSOMeg= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4053 x-originatororg: cable.comcast.com Content-Type: multipart/alternative; boundary="_000_509F49E36B104AAE8C651B5B144193FDcablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA22SfSyVURzHO89z73Mfcu24yC+R3E0vWkRem6GluuYlmqy1yNMcKTfsufca /aVNDGvpzbgpb3c1ItIqGX946Q/dKcRatVveSsh084f5I+Xx3DZbzl+fc36f7+/8znZYWlHL OLMXMrWEz+TUSsZakqKJDNp3N244aX+X0Sboj/ExE1SsL6PCKdVLvUmmMhiWqTjqdD4K0abz hNNGkDSSqSGh1jv+WyHnSFoWT45wvDrvBFETbmNNMFOJ+kIO4b03bOO9YZ+UESp9ttwoyx4L zP08bZbko1sBJciKBewHs0+66BJkzSpwNwXPzf2UuOlAYLrz1lIZRdBbOCsRIgr8CkH3lK1Y uElB6/UrFmsCwcjPPlqwGBwAptqRNXbAh6CuaoYR2B6HwkLFNCOeh8HkXDMlciI8NA9IBZZg D5jrK147l+MIeFBZxIgXmGiYb2tfHYNlrXA8vDY6CA7CW2DpddOaT2Mn+DhVTYmPw2DofEuL 7AgzkytSIeqIvaH7d4wYTYX6kjqL7g5F9V+kIrvCcHUpEjkGqpq+WhxP6HzzyNIyAwrH3jEi 74IC831L1gXqXgzKhJEBz0hh9GkBEu5V4IswPxoqOtuh8dq4pAz56tdNLfJ5KJuZlunXXm8H /ZVTEv1qmsZ7oKXDW1Tc4XbpuEzk3XC16p6FVfC+4Tuz3qlBbCOyCQ7w8vHx8/IN8goMaEPC x+VdotvRr3JVD8IsUtrIM48OJymkXI4m71IPApZWOshjJwaTFPJULu8y4bPO8jo10fSgbaxE 6STf1FyTpMDnOS3JICSb8P+qFGvlnI9sVU4JwR1bI9khWr3T49veVzfyzyxkLMZIfzRLD7Lj DgluZNTzXfLJi2+63J/Z2baGf4jKjv3kdaoBDJt1BvPx2X7VUJSTS2KKVhdqV5cbNplcGXjA fszf3tWjpTc2cKTCKFvURy9p3SYUOtNK/OHyymqp41y1j7/7seUBXZpcKdGkcz6eNK/h/gID PLvEtAMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_01:2019-11-15,2019-11-17 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 08:04:46 -0000 --_000_509F49E36B104AAE8C651B5B144193FDcablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogQWRkIDxhZGQtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIFJvYiBTYXlyZSA8 c2F5cmVyQGdtYWlsLmNvbT4NCk9uIFN1biwgTm92IDE3LCAyMDE5IGF0IDk6NTEgUE0gSm9zZXBo IExvcmVuem8gSGFsbCA8aGFsbEBpc29jLm9yZzxtYWlsdG86aGFsbEBpc29jLm9yZz4+IHdyb3Rl Og0KDQpJIGFncmVlIHdpdGggUGF0cmljayB0aGF0IHRoaXMgaXMgb25lIG9mIGEgbnVtYmVyIG9m IGFzcGVjdHMgb2YgdGhlIG9uZ29pbmcgQUJDRC9BREQgZGlzY3Vzc2lvbiB0aGF0IHNlZW1zIHRv IGluZGljYXRlIHdlIHdvdWxkIGJlIOKAnHNwaW5uaW5nIHRoZSB3aGVlbHPigJ0gKG5vdCBnZXR0 aW5nIG11Y2ggcHJvZHVjdGl2ZSBkb25lKSBpbiBhIFdHLiBJIGxpa2Ugd2hlcmUgTGl2aW5nb29k IGlzIGdvaW5nIG9uIHRoaXMgdGhyZWFkIHdpdGggc3VnZ2VzdGVkIGNoYW5nZXMgdG8gdGhlIHBy b3Bvc2VkIGNoYXJ0ZXIgdG8gbWFrZSB0aGUgd29yayBoZXJlIG1vcmUgY3Jpc3ANCg0KPiBJIGFn cmVlIHRoYXQgc29tZSBvZiBMaXZpbmdvb2QncyBhZGRpdGlvbnMgYXJlIGEgbGl0dGxlIGJldHRl ci4gQnV0IGhpcyBlZGl0cyBzZWVtIHRvIHJlbW92ZSBvdXQtb2YtYm91bmRzIHRvcGljcywgd2hp Y2ggc2VlbXMgbWlzZ3VpZGVkLg0KDQpbSkxdIEl0IHNlZW1lZCB0aGUg4oCYb3V0IG9mIGJvdW5k c+KAmSB0b3BpY3Mgd291bGQgbWFrZSBjb25zZW5zdXMgaW1wb3NzaWJsZSDigJMgd2hpY2ggd291 bGQgdGhlbiBwcmV2ZW50IFdHIGZvcm1hdGlvbi4gU28gcHJvcG9zaW5nIHJlbW92YWwgd2FzIGFu IGFwcHJvYWNoIHRvIHNlZSBpZiB3ZSBtaWdodCBpZGVudGlmeSB0aG9zZSBmZXcgYXJlYXMgd2hl cmUgdGhlcmUgaXMgYWdyZWVtZW50LiBJIGFtIG5vdCBzdXJlIGhvdyB0aGF0IGlzIG1pc2d1aWRl ZCwgYnV0IGl0IHdvdWxkbuKAmXQgYmUgdGhlIGZpcnN0IHRpbWUgSeKAmXZlIGJlZW4gYWNjdXNl ZCBvZiBiZWluZyBtaXNndWlkZWQsIGNvbmZ1c2VkLCBjcmF6eSwgZGVsdWRlZCBvciB3aGF0ZXZl ciBlbHNlLiBMT0wuDQoNCg0KDQo= --_000_509F49E36B104AAE8C651B5B144193FDcablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29M aXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9t OjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVm YXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4g MS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5BZGQgJmx0O2FkZC1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgUm9iIFNheXJl ICZsdDtzYXlyZXJAZ21haWwuY29tJmd0Ozxicj4NCjwvc3Bhbj5PbiBTdW4sIE5vdiAxNywgMjAx OSBhdCA5OjUxIFBNIEpvc2VwaCBMb3JlbnpvIEhhbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpoYWxs QGlzb2Mub3JnIj5oYWxsQGlzb2Mub3JnPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICND Q0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDtt YXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IGFncmVlIHdpdGggUGF0cmljayB0aGF0IHRoaXMgaXMgb25lIG9mIGEgbnVtYmVyIG9mIGFzcGVj dHMgb2YgdGhlIG9uZ29pbmcgQUJDRC9BREQgZGlzY3Vzc2lvbiB0aGF0IHNlZW1zIHRvIGluZGlj YXRlIHdlIHdvdWxkIGJlIOKAnHNwaW5uaW5nIHRoZSB3aGVlbHPigJ0gKG5vdCBnZXR0aW5nIG11 Y2ggcHJvZHVjdGl2ZSBkb25lKSBpbiBhIFdHLiBJIGxpa2Ugd2hlcmUgTGl2aW5nb29kIGlzIGdv aW5nIG9uIHRoaXMNCiB0aHJlYWQgd2l0aCBzdWdnZXN0ZWQgY2hhbmdlcyB0byB0aGUgcHJvcG9z ZWQgY2hhcnRlciB0byBtYWtlIHRoZSB3b3JrIGhlcmUgbW9yZSBjcmlzcDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsgSSBhZ3JlZSB0aGF0IHNvbWUgb2YgTGl2aW5nb29kJ3MgYWRkaXRpb25zIGFy ZSBhIGxpdHRsZSBiZXR0ZXIuIEJ1dCBoaXMgZWRpdHMgc2VlbSB0byByZW1vdmUgb3V0LW9mLWJv dW5kcyB0b3BpY3MsIHdoaWNoIHNlZW1zIG1pc2d1aWRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPltKTF0gSXQg c2VlbWVkIHRoZSDigJhvdXQgb2YgYm91bmRz4oCZIHRvcGljcyB3b3VsZCBtYWtlIGNvbnNlbnN1 cyBpbXBvc3NpYmxlIOKAkyB3aGljaCB3b3VsZCB0aGVuIHByZXZlbnQgV0cgZm9ybWF0aW9uLiBT byBwcm9wb3NpbmcgcmVtb3ZhbCB3YXMgYW4gYXBwcm9hY2ggdG8gc2VlIGlmIHdlIG1pZ2h0IGlk ZW50aWZ5IHRob3NlIGZldyBhcmVhcyB3aGVyZSB0aGVyZQ0KIGlzIGFncmVlbWVudC4gSSBhbSBu b3Qgc3VyZSBob3cgdGhhdCBpcyBtaXNndWlkZWQsIGJ1dCBpdCB3b3VsZG7igJl0IGJlIHRoZSBm aXJzdCB0aW1lIEnigJl2ZSBiZWVuIGFjY3VzZWQgb2YgYmVpbmcgbWlzZ3VpZGVkLCBjb25mdXNl ZCwgY3JhenksIGRlbHVkZWQgb3Igd2hhdGV2ZXIgZWxzZS4gTE9MLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjE0LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_509F49E36B104AAE8C651B5B144193FDcablecomcastcom_-- From nobody Mon Nov 18 00:20:55 2019 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 9369F120881 for ; Mon, 18 Nov 2019 00:20:53 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.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 lsLoqSpaS27q for ; Mon, 18 Nov 2019 00:20:51 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110040.outbound.protection.outlook.com [40.107.11.40]) (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 2E4AD1200A1 for ; Mon, 18 Nov 2019 00:20:51 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HPQKVlgDQbcQekVciReHK/px+vmdgHSI2/PphM4rAvBk24lP0VywR/CQ6DmZ+cqHtPSUy4mbf8rkK+nc6PRFibmqadq0oyB3tVqFGDHmcmp1Y3J0i52N0ODcsnYvjiiZaaovkv3WW2xhiJWRMFS4CUjwpdLMU3GGO8+vvcGEJdzziL7oX7XggH+e9RcpwqL6Xb5UsuuLAAWYHkXI9CcivVHh2F0iClt5JYixwg/jBYZt9q1CqgSVKOjyZS+/LJwUqqKZJAquePCbIBS2M6cHndlVT5GfZzvcelGnOsn9Jk4W9wRQqpJz+kYQJdl9WHZh3iNBuaVjB81qz0jPms5PUQ== 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=MLAMOXWHD6E73ad5baowXSvgjXmI6zEn5RD6qdQEJpE=; b=hyoG/qW6smU3QeXdZQ5/1PID8zz910EgyetEBhwbtOKlX3O3k6wU26Y2ZjJLbBCrNgCQD4p9OflIbZ1phhAbym/59ocEigkKCLnCptFC71RPct8YEqkwxjWQ89KJn6/KRcW+298vxrFhlORXlV1MMFeYiJ45g2FlQAJjIj7nmQZvEKfJhLD1mOLfe+RWMurtdYc4Ws8ylyrDOdvpF6PhZmE6h0RPoCqHTsgkmP+9OGXX3C0nCTzDhbIcI3BUOBq5kRdbWmV1Bzx+VunqIJSLY+0ToCn/Bxbyst04X2JEbgUBvSRf5uN93YKaFJCb9E2G7FXZLzkyKWaLGvl4k9P3fg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MLAMOXWHD6E73ad5baowXSvgjXmI6zEn5RD6qdQEJpE=; b=eB2ykADv591Y1W+DN2gnREy3SXIS6gm35lQWWw3970WNKgw2PiWslteus1expJ8ymDDG8ocpjzQadRZPSoN00VTjPD1h3voQpOHbdDFJ70Red3PPCnln20RotFZ0oxzs+R+bJAXBrCB1CqCemWZbzCSGXWkTxKIqaZEh+w/d86g= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB1518.GBRP265.PROD.OUTLOOK.COM (20.176.143.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Mon, 18 Nov 2019 08:20:48 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 08:20:48 +0000 From: Andrew Campling To: "Livingood, Jason" , Rob Sayre , ADD Mailing list Thread-Topic: [Add] Agenda and Revised Charter for the ABCD BoF Thread-Index: AQHVnebepfNr3Zq+dUejyYxWE6oXjKeQk7IA Date: Mon, 18 Nov 2019 08:20:48 +0000 Message-ID: References: <299277505.7138.1574037347987@appsuite-gw2.open-xchange.com> <20D27080-7049-4D42-B020-6F574FD45140@isoc.org> <509F49E3-6B10-4AAE-8C65-1B5B144193FD@cable.comcast.com> In-Reply-To: <509F49E3-6B10-4AAE-8C65-1B5B144193FD@cable.comcast.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [89.187.165.42] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4d0d4d50-6f32-4ace-6ee5-08d76c0037b8 x-ms-traffictypediagnostic: LO2P265MB1518: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39830400003)(346002)(366004)(136003)(396003)(189003)(199004)(86362001)(6246003)(33656002)(3846002)(71200400001)(7696005)(76176011)(6116002)(790700001)(66946007)(2906002)(66476007)(25786009)(76116006)(66446008)(64756008)(66556008)(14454004)(66066001)(446003)(74316002)(4744005)(5660300002)(11346002)(81166006)(81156014)(8676002)(8936002)(508600001)(44832011)(52536014)(256004)(71190400001)(316002)(53546011)(55016002)(7736002)(6506007)(99286004)(229853002)(9686003)(54896002)(6306002)(236005)(26005)(186003)(110136005)(102836004)(486006)(6436002)(476003)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB1518; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: wLJX6E6L9JBrDQqXirI0SxjKi78mhmG9+Vupl/IJeTyaGKNbVxvF/KCqACE+7QWRlhyNlWi6Uu5x3ZxNO47/JpyOyXH/irev3nAm7oZHghhg4kp5CTLyqXvftD7EdxuUsXuL+ofaymKtEm+IZCwCk/2uJ8vZUuBgOS1eDbHw0bLBmf7adRvJN1E8CAQ+mfei6M46ci3eBOWvotSqokoAef+DfaEBLoY5VOMAqKtTHa59ladVPg4+QeeG8LSId97nOemEaOd1/GuoTU9+KBMnDVDHuiNC25tuq2f+6tXjP9Bu3QHPaSWPlWwcypLonhC5XXDkCn/grrjDHUkfEC9UzH6tWam7bPWtmr5kVN4nSzYHnYMqltyznIRGwkQsu9lIT+84F3W0BW9FhVhqm8Tu31UmYjObl7r4d6SSetuCOZkBlAfHPS+2ujiba91w5bd0 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB05735990CD64E8C778BABE88C24D0LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 4d0d4d50-6f32-4ace-6ee5-08d76c0037b8 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 08:20:48.6608 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Sukc4V6s4GveMhmmHK1uRGgVkddy4QrAoojwD8LDrAjWFYl+rdJGXflUqjoljy2neE7jkN9lOIU1gUWfuvumn/hUYYGLSlKPtS5mpGZ1KBg= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1518 Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 08:20:54 -0000 --_000_LO2P265MB05735990CD64E8C778BABE88C24D0LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gTW9uLCBOb3YgMTgsIDIwMTkgYXQgMTY6MDUgTGl2aW5nb29kLCBKYXNvbiA8SmFzb25fTGl2 aW5nb29kQGNvbWNhc3QuY29tPiB3cm90ZToNCg0KPiBGcm9tOiBBZGQgPGFkZC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzphZGQtYm91bmNlc0BpZXRmLm9yZz4+IG9uIGJlaGFsZiBvZiBSb2IgU2F5 cmUgPHNheXJlckBnbWFpbC5jb208bWFpbHRvOnNheXJlckBnbWFpbC5jb20+Pg0KPj4gSSBhZ3Jl ZSB0aGF0IHNvbWUgb2YgTGl2aW5nb29kJ3MgYWRkaXRpb25zIGFyZSBhIGxpdHRsZSBiZXR0ZXIu IEJ1dCBoaXMgZWRpdHMgc2VlbSB0byByZW1vdmUgb3V0LW9mLWJvdW5kcyB0b3BpY3MsDQo+PiB3 aGljaCBzZWVtcyBtaXNndWlkZWQuDQoNCj4gSXQgc2VlbWVkIHRoZSDigJhvdXQgb2YgYm91bmRz 4oCZIHRvcGljcyB3b3VsZCBtYWtlIGNvbnNlbnN1cyBpbXBvc3NpYmxlIOKAkyB3aGljaCB3b3Vs ZCB0aGVuIHByZXZlbnQgV0cgZm9ybWF0aW9uLg0KPiBTbyBwcm9wb3NpbmcgcmVtb3ZhbCB3YXMg YW4gYXBwcm9hY2ggdG8gc2VlIGlmIHdlIG1pZ2h0IGlkZW50aWZ5IHRob3NlIGZldyBhcmVhcyB3 aGVyZSB0aGVyZSBpcyBhZ3JlZW1lbnQuIEkgYW0NCj4gbm90IHN1cmUgaG93IHRoYXQgaXMgbWlz Z3VpZGVkLCBidXQgaXQgd291bGRu4oCZdCBiZSB0aGUgZmlyc3QgdGltZSBJ4oCZdmUgYmVlbiBh Y2N1c2VkIG9mIGJlaW5nIG1pc2d1aWRlZCwgY29uZnVzZWQsDQo+IGNyYXp5LCBkZWx1ZGVkIG9y IHdoYXRldmVyIGVsc2UuIExPTC4NCg0KVGhhdCBkb2VzIHNlZW0gYSBzb21ld2hhdCBpZGlvc3lu Y3JhdGljIHVzZSBvZiB0aGUgd29yZCBtaXNndWlkZWQuICBMZXTigJlzIGhvcGUgdGhhdCBvdGhl cnMgdGFrZSBhIHNpbWlsYXIgYXBwcm9hY2ggdG8gaGVscCByZWFjaCBhIHJlYXNvbmFibGUgY29u c2Vuc3VzIGluIHRoZSBCb0Ygc2Vzc2lvbiB0b21vcnJvdy4NCg0KDQpBbmRyZXcNCg== --_000_LO2P265MB05735990CD64E8C778BABE88C24D0LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0K CXttc28tbGlzdC1pZDo4OTQwNTA4NDc7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOjMwNzM2OTM2MCAtMTg4MTA4Mzc3NiAxMzQ4MDc1NTUgMTM0ODA3NTU3 IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3NTU3IDEzNDgwNzU1MyAxMzQ4MDc1NTUgMTM0ODA3 NTU3O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1m b250LWZhbWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDENCgl7bXNvLWxpc3QtaWQ6MTI1OTE2OTM3MTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsN Cgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTU3NTkzNDI3MiAtMzk1OTUwNDU2IDEzNDgwNzU1NSAx MzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1NSAxMzQ4MDc1NTcgMTM0ODA3NTUzIDEzNDgwNzU1 NSAxMzQ4MDc1NTc7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0K CW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVs NA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3 Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwx OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBjbTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5PbiBNb24sIE5vdiAxOCwg MjAxOSBhdCAxNjowNQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+TGl2aW5nb29kLCBKYXNvbiAmbHQ7SmFzb25fTGl2aW5nb29kQGNvbWNhc3QuY29t Jmd0Ow0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+ d3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMS43cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0OyBGcm9tOjxiPg0KPC9iPkFkZCAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmFkZC1ib3VuY2VzQGlldGYub3JnIj5hZGQtYm91bmNlc0BpZXRmLm9y ZzwvYT4mZ3Q7IG9uIGJlaGFsZiBvZiBSb2IgU2F5cmUgJmx0OzxhIGhyZWY9Im1haWx0bzpzYXly ZXJAZ21haWwuY29tIj5zYXlyZXJAZ21haWwuY29tPC9hPiZndDs8YnI+DQo8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7Jmd0OyBJIGFncmVlIHRo YXQgc29tZSBvZiBMaXZpbmdvb2QncyBhZGRpdGlvbnMgYXJlIGEgbGl0dGxlIGJldHRlci4gQnV0 IGhpcyBlZGl0cyBzZWVtIHRvIHJlbW92ZSBvdXQtb2YtYm91bmRzIHRvcGljcywNCjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDox MS43cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0OyZn dDsgd2hpY2ggc2VlbXMgbWlzZ3VpZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij4mZ3Q7 IEl0IHNlZW1lZCB0aGUg4oCYb3V0IG9mIGJvdW5kc+KAmSB0b3BpY3Mgd291bGQgbWFrZSBjb25z ZW5zdXMgaW1wb3NzaWJsZSDigJMgd2hpY2ggd291bGQgdGhlbiBwcmV2ZW50IFdHIGZvcm1hdGlv bi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5TbyBwcm9wb3NpbmcgcmVtb3ZhbCB3 YXMgYW4gYXBwcm9hY2ggdG8gc2VlIGlmIHdlIG1pZ2h0IGlkZW50aWZ5IHRob3NlIGZldyBhcmVh cyB3aGVyZSB0aGVyZSBpcyBhZ3JlZW1lbnQuIEkgYW0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+Jmd0OyA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0Ij5ub3Qgc3VyZSBob3cgdGhhdCBpcyBtaXNndWlkZWQsIGJ1dCBpdCB3b3VsZG7igJl0 IGJlIHRoZSBmaXJzdCB0aW1lIEnigJl2ZSBiZWVuIGFjY3VzZWQgb2YgYmVpbmcgbWlzZ3VpZGVk LCBjb25mdXNlZCwNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0OyA8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5jcmF6eSwgZGVsdWRl ZCBvciB3aGF0ZXZlciBlbHNlLiBMT0wuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5UaGF0IGRvZXMg c2VlbSBhIHNvbWV3aGF0IGlkaW9zeW5jcmF0aWMgdXNlIG9mIHRoZSB3b3JkIG1pc2d1aWRlZC4m bmJzcDsgTGV04oCZcyBob3BlIHRoYXQgb3RoZXJzIHRha2UgYSBzaW1pbGFyIGFwcHJvYWNoIHRv IGhlbHAgcmVhY2ggYSByZWFzb25hYmxlIGNvbnNlbnN1cyBpbiB0aGUgQm9GIHNlc3Npb24gdG9t b3Jyb3cuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPkFuZHJl dzxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_LO2P265MB05735990CD64E8C778BABE88C24D0LO2P265MB0573GBRP_-- From nobody Mon Nov 18 00:25:35 2019 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 C0574120892 for ; Mon, 18 Nov 2019 00:25:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bVr1KCponYza for ; Mon, 18 Nov 2019 00:25:31 -0800 (PST) Received: from mail-ua1-x929.google.com (mail-ua1-x929.google.com [IPv6:2607:f8b0:4864:20::929]) (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 7D7F91200B6 for ; Mon, 18 Nov 2019 00:25:31 -0800 (PST) Received: by mail-ua1-x929.google.com with SMTP id s14so4957293uad.2 for ; Mon, 18 Nov 2019 00:25:31 -0800 (PST) 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=ji/qL+/n70+DmkbBuFtOMlRr4yeF6uDYj+2F6F/7QB4=; b=iPJLC8DQYaB85DyRNtePV+vN2bNY7AE8gHhsZv9M4A2qnfAD7sZUKJcFqR03Esil6p mdIwokzhzdovSdXlODIIPSd3AwqCMA/fGWMhraEw7Cj31p070As3vvX9cKjWhOJyoLln zFSmOMhSw0QqDdY3x1yyYFs0OWanWulpVReefF7IDW4S+WEWJtdpSEYTbSf+iUPYgbSU rE8a0KKu0VgjeuzsaLSfA21PnrjVrELWTogWdd3ndAiXZNeyMTE+PfmmnpjHFmgleRKP IBONly7sVGAQZImIjoXhst0EFYmEgkrgb7NlmEwwP+F04gwGtJ+M9hjkLTZRMXiFaeEE 5K+Q== 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=ji/qL+/n70+DmkbBuFtOMlRr4yeF6uDYj+2F6F/7QB4=; b=fwNI/HTPQPRC4Q4UVC6TDmHb9YKZBh9o1IeNmK5eiZxr7lturpWetH4eOszAjwCpMN bTyx4drZRIQMJewFY8PB3ooALlCQosflejZY+a0ussDa5JFCxQknjB3EeJaXjQK6FCiF hCXkBNPRMSeh26EAnEU477/PE5BWnXxPcTUG4DX+OXQpqfDUeQ0xGBbaUCsLbYPfXOKG 00HFrotMM8vmvv89+Xhk1/cOReROQWcxK8MzFjz3aDsHTwq2g0mlvEhZpDO0zaPF5fLu f5dfGtiU4KbNhsznxXrQjmbOV/RLOy328nXaOW8RhuCVwMAF9pc+RbISggfOpEccg5mo GY7A== X-Gm-Message-State: APjAAAUhalySsra02ILak0h7hZAiZOTOa4WLzQYTgZSO4aloT09BHN+2 h6YwCf0lGURMnn77UTBtvqD10KWOggs74ZNq1UY= X-Google-Smtp-Source: APXvYqw4unmpniRuvOc8S31y4Px9cBO1RMT+X026srIW9k6kp1YGiypE1wDNS5WPS1xC1I2Mu9DiSC3Um3zqaZsrUv8= X-Received: by 2002:ab0:5ea9:: with SMTP id y41mr15870319uag.114.1574065530452; Mon, 18 Nov 2019 00:25:30 -0800 (PST) MIME-Version: 1.0 References: <1E524D44-E988-4E95-8C71-30C5D5BF7225@fugue.com> In-Reply-To: From: Brian Dickson Date: Mon, 18 Nov 2019 16:25:14 +0800 Message-ID: To: Ted Lemon Cc: Ben Schwartz , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000cbc01405979ab0fc" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 08:25:34 -0000 --000000000000cbc01405979ab0fc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable TL;DR: I TL;DR'd the 8484 and misunderstood the whole template semantics. In short, there was a misunderstanding on my part on what the template was and where it came from, and that it was actually outside the scope of the RFC. And, then, what I really should have said/meant was, the port number would be a replacement for (or additional ":port" parameter) to the template URI where it currently needs to be "https://". Apologies, still maybe a bit jet lagged. Brian On Mon, Nov 18, 2019 at 2:17 PM Brian Dickson wrote: > > > On Mon, Nov 18, 2019 at 1:50 PM Ted Lemon wrote: > >> On Nov 17, 2019, at 9:18 PM, Brian Dickson >> wrote: >> >> I think product (coffee/tea) comparisons aren't good analogies, I think >> standards things like railway track gauge, or the NTSC upgrade to suppor= t >> HDTV, or wireless frequency stuff, are better choices. >> E.g. There is some good history on why subways and railroads use >> different standards for track gauge, at least in some cities, IIRC. >> A good use case example would be bridges or tunnels used for multiple >> vehicle types, where being able to operate switches that apply to one se= t >> of colinear tracks but not the other, would be particularly useful, >> something only possible with different rail gauges running literally one >> inside the other. >> >> >> > I'm going to ask follow-up questions here, because I don't think I > understand what you're meaning, and want to understand. > (The hallmark of useful discussion is the listening and comprehension, > rather than the talking part.) > > >> No, the coffee/tea analogy is actually more right. >> > > >> If you have a rail car with the wrong gauge, it won=E2=80=99t run on the= track. >> > > So, what I'm talking about in the analogy, is two tracks running in > parallel, occupying what amounts to a single "right of way", or passagewa= y. > Only one of the two tracks can be used at a time. > For demonstration purposes, suppose one track is 44.3 inches wide, and th= e > other track is 65.3 inches wide (call them https, and newdoh). > > I'm proposing that both the client and server switch to port NEW_VALUE (i= n > the example that would correspond to 653, for identification purposes onl= y). > > The analogy is only useful when both the client and server use the new > value, i.e. the rail car also has the new gauge. > > DoH rail cars would have 65.3 gauge. HTTPS rail cars would have 44.3 gaug= e. > > The two ends of the passageway would have switches for the 65.3 gauge > only, to divert it (analogous to being able to identify and/or block on t= he > basis of port -- or to not block it, if the network policy were > permissive.) > > >> DoH will work fine with any port number. >> > This is not an opinion=E2=80=94it=E2=80=99s a fact. >> > > I believe you are conflating the DoH Template URI, and the content of the > template. > I am proposing a new Template port number, irrespective of what is in the > template. > (I.e. that post-template communications is not port-dependent, as that is > all specified in the template.) > I think there is no disagreement on whether the DoH traffic after being > configured by the template is port-neutral. > > The issue is the first port, which is necessarily required for the DoH > configuration step (which may still require a bootstrap via DNS to find t= he > IP address of the server name at which the Template is served.) > > >> DoH is not useful for its intended purpose if any port other than 443 is >> specified. Again, not opinion, fact. >> > > I am unsure what fact you are implying, as the "intended purpose" is > pretty vague. > > If you mean "privacy-enhanced DNS using TLS encryption", we disagree, as > the only issue is whether the TLS connection can be established. If it is > established, privacy is assured by TLS. > > If you mean the stuff about > > Additionally, the use of the HTTPS default port 443 and the ability > > to mix DoH traffic with other HTTPS traffic on the same connection > can deter unprivileged on-path devices from interfering with DNS > operations and make DNS traffic analysis more difficult. > > > ... then that is a "can", not a "will", and is entirely dependent on whet= her the resolver operator has any HTTPS content other than DNS. > > > If it does not, then the port number is moot, since the preconditions are= not met. > > > This whole discussion that I started, is premised entirely on facts, rega= rding DoH public resolvers not doing any other HTTPS on the IP addresses se= rving DoH. > > > This, IMHO, is what makes the port number question germane, and ripe for = discussion. I see no solid reason to insist on the Template being served on= port 443. > > > While I'd prefer the default port used by the resulting templates (and th= us by the DoH TLS connections) be different, I haven't given it enough thou= ght to figure out if the port number INSIDE the template is as important. > > > Maybe this is where we are talking past each other, and if so, that is pr= obably my fault, and I apologize. > > > So, to restate: I'm suggesting changing the standardized port FOR THE TEM= PLATE RETRIEVAL, without speaking to the in-template URI port number. > > > >> >> So when you say =E2=80=9Cuse a different port,=E2=80=9D you are saying = =E2=80=9Cdrink tea, not >> coffee.=E2=80=9D You are essentially saying =E2=80=9Cdon=E2=80=99t use= DoH.=E2=80=9D >> > > No, I really am saying, different rail gauge, and pick the hot beverage > that suits you. > > Brian > --000000000000cbc01405979ab0fc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
TL;DR:
I TL;DR'd the 8484 and misunderstood the wh= ole template semantics.

In short, there was a misu= nderstanding on my part on what the template was and where it came from, an= d that it was actually outside the scope of the RFC.

And, then, what I really should have said/meant was, the port number wou= ld be a replacement for (or additional=C2=A0":port" parameter) to= the template URI where it currently needs to be "https://".

Apologies, still maybe a bit jet lagged.
Brian

On Mon, Nov 18, 2019 at 2:17 PM Brian Dickson <brian.peter.dickson@gmail.co= m> wrote:


On Mon, Nov 18, 2019 at 1:50 PM Ted = Lemon <mellon@fugu= e.com> wrote:
On Nov 17, 2019, at 9:18 PM, Brian Dickson <brian.peter.dickson@gmail.= com> wrote:
= I think product (coffee/tea) comparisons aren't good analogies, I think= standards things like railway track gauge, or the NTSC upgrade to support = HDTV, or wireless frequency stuff, are better choices.
E.g. There is some good history on why subways and railroads use diff= erent standards for track gauge, at least in some cities, IIRC.
=C2=A0A good use case example would be bridges or tunnels us= ed for multiple vehicle types, where being able to operate switches that ap= ply to one set of colinear tracks but not the other, would be particularly = useful, something only possible with different rail gauges running literall= y one inside the other.


I'm going to ask follow-up questions here, becaus= e I don't think I understand what you're meaning, and want to under= stand.
(The hallmark of useful discussion is the listening and co= mprehension, rather than the talking part.)
=C2=A0
No, the coffee/tea analo= gy is actually more right. =C2=A0
=C2=A0
=
If you have a r= ail car with the wrong gauge, it won=E2=80=99t run on the track. =C2=A0

So, what I'm talking about in = the analogy, is two tracks running in parallel, occupying what amounts to a= single "right of way", or passageway. Only one of the two tracks= can be used at a time.
For demonstration purposes, suppose one t= rack is 44.3 inches wide, and the other track is 65.3 inches wide (call the= m https, and newdoh).

I'm proposing that both = the client and server switch to port NEW_VALUE (in the example that would c= orrespond to 653, for identification purposes only).

The analogy is only useful when both the client and server use the new v= alue, i.e. the rail car also has the new gauge.

Do= H rail cars would have 65.3 gauge. HTTPS rail cars would have 44.3 gauge.

The two ends of the passageway would have switches = for the 65.3 gauge only, to divert it (analogous to being able to identify = and/or block on the basis of port -- or to not block it, if the network pol= icy were permissive.)=C2=A0
=C2=A0
DoH will work fine with any port number.= =C2=A0=C2=A0
This is not an opinion=E2=80=94it=E2=80=99s a fact. = =C2=A0

I believe you are confla= ting the DoH Template URI, and the content of the template.
I am = proposing a new Template port number, irrespective of what is in the templa= te.
(I.e. that post-template communications is not port-dependent= , as that is all specified in the template.)
I think there is no = disagreement on whether the DoH traffic after being configured by the templ= ate is port-neutral.

The issue is the first port, = which is necessarily required for the DoH configuration step (which may sti= ll require a bootstrap via DNS to find the IP address of the server name at= which the Template is served.)=C2=A0
=C2=A0
DoH is not useful for its inte= nded purpose if any port other than 443 is specified. Again, not opinion, f= act.

I am unsure what fact you = are implying, as the "intended purpose" is pretty vague.

If you mean "privacy-enhanced DNS using TLS encryptio= n", we disagree, as the only issue is whether the TLS connection can b= e established. If it is established, privacy is assured by TLS.
<= br>
If you mean the stuff about
= 
Additionally, the use of the HTTPS default=
 port 443 and the ability
   to mix DoH traffic with other H=
TTPS traffic on the same connection
   can deter unprivileged on-path devices from interfering with DNS
   operations and make DNS traffic analysis more difficult.

... then that is a "can", not a "will", a=
nd is entirely dependent on whether the resolver operator has any HTTPS con=
tent other than DNS.

If it does not, then the port number is moot, since =
the preconditions are not met.

<=
font face=3D"arial, sans-serif">This whole discussion that I started, is pr=
emised entirely on facts, regarding DoH public resolvers not doing any othe=
r HTTPS on the IP addresses serving DoH.

This, IMHO, is what makes the por=
t number question germane, and ripe for discussion. I see no solid reason t=
o insist on the Template being served on port 443.

While I'd prefer =
the default port used by the resulting templates (and thus by the DoH TLS c=
onnections) be different, I haven't given it enough thought to figure o=
ut if the port number INSIDE the template is as important.

<= pre style=3D"margin-top:0px;margin-bottom:0px;break-before:page">Maybe this is where we are talking past each other, and if so, that= is probably my fault, and I apologize.

So, to restate: I=
9;m suggesting changing the standardized port FOR THE TEMPLATE RETRIEVAL, w=
ithout speaking to the in-template URI port number.
= =C2=A0
So when you say =E2=80=9Cuse a different port,=E2=80=9D you are= saying =E2=80=9Cdrink tea, not coffee.=E2=80=9D =C2=A0 You are essentially= saying =E2=80=9Cdon=E2=80=99t use DoH.=E2=80=9D

No, I really am saying, different rail gauge, and pick th= e hot beverage that suits you.

Brian=C2=A0
--000000000000cbc01405979ab0fc-- From nobody Mon Nov 18 01:05:21 2019 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 81DF0120047 for ; Mon, 18 Nov 2019 01:05:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=infoblox.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 WcXwS6GpqymZ for ; Mon, 18 Nov 2019 01:05:18 -0800 (PST) Received: from mx0b-00333e01.pphosted.com (mx0b-00333e01.pphosted.com [148.163.141.155]) (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 688361200C7 for ; Mon, 18 Nov 2019 01:05:18 -0800 (PST) Received: from pps.filterd (m0158919.ppops.net [127.0.0.1]) by mx0b-00333e01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAI909Ut009088; Mon, 18 Nov 2019 01:05:13 -0800 Received: from nam05-dm3-obe.outbound.protection.outlook.com (mail-dm3nam05lp2052.outbound.protection.outlook.com [104.47.49.52]) by mx0b-00333e01.pphosted.com with ESMTP id 2wahh21kgu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 18 Nov 2019 01:05:13 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dG0eaurV7uILzX+rSkRXohwEHkcH81EnQt/q41CaeNS/Pw22UORvIx3ZBvBWevIL544wDdCROyadypZW2hrhajGarngv798nhuJfv9RA8RTdOPqceEsbaf6Ny8HX3qqiAggki1gNLoQysJQ0rWoig8W18V84ReYeeIN7pcPhgblqBMuvlGGwnbqZtpNnucEJSzBjwumIsobkrzTxKgbGhkyVf6mTL4jQPR7trJ7UCZ3DX7SvRkjlOmIP0U41Ccn3QO/SWad2UdKepfEyBYCa1blgz+ij18aR2HGZU3QG3TUq7ocWGlEuByigTEHVtsnIFRQ8XBcu+Acz1X5mbnio4g== 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=LxVqyvCq8XdQrY/jSuKpUPBmLEjf1fLB7GgqqgZh//U=; b=Vf5gc0Dl6CYxzSB7nyW4npHQIkM0KqLu3mPI7h/0gimlV4HZ/08FKTNJGHP8N0urABUoaBmPWu2M8Ci/l48Nc0oB7hxDwsokHdWNx7fi4/fe09UgtHhosmO86aiExBue3O7AK8CK7/NFxxJa2nCiieZn6wqcFgNJJz4ycNv2Yf/TDC/x6COf3H74E9O4rAk5p01Mm6ChEvoc2kTzXPb9PJ5JU2QYm2X6qKXlH1eCpJzAgq+TLUHedvIwwN1BY6fP3Ygt2WJGbDGSLODXHsMHx6ajA8Nd+hSuqxkfidrG898qfBIRkcY822h40b13paVf0JKEGvNLXnbqJGfHfn+8Bg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=infoblox.com; dmarc=pass action=none header.from=infoblox.com; dkim=pass header.d=infoblox.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=infoblox.onmicrosoft.com; s=selector2-infoblox-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LxVqyvCq8XdQrY/jSuKpUPBmLEjf1fLB7GgqqgZh//U=; b=B7M2nt6LNlKe9R6AdTEFN/od5nREEzz7JMqmA8lENB5T0QbUnY9vOlOGx+MXjeQIdY2T4hr0hnAWlOcj6XM1AMHQ6ua7wjb5SVvkNUEdxBsNELsrFz64mLDfkTt2okH0H91xCMwSz44wNR23/PjxR5TLIes7MsFZQw2u5f+CR/A= Received: from BYAPR07MB5671.namprd07.prod.outlook.com (20.177.229.88) by BYAPR07MB5720.namprd07.prod.outlook.com (20.178.0.78) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.29; Mon, 18 Nov 2019 09:05:10 +0000 Received: from BYAPR07MB5671.namprd07.prod.outlook.com ([fe80::6c07:500:290b:f923]) by BYAPR07MB5671.namprd07.prod.outlook.com ([fe80::6c07:500:290b:f923%5]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 09:05:10 +0000 From: Paul Adair To: "Livingood, Jason" , Ted Lemon CC: ADD Mailing list Thread-Topic: [Add] [EXTERNAL] Re: Agenda and Revised Charter for the ABCD BoF Thread-Index: AQHVneXAlpoFMOXeHUG+1U4UyaCRzKeRKN6A Date: Mon, 18 Nov 2019 09:05:10 +0000 Message-ID: <29182BD8-1791-4227-91CA-D3E6F9C31AB7@infoblox.com> References: <254AEFB0-F930-466B-8BB6-707D5CE72657@fl1ger.de> <46A8E055-C14B-4927-B348-1B4C44F417DF@fugue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-originating-ip: [203.116.192.194] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b102c82-0f7f-41c5-0e9e-08d76c066a5a x-ms-traffictypediagnostic: BYAPR07MB5720: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(376002)(366004)(346002)(136003)(396003)(199004)(189003)(7736002)(6512007)(486006)(6486002)(476003)(2616005)(446003)(76116006)(33656002)(91956017)(14444005)(76176011)(6506007)(71190400001)(71200400001)(6246003)(11346002)(14454004)(4326008)(81166006)(186003)(81156014)(8936002)(102836004)(66066001)(26005)(6436002)(229853002)(6116002)(5660300002)(478600001)(8676002)(305945005)(256004)(99286004)(86362001)(66946007)(66556008)(2906002)(66476007)(64756008)(66446008)(316002)(110136005)(25786009)(3846002)(58126008)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR07MB5720; H:BYAPR07MB5671.namprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: infoblox.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: HegIMi7sqbf8KF/48pokQV4eQEPpS8BbHx6ntlHJfRtZJ7QOCOkh4vEEIOOAoA+UrcLwRWoz/9xGegmqf7QR40spidgDZzeYm2XUKVIwxDc9XkROcHqU1inlU0A+VOKUROsuhNUFDUhKcaLy5A7ESX0ym474kIJOZSRt5NI+SRCRely/vguoOGwm2MVdqbiJdePj4ZQMPjLuUVS+1roN17z6+4tJH/fKnqAiSLSe1XuCsUFBAYndFwZVCzt561bv2nqJ3aisX5xqy8tAQ6Qg0D6+30PFK/tr9RYjVZSRtvYL0CdNAZdpLUVkY4EsznTVmuNtzpFDdwETVg443hEDCXvFyQf8ljGNC/CQWnju7Qh98VDj9CRbW/wssM05qM3ee7SXlEvxhq/mWMygg4u54XdyctvkMA0Ve5iRFzPNym3/Gcen+Aq/1swOTiQvACgL x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: infoblox.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4b102c82-0f7f-41c5-0e9e-08d76c066a5a X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 09:05:10.4975 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: ccf6dc4a-9fe9-4c20-85a6-46d2709e8435 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: IPiJ+5Hw1Itud/8vL3tm5ZIfbWPEC20VlD2BOg7dDhl3FKOCCuE7Ha7bHshq/HYXXO3LW8Fw3u2JyG2hd7MTOg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR07MB5720 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_01:2019-11-15,2019-11-17 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 malwarescore=0 phishscore=0 lowpriorityscore=0 mlxlogscore=999 impostorscore=0 adultscore=0 spamscore=0 clxscore=1011 mlxscore=0 suspectscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1910280000 definitions=main-1911180081 Archived-At: Subject: Re: [Add] [EXTERNAL] Re: Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 09:05:20 -0000 QmxvY2tpbmcgYWNjZXNzIHRvIGFsbCB1bmFwcHJvdmVkIHJlY3Vyc2l2ZSByZXNvbHZlcnMgKGJl IHRoZXkgb24gb3Igb2ZmIG5ldHdvcmspIGhhcyBiZWVuIGEgYmVzdCBwcmFjdGljZSByZWNvbW1l bmRhdGlvbiBvZiBJbmZvYmxveCB0byBvdXIgZW50ZXJwcmlzZSBjdXN0b21lcnMgZm9yIGEgdmVy eSBsb25nIHRpbWUuICBXZSBoYXZlIHVwZGF0ZWQgb3VyIHJlY29tbWVuZGF0aW9ucyBhcyBhIHJl c3VsdCBvZiBEb0guIFdlIG5vdyByZWNvbW1lbmQgZW50ZXJwcmlzZXMgYmxvY2sgdGhlIFVSTHMs IEZRRE5zLCBhbmQgSVAgYWRkcmVzc2VzIG9mIGFsbCB1bmFwcHJvdmVkIERvSCBzZXJ2aWNlcyBh dCBhbnkgcmVsZXZhbnQgZW5mb3JjZW1lbnQgcG9pbnRzIHRoZXkgbWF5IGhhdmUgKFJQWiwgU1dH LCBOR0ZXLCBIb3N0IEZXLCBldGMpLg0KDQpQYXVsIEFkYWlyDQoNCu+7v09uIDExLzE4LzE5LCAz OjU2IFBNLCAiQWRkIG9uIGJlaGFsZiBvZiBMaXZpbmdvb2QsIEphc29uIiA8YWRkLWJvdW5jZXNA aWV0Zi5vcmcgb24gYmVoYWxmIG9mIEphc29uX0xpdmluZ29vZEBjb21jYXN0LmNvbT4gd3JvdGU6 DQoNCiAgICBGcm9tOiBUZWQgTGVtb24gPG1lbGxvbkBmdWd1ZS5jb20+DQogICAgPj4gLSBQb3Rl bnRpYWwgdXNlIG9mIGFsdGVybmF0aXZlIGFwcGxpY2F0aW9uIHBvcnQgbnVtYmVycyBpbiBzb21l IGNvbnRyb2xsZWQgZW52aXJvbm1lbnRzIChlLmcuIG1hbmFnZWQgZW50ZXJwcmlzZSBlbnZpcm9u bWVudHMpLCBpbmNsdWRpbmcgdGhlIHByb3MvY29ucyBhbmQgaW1wbGljYXRpb25zIG9mIHNlY3Vy aXR5IGRvd25ncmFkZSBhbmQvb3IgZGV0ZWN0YWJpbGl0eSBpbiB0aGVzZSBlbnZpcm9ubWVudHMN CiAgICANCiAgICA+IFRoaXMgaXMgcHJlc3VtaW5nIGEgc29sdXRpb24uICBDYW4gd2UgY2hhbmdl IGl0IHRvIGp1c3QgdGFsayBhYm91dCB0aGUgcHJvYmxlbT8NCiAgICANCiAgICA+IC0gVGhlIHBy b2JsZW0gb2YgZGV0ZWN0aW5nIGFuZCBwcmV2ZW50aW5nIHRoZSB1c2Ugb2YgRG9IIGluIG1hbmFn ZWQgZW52aXJvbm1lbnRzIHdoZXJlIHRoZSBuZXR3b3JrIG9wZXJhdG9yIG5lZWRzIGNvbnRyb2wg b2YgRE5TIHF1ZXJpZXMuDQogICAgDQogICAgW0pMXSBUaGF0IGNvdWxkIHdvcmsgYXMgd2VsbC4g SSB3b25kZXIgdGhvdWdoIGlmIHRoZXJlIGFyZSB1c2UgY2FzZXMgd2hlcmUgYW4gZW50ZXJwcmlz ZSBtYXkgbm90IHdhbnQgdG8gcHJldmVudCBEb0ggd3JpdCBsYXJnZSwganVzdCB0byBvZmYtbmV0 IERvSCBzZXJ2ZXJzIChzL2RldGVjdGluZyBhbmQvZGV0ZWN0aW5nIG9yID8pLiBBcyBJIHRob3Vn aHQgYWJvdXQgaXQsIHBlcmhhcHMgdGhlcmUgaXMgdmFsdWUgaW4gZG9jdW1lbnRpbmcgd2h5IGVu dGVycHJpc2VzIG1pZ2h0IHdhbnQgdG8gZG8gdGhpcywgYXMgd2VsbCBhcyB0aGUgc2VjdXJpdHkg JiBwcml2YWN5IHByb3MgYW5kIGNvbnMgb2YgZG9pbmcgc28sIGV0Yy4gQWdhaW4sIG5vdCBzdXJl IEkgaGF2ZSBhIHBvc2l0aW9uIG9uIHRoaXMgZGVsaXZlcmFibGUgLSBJJ20ganVzdCB0cnlpbmcg dG8gc2VlIGlmIGl0J3MgcG9zc2libGUgdG8gZmxlc2ggb3V0IHNvbWUgb2YgdGhlIGNoYXJ0ZXIg aXRlbXMgYW5kIGZyYW1lIHRoZW0gc28gdGhhdCBwZXJoYXBzIGNvbnNlbnN1cyBvbiBpdCBtYXkg YmUgcG9zc2libGUuDQogICAgDQogICAgDQogDQoNCg== From nobody Mon Nov 18 01:26:47 2019 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 37AF612086D for ; Mon, 18 Nov 2019 01:26:45 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.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 oy6f_ab802nI for ; Mon, 18 Nov 2019 01:26:43 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100069.outbound.protection.outlook.com [40.107.10.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F191E12004F for ; Mon, 18 Nov 2019 01:26:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BmwL575978SgccPs0o8UCEKDNkzDTt8nFjH0CsLiELLXkPD69Rtq65GfzbITuBcaGcNulUewIi+C2HRpaC4OwdStUlaQwJ5B9toj7DExA6ubq/7YYSBIvMOZmfOLJ1MSMdJD1ZEqTJYief2MDeklHvuMbLlLI7ZAmTbXR9yHEpJLZ2N91xU89sx3sqkX7P1VxqOb1uMsJ8zkqVJ+j7maKIqVNrb6LiLFFncpicYPbLwiIhq9M37K0rLrwjqjdwd4A4jly3GRN4ChTErs14+Lh3RIJmgkDOx2nsELwgGrZa4+IM8fwP8tQTK8enitZbPRsF6oxQmhiwKJfZz5hMDPvw== 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=msaCxWBFaGApe2KjTjIUyaeJKWavc2tI5KGrPohhUDk=; b=Qt1efc4iJTPPrgkvk87OBLOAESg/c9j3rYqyHc+GY2I6EFSQBwLGkFDmKUKyQIInb+82naooyI2UgD0GF8Pk8DBTwJdFWegM8Oh15T9HnQDu+LWZVOc/xnFw/z6Zgkly2SrLZCsn6MgU52vMhZSH2upoxLsfmu0ARmONDxp01cQWSFKoJYTC/EQdXxviDsgcjSAe4pRPQzx1jZazfnKqdyF0zsi2kj1b6U1tynCiEVP93Bb1BcDkvSX7NfuT+EViOudrWhq/y/iB3ZkFOi1IKToBUl/gvbz5rlJ8U/yxxTrZAkV4wY1MYOwjFYKRV1rodFw9HfL+r93ZYLOlq9bTkA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=msaCxWBFaGApe2KjTjIUyaeJKWavc2tI5KGrPohhUDk=; b=M2/+P8UkeTs8bGE5UCwN8qS1LrKLZqU5baQI3Dtl5XinxmWQeRzyLeCP/FniyLc2qufDkpIUacHDoE3ziJlmaH2N8h+9Sjtl9lHmuNCjX9nJ1Jals9ymoMqQQXs/sJuK05sc6klOOaki9bCpfR3lvIDlsvvKMUgtlvpC0WyyakQ= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB1566.GBRP265.PROD.OUTLOOK.COM (20.176.142.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.22; Mon, 18 Nov 2019 09:26:40 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712%7]) with mapi id 15.20.2451.029; Mon, 18 Nov 2019 09:26:40 +0000 From: Andrew Campling To: Ted Lemon , Brian Dickson CC: Ben Schwartz , ADD Mailing list Thread-Topic: [Add] Agenda and Revised Charter for the ABCD BoF Thread-Index: AQHVnfJGpfNr3Zq+dUejyYxWE6oXjA== Date: Mon, 18 Nov 2019 09:26:40 +0000 Message-ID: References: <1E524D44-E988-4E95-8C71-30C5D5BF7225@fugue.com> In-Reply-To: <1E524D44-E988-4E95-8C71-30C5D5BF7225@fugue.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [89.187.165.42] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 50cb435f-8b49-48c2-5d19-08d76c096b37 x-ms-traffictypediagnostic: LO2P265MB1566: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(396003)(346002)(376002)(39830400003)(199004)(189003)(508600001)(76176011)(74316002)(33656002)(14454004)(2906002)(44832011)(25786009)(99286004)(486006)(110136005)(229853002)(71190400001)(71200400001)(76116006)(4326008)(316002)(6436002)(54906003)(14444005)(6246003)(476003)(55016002)(6306002)(54896002)(9686003)(4744005)(446003)(8936002)(5660300002)(790700001)(256004)(6116002)(11346002)(3846002)(6506007)(102836004)(86362001)(53546011)(26005)(7696005)(66066001)(66446008)(8676002)(52536014)(81156014)(81166006)(7736002)(186003)(64756008)(66556008)(66946007)(66476007)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB1566; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: u5zlmS5xa2Ed63lhzwLVBUnHvBaAHrO3+77vIsa//1ypwKeSz0DaIC5G3hLxqhiq9n4SLZgxzvddq6vTI7VPqV9geJHzX0j4FxnHdD4cYr2MXXiiOXAxYIZM1zzbtTakWPNG3wrCTaHBWOnPjSWcu5SzLn8dSs20goq32D1ljKZDTiMwz9xIOubmmk9w33DgFzsjrv3wmOQ/jI0RJs8OPaeuo6MATnh82VUXjjc5avq4IHWcSICdF/4ijGODv4+mlOPTPCHMmtL2QAVy62CUeBS84+bhsJ/FaqXH3BuxkhkbxxHPS8PIvgaZjQ4fF1XfY2jA4lnMXLP3UJbdve0NTokBFQNKWR3G2Ezo6vj4XNOEtZFcF6XykzbbT78isCR87/9mpl9cXDg1vfrO8v0obZ55sMqXU2xESEEnvnlS7eEGri4daWR1gkLZfWNQjdt+ x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB057321BF69D185CF3A2EC592C24D0LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 50cb435f-8b49-48c2-5d19-08d76c096b37 X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Nov 2019 09:26:40.4840 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: lWJ+5jUDnWtSzjOgRL1HYHAja3kvp371CTjYaVcJzK66qdDp2GrAcCwPqLtow01NWdm/b+8sURnzYmqHOldfUe5LmR4QX+rp52TOUQFum4c= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB1566 Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 09:26:45 -0000 --_000_LO2P265MB057321BF69D185CF3A2EC592C24D0LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gTm92IDE4LCAyMDE5LCBhdCAxMzo1MCwgVGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPiB3 cm90ZToNCg0KPiBDaGFuZ2luZyB0aGUgcG9ydCBudW1iZXIgd2lsbCBkZWZpbml0ZWx5IGJlIGln bm9yZWQgYnkgYW55Ym9keSB3aG8gbmVlZHMgRG9IIGZvciBpdHMgaW50ZW5kZWQgcHVycG9zZSwN Cj4gc28gaXTigJlzIGEgbm8tb3AuDQoNCkkgYmVsaWV2ZSB0aGF0IG9uZSBvZiB0aGUgaXNzdWVz IHRoYXQgaXMgaGluZGVyaW5nIGFuIGVmZmVjdGl2ZSBkaXNjdXNzaW9uIGFib3V0IERvSCBpcyB0 aGUgbGFjayBvZiBkb2N1bWVudGVkIHVzZSBjYXNlcyB0aGF0IGVuYWJsZSBhbiBvYmplY3RpdmUg YXNzZXNzbWVudCBvZiB2YXJpb3VzIHByb3Bvc2Fscy4gIEl0IHdvdWxkIGJlIHBhcnRpY3VsYXJs eSBoZWxwZnVsIGZvciB0aGUgV0cgY2hhcnRlciB0byBpbmNsdWRlIHRoZSBjYXB0dXJlLCBkb2N1 bWVudCBhbmQgdGhlbiB2YWxpZGF0ZSB0aGUgcmVsZXZhbmNlIG9mIHVzZSBjYXNlcyBzbyB0aGF0 IHdlIGhhdmUgYW4gYWdyZWVkIHNldCBmb3IgZnV0dXJlIHJlZmVyZW5jZS4NCg0KPiBEaXNhYmxp bmcgRG9IIHdvbuKAmXQgaGFwcGVuIGlmIHNvbWVvbmUgd2FudHMgaXQsIGJlY2F1c2UgaXTigJlz IHVwIHRvIHRoZW0gdG8gZGVjaWRlLCBub3QgdXAgdG8gdXMuDQoNCkkgc3VzcGVjdCB0aGF0IG9u ZSBvZiB0aGUgYXJlYXMgb2YgYW5nc3QgaXMgd2hvIHRoYXQg4oCcc29tZW9uZeKAnSBpcyDigJMg aWUgd2hldGhlciBpdOKAmXMgYW4gYWN0dWFsIGVuZCB1c2VyIChpbmRpdmlkdWFsIG9yIGVudGVy cHJpc2UpIG9yIHdoZXRoZXIgaXTigJlzIGEgdGVjaCBjb21wYW55IGRyaXZlbiBieSBhIOKAnGNv bW1lcmNpYWwgaW1wZXJhdGl2ZeKAnS4gIEFzIGFib3ZlLCBkb2N1bWVudGVkIHVzZSBjYXNlcyB3 b3VsZCBoZWxwIGhlcmUuDQoNCg0KQW5kcmV3DQoNCg== --_000_LO2P265MB057321BF69D185CF3A2EC592C24D0LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxp Lk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlv cml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1i b3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2LjBwdDsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmln aHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEw LjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLUdCIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PbiBOb3YgMTgsIDIwMTksIGF0IDxzcGFuIGxhbmc9IkVOLVVTIj4xMzo1 MDwvc3Bhbj4sIDxzcGFuIGxhbmc9IkVOLVVTIj4NClRlZCBMZW1vbiAmbHQ7bWVsbG9uQGZ1Z3Vl LmNvbSZndDsgPC9zcGFuPndyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiPiZndDsg PC9zcGFuPjwvYj5DaGFuZ2luZyB0aGUgcG9ydCBudW1iZXIgd2lsbCBkZWZpbml0ZWx5IGJlIGln bm9yZWQgYnkgYW55Ym9keSB3aG8gbmVlZHMgRG9IIGZvciBpdHMgaW50ZW5kZWQgcHVycG9zZSwN CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPiZndDsgPC9zcGFuPnNvIGl04oCZcyBhIG5vLW9wLiAmbmJzcDsgPG86cD4N CjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkkgYmVsaWV2ZSB0aGF0IG9uZSBvZiB0aGUgaXNzdWVz IHRoYXQgaXMgaGluZGVyaW5nIGFuIGVmZmVjdGl2ZSBkaXNjdXNzaW9uIGFib3V0IERvSCBpcyB0 aGUgbGFjayBvZiBkb2N1bWVudGVkIHVzZSBjYXNlcyB0aGF0IGVuYWJsZSBhbiBvYmplY3RpdmUg YXNzZXNzbWVudCBvZiB2YXJpb3VzIHByb3Bvc2Fscy4mbmJzcDsgSXQgd291bGQgYmUgcGFydGlj dWxhcmx5DQogaGVscGZ1bCBmb3IgdGhlIFdHIGNoYXJ0ZXIgdG8gaW5jbHVkZSB0aGUgY2FwdHVy ZSwgZG9jdW1lbnQgYW5kIHRoZW4gdmFsaWRhdGUgdGhlIHJlbGV2YW5jZSBvZiB1c2UgY2FzZXMg c28gdGhhdCB3ZSBoYXZlIGFuIGFncmVlZCBzZXQgZm9yIGZ1dHVyZSByZWZlcmVuY2UuJm5ic3A7 DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyBEaXNhYmxpbmcgRG9IIHdvbuKAmXQgaGFwcGVuIGlmIHNvbWVv bmUgd2FudHMgaXQsIGJlY2F1c2UgaXTigJlzIHVwIHRvIHRoZW0gdG8gZGVjaWRlLCBub3QgdXAg dG8gdXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkkgc3VzcGVjdCB0aGF0 IG9uZSBvZiB0aGUgYXJlYXMgb2YgYW5nc3QgaXMgd2hvIHRoYXQg4oCcc29tZW9uZeKAnSBpcyDi gJMgaWUgd2hldGhlciBpdOKAmXMgYW4gYWN0dWFsIGVuZCB1c2VyIChpbmRpdmlkdWFsIG9yIGVu dGVycHJpc2UpIG9yIHdoZXRoZXIgaXTigJlzIGEgdGVjaCBjb21wYW55IGRyaXZlbiBieSBhIOKA nGNvbW1lcmNpYWwgaW1wZXJhdGl2ZeKAnS4mbmJzcDsgQXMgYWJvdmUsDQogZG9jdW1lbnRlZCB1 c2UgY2FzZXMgd291bGQgaGVscCBoZXJlLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5BbmRyZXc8bzpwPjwvbzpw Pjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_LO2P265MB057321BF69D185CF3A2EC592C24D0LO2P265MB0573GBRP_-- From nobody Mon Nov 18 02:15:05 2019 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 19A4A120851 for ; Mon, 18 Nov 2019 02:15:04 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 dfNDHjANKGxO for ; Mon, 18 Nov 2019 02:15:02 -0800 (PST) Received: from mail-qt1-x82b.google.com (mail-qt1-x82b.google.com [IPv6:2607:f8b0:4864:20::82b]) (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 DDFF41207FE for ; Mon, 18 Nov 2019 02:15:01 -0800 (PST) Received: by mail-qt1-x82b.google.com with SMTP id j5so18142757qtn.10 for ; Mon, 18 Nov 2019 02:15:01 -0800 (PST) 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=Kdc7ooTCwOEaT+B4LEHe23GKjlb7NS/oPaQK8OIbiIE=; b=PDacmqwkgN0aFgRAwu7I+/fJ/yt6CXi69uF8pI9OfRCwlXUyCeLF7KpWwco/F/7jbx YJfpDiXeRA2bW8nEXhWAtyZC/7ujWuQUQYABLJgvBna4U8k2DjUBBQeqzmjpmXSn46HE e9dhORRNHsKt0FROVtAsUskD3xvytvhN2UQAnBH5P4Lc/11O/Ft1qf7m8/VB5RHELB+5 i/7upxsnQ5Exavm/K+GOW9XqKq40/bOFMqF22M2KtBlc1Xze+umqAsL9P99660juJXhk FF37tIeXyldaHp3sdZHBzjc3hxhN6/7pt5F25HoW1Bo8SfpKCFmwAxY58F/pdzge5B4j W0pA== 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=Kdc7ooTCwOEaT+B4LEHe23GKjlb7NS/oPaQK8OIbiIE=; b=qT5FusYIxTHyCbiTRrglqoSu+RgGcVe/fkiwkwbon/1mC/ai828qghE7IpULxRtp2B mv+bZjZjfxW76hVqxiPNZDQajKKDd2bOEVJ0/G8ysjqFjuP6Hu5CNkaFmhyrseLucZoz nlauqwTHepghn/jrAFsz6BD81fqpwMwBzrETpHpDn2ASf7hMHRTsEkditQDABsDcISwG /3Lv8t2XCLSmN5f7bXFOoGynnatGKcq1dZM4HCygzTz4YN3s2ZnvDXDXTZS9ePcJ+BiM IBVTtgB9E6soT+QyjXhH4PA0jcPioScAH47722lDnQq/HfGjeB6flPBPLKbMPj/+3MRs 0g1g== X-Gm-Message-State: APjAAAVGOVYD9o5jrc3C6YyDqArL74jp+H2jmpzDeAIB0+oK8gtFJoxS o/a1ob42OZbhHBtvB5TBg0RvxQ== X-Google-Smtp-Source: APXvYqyPMobwGJsei3pLyqn7zkNT+YFi2phRLKqGXsse+TvTBFS9QUU9zlDmvkekMOnlsMYETHdLUA== X-Received: by 2002:ac8:ff5:: with SMTP id f50mr27140034qtk.2.1574072100917; Mon, 18 Nov 2019 02:15:00 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:452d:641f:4592:1697? ([2601:18b:300:36ee:452d:641f:4592:1697]) by smtp.gmail.com with ESMTPSA id l93sm9967503qtd.86.2019.11.18.02.14.59 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 02:15:00 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_270F5CB7-061B-4397-9DDA-C413694DCEAE" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.1\)) Date: Mon, 18 Nov 2019 05:14:59 -0500 In-Reply-To: Cc: Brian Dickson , Ben Schwartz , ADD Mailing list To: Andrew Campling References: <1E524D44-E988-4E95-8C71-30C5D5BF7225@fugue.com> X-Mailer: Apple Mail (2.3608.40.2.2.1) Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 10:15:04 -0000 --Apple-Mail=_270F5CB7-061B-4397-9DDA-C413694DCEAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 18, 2019, at 4:26 AM, Andrew Campling = wrote: > I believe that one of the issues that is hindering an effective = discussion about DoH is the lack of documented use cases that enable an = objective assessment of various proposals. It would be particularly = helpful for the WG charter to include the capture, document and then = validate the relevance of use cases so that we have an agreed set for = future reference.=20 The protocol is already documented in an RFC, and is being deployed by = vendors. So there are already use cases. You=E2=80=99re welcome to = document them if you think it=E2=80=99s useful. I don=E2=80=99t think = we need an IETF working group for that. > > Disabling DoH won=E2=80=99t happen if someone wants it, because = it=E2=80=99s up to them to decide, not up to us. > I suspect that one of the areas of angst is who that =E2=80=9Csomeone=E2= =80=9D is =E2=80=93 ie whether it=E2=80=99s an actual end user = (individual or enterprise) or whether it=E2=80=99s a tech company driven = by a =E2=80=9Ccommercial imperative=E2=80=9D. As above, documented use = cases would help here. I think it=E2=80=99s inappropriate to describe this as =E2=80=9Cangst.=E2=80= =9D It=E2=80=99s pretty clear how to block DoH. It=E2=80=99s pretty = clear in what cases this makes sense. What I=E2=80=99m getting at here = is that in most cases, the person making the decision is the host = operator, not the network operator. Documenting how a network operator = would do this seems like it would be useful; my point was that the = network operator can=E2=80=99t do this by convincing the operators of = the host and the resolver to use a different port, because from their = perspective they have no choice. So if you start out by saying = =E2=80=9Cfirst, get the operators of the endpoints to use a different = port,=E2=80=9D then whatever you do after that will be of no use at all. = Any interception or blocking you=E2=80=99re going to do has to work = when the port number is 443, or you are wasting your time. --Apple-Mail=_270F5CB7-061B-4397-9DDA-C413694DCEAE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 18, 2019, at 4:26 AM, Andrew Campling <andrew.campling@419.consulting> wrote:
I believe that one of the issues = that is hindering an effective discussion about DoH is the lack of = documented use cases that enable an objective assessment of various = proposals.  It would be particularly helpful for the WG charter to = include the capture, document and then validate the relevance of use = cases so that we have an agreed set for future = reference. 

The protocol is already documented in an RFC, and = is being deployed by vendors.   So there are already use = cases.  =  You=E2=80=99re welcome to document them if you think it=E2=80=99s = useful.  I don=E2=80=99t think we need an IETF working group for = that.

> Disabling DoH won=E2=80=99t = happen if someone wants it, because it=E2=80=99s up to them to decide, = not up to us.
I suspect that one of the areas of = angst is who that =E2=80=9Csomeone=E2=80=9D is =E2=80=93 ie whether = it=E2=80=99s an actual end user (individual or enterprise) or whether = it=E2=80=99s a tech company driven by a =E2=80=9Ccommercial = imperative=E2=80=9D.  As above, documented use cases would help = here.

I = think it=E2=80=99s inappropriate to describe this as =E2=80=9Cangst.=E2=80= =9D   It=E2=80=99s pretty clear how to block DoH.  It=E2=80=99s = pretty clear in what cases this makes sense.  What I=E2=80=99m = getting at here is that in most cases, the person making the decision is = the host operator, not the network operator.  Documenting how a = network operator would do this seems like it would be useful; my point = was that the network operator can=E2=80=99t do this by convincing the = operators of the host and the resolver to use a different port, because = from their perspective they have no choice.   So if you start out = by saying =E2=80=9Cfirst, get the operators of the endpoints to use a = different port,=E2=80=9D then whatever you do after that will be of no = use at all.  Any interception or blocking you=E2=80=99re going to = do has to work when the port number is 443, or you are wasting your = time.

= --Apple-Mail=_270F5CB7-061B-4397-9DDA-C413694DCEAE-- From nobody Mon Nov 18 03:24:26 2019 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 E2DC412092B for ; Mon, 18 Nov 2019 03:24:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjlnY27q1u1r for ; Mon, 18 Nov 2019 03:24:21 -0800 (PST) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 AF9F712008B for ; Mon, 18 Nov 2019 03:24:21 -0800 (PST) Received: by mail-ua1-x92e.google.com with SMTP id a13so5115744uaq.0 for ; Mon, 18 Nov 2019 03:24:21 -0800 (PST) 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=YGv5k1eci5FxfkzZKXa+Q58Exj5UrOLt1cEQ5TABv+M=; b=Enr8/x2FxEAvL1/LcS+doTpo5QXuzDWMtucMvOaLmAKWcTXBNAS8IK8801fOHTsJr5 RTu1Hem/FBNrwraRWTgPTKp8Dw//0QLna69oDw7mTbiq5y51TxxYkxB7yKff4HdKzjWS sK3vJsUT6Xi5oj8ObP2KnfPZN27U4o4bVV42HwcdINOrVrXoMQpdb2wK4BNVK5CDw1wr FjO0SI/6SdT59WyF/b+G7bJDXcc91hqT5TO2yYtmIVyoZOl8wbZstk+8H/qxOm2OxdKA EKbnL5v8tuRPE2Brp6JeYqRL79ywIXsiA61Xd5wNQcLWpfGAx29QhEfHTq/r0MK0wAi3 uotQ== 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=YGv5k1eci5FxfkzZKXa+Q58Exj5UrOLt1cEQ5TABv+M=; b=q7kXc5S+yyc4Lmr/47luFHnpb6VX7ZV94fczpJ+9IzfPI96WHeaO38ry9CjpH6Z6Dh HDYULfKk+TNaAGd2SRXWkPx63QsH9+e2RULb+xsSSH6TS/bvEZqKd9F04zhOnZlZhcC3 D+I3aPR4E9ZQZgvGvIKfMIPgYrIFORC0evn4vMwFldFSX8MoOt+pnK+UMrcl8wCZhF2R ymGgZVeP1+ayZ6c0J4wFqvzmuPK6X/gY2Pz0GeXkxc5Er8/kx2HP4R456aQRR5yw2b1M 3a8KecpdsCF/X6XDRYT9UhtllqBdFW02rKpffDYE3i+RFIrssJnkwze/L3drK32kG2n9 EF/Q== X-Gm-Message-State: APjAAAW67/qq2mrtel7GE56mmVoGQEqt9b3DateKVvFoMdV0ZLIRCinC bHG+vAqGUxqj7OD2fOpPHBLs5gQO+8lHHnARWDx+7gk9cjI= X-Google-Smtp-Source: APXvYqzwgu4zVML8n1SIl8aojaWWru/QRE7Y7aWpczzW54nmNBiQaIEqBdPsrq37T74dQfu599yZirAWt65/iIQqTpU= X-Received: by 2002:ab0:786:: with SMTP id c6mr16795346uaf.62.1574076260597; Mon, 18 Nov 2019 03:24:20 -0800 (PST) MIME-Version: 1.0 References: <1E524D44-E988-4E95-8C71-30C5D5BF7225@fugue.com> In-Reply-To: From: Brian Dickson Date: Mon, 18 Nov 2019 19:24:03 +0800 Message-ID: To: Ted Lemon Cc: Andrew Campling , Ben Schwartz , ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000005cc3d305979d3083" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 11:24:24 -0000 --0000000000005cc3d305979d3083 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2019 at 6:15 PM Ted Lemon wrote: > On Nov 18, 2019, at 4:26 AM, Andrew Campling < > andrew.campling@419.consulting> wrote: > > I believe that one of the issues that is hindering an effective discussio= n > about DoH is the lack of documented use cases that enable an objective > assessment of various proposals. It would be particularly helpful for th= e > WG charter to include the capture, document and then validate the relevan= ce > of use cases so that we have an agreed set for future reference. > > > The protocol is already documented in an RFC, and is being deployed by > vendors. So there are already use cases. You=E2=80=99re welcome to do= cument > them if you think it=E2=80=99s useful. I don=E2=80=99t think we need an = IETF working group > for that. > > > Disabling DoH won=E2=80=99t happen if someone wants it, because it=E2= =80=99s up to them > to decide, not up to us. > I suspect that one of the areas of angst is who that =E2=80=9Csomeone=E2= =80=9D is =E2=80=93 ie > whether it=E2=80=99s an actual end user (individual or enterprise) or whe= ther it=E2=80=99s > a tech company driven by a =E2=80=9Ccommercial imperative=E2=80=9D. As a= bove, documented > use cases would help here. > > > Documenting how a network operator would do this seems like it would be > useful; my point was that the network operator can=E2=80=99t do this by c= onvincing > the operators of the host and the resolver to use a different port, becau= se > from their perspective they have no choice. > Just to clarify this assertion, "they have no choice" -- is that solely because of what is specified by RFC8484? (It's not a rhetorical question, btw.) > So if you start out by saying =E2=80=9Cfirst, get the operators of the en= dpoints > to use a different port,=E2=80=9D then whatever you do after that will be= of no use > at all. Any interception or blocking you=E2=80=99re going to do has to w= ork when > the port number is 443, or you are wasting your time. > This presumes that the process of "get the operators of the endpoints to use a different port" is not accomplished by doing an RFC8484-bis to change the port. If doing a -bis were done, does that change things? (That presupposes a lot of things, of course, but it's an IETF document, and can be updated by the IETF. That happens all the time, with "updates" or "obsoletes" RFCs.) (And yes, I realize that deployments would have to have updates done on both the resolver operator side, and on the client side.) (It may be necessary to also specify a new namespace specifier analogous to "https:", call it "doh:". I believe the contents of 2818 could be trivially transformed by modifying the document name, and changing sections 2.3 and 2.4 to specify "doh:" and the new port number, and doing basic housekeeping. Then 8484-bis would refer to this in place of 2818, and use the new doh: URI component in place of https: .) So, starting the question over again, this time without excluding doing a -bis as the mechanism on changing the port number. If the port number was different, the mechanisms available for a network operator to block DoH would include doing so strictly on the basis of port number. And, if the network operator did not block any DoH servers, or only blocked DoH servers not on the TRR list, DoH to those servers would work exactly as they would have done had the port number remained 443. The caveat here is I think this -bis would need to either require the new port be used exclusively by clients (no client-side override of port number via template configuration), or to exclude 443 as an override port number. (I realize that kind of seems draconian, because it is. It's the logical result of facilitating a scalable way for network operators to block DoH.) This may seem contentious, because of the original desire to have DoH and HTTPS traffic muxed together on the same IP addresses. However, the current reality is that isn't happening to the best of my knowledge, and I am unaware of any large public resolver operator committing to doing so. (Large =3D=3D enough HTTPS traffic to dwarf expected DoH traffic, and production resolver, meaning with geographically redundant anycast addressing and > O(10K qps) DNS traffic.) I.e. if the port 443 justification has become moot, I think it is reasonable to look at this pragmatically. All the public TRR-list (and similar) DoH operators' DoH traffic can be identified by IP address alone, and blocked the same way. The remaining issue is the ability of network operators to do any of several things: - Identify all DoH traffic regardless of destination - Block all DoH traffic - Reactively block individual DoH destinations that have been identified as problematic (regardless of how/why) - Accommodate mandated legal filtering requirements within appropriate jurisdictions (e.g. in the UK) by limiting resolver choice to resolvers which comply with those mandates - Limit DoH destinations to a white list of addresses (e.g. TRR lists) And to reiterate: the purpose of this is to reach a balance, and to specifically encourage and promote the use of TLS for privacy on DNS traffic, speaking only for myself at least. Brian --0000000000005cc3d305979d3083 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 18, 2019 at 6:15 PM Ted L= emon <mellon@fugue.com> wrote= :
On Nov 18, 2019, at 4:26 AM, Andrew Campling &l= t;andre= w.campling@419.consulting> wrote:
I believe that one of the issues that is hindering an effective discu= ssion about DoH is the lack of documented use cases that enable an objectiv= e assessment of various proposals.=C2=A0 It would be particularly helpful f= or the WG charter to include the capture, document and then validate the re= levance of use cases so that we have an agreed set for future reference.=C2= =A0

The protocol is already do= cumented in an RFC, and is being deployed by vendors. =C2=A0 So there are a= lready use cases.=C2=A0 =C2= =A0You=E2=80=99re welcome to document them if you think it=E2=80=99s useful= .=C2=A0 I don=E2=80=99t think we need an IETF working group for that.

> Disabling DoH won=E2=80=99t happen if someone wants it= , because it=E2=80=99s up to them to decide, not up to us.
= I suspect that one of the areas of angst is who that =E2=80=9Csomeone=E2=80= =9D is =E2=80=93 ie whether it=E2=80=99s an actual end user (individual or = enterprise) or whether it=E2=80=99s a tech company driven by a =E2=80=9Ccom= mercial imperative=E2=80=9D.=C2=A0 As above, documented use cases would hel= p here.

=C2=A0Documenting how a net= work operator would do this seems like it would be useful; my point was tha= t the network operator can=E2=80=99t do this by convincing the operators of= the host and the resolver to use a different port, because from their pers= pective they have no choice.=C2=A0=C2=A0

<= /div>
Just to clarify this assertion, "they have no choice" -= - is that solely because of what is specified by RFC8484?
(It'= ;s not a rhetorical question, btw.)


=C2=A0
So if you start out by saying =E2=80= =9Cfirst, get the operators of the endpoints to use a different port,=E2=80= =9D then whatever you do after that will be of no use at all.=C2=A0 Any int= erception or blocking you=E2=80=99re going to do has to work when the port = number is 443, or you are wasting your time.
<= br>
This presumes that the process of "get the operators of = the endpoints to use a different port" is not accomplished by doing an= RFC8484-bis to change the port.

If doing a -bis w= ere done, does that change things?=C2=A0
(That presupposes a lot = of things, of course, but it's an IETF document, and can be updated by = the IETF. That happens all the time, with "updates" or "obso= letes" RFCs.)
(And yes, I realize that deployments would hav= e to have updates done on both the resolver operator side, and on the clien= t side.)
(It may be necessary to also specify a new namespace spe= cifier analogous to "https:", call it "doh:". I believe= the contents of 2818 could be trivially transformed by modifying the docum= ent name, and changing sections 2.3 and 2.4 to specify "doh:" and= the new port number, and doing basic housekeeping. Then 8484-bis would ref= er to this in place of 2818, and use the new doh: URI component in place of= https: .)

So, starting the question over again, t= his time without excluding doing a -bis as the mechanism on changing the po= rt number.=C2=A0

If the port number was different,= the mechanisms available for a network operator to block DoH would include= doing so strictly on the basis of port number.
And, if the netwo= rk operator did not block any DoH servers, or only blocked DoH servers not = on the TRR list, DoH to those servers would work exactly as they would have= done had the port number remained 443.

The caveat= here is I think this -bis would need to either require the new port be use= d exclusively by clients (no client-side override of port number via templa= te configuration), or to exclude 443 as an override port number.
= (I realize that kind of seems draconian, because it is. It's the logica= l result of facilitating a scalable way for network operators to block DoH.= )

This may seem contentious, because of the origin= al desire to have DoH and HTTPS traffic muxed together on the same IP addre= sses.
However, the current reality is that isn't happening to= the best of my knowledge, and I am unaware of any large public resolver op= erator committing to doing so.
(Large =3D=3D enough HTTPS traffic= to dwarf expected DoH traffic, and production resolver, meaning with geogr= aphically redundant anycast addressing and > O(10K qps) DNS traffic.)

I.e. if the port 443 justification has become moot, = I think it is reasonable to look at this pragmatically.=C2=A0
All= the public TRR-list (and similar) DoH operators' DoH traffic can be id= entified by IP address alone, and blocked the same way.
The remai= ning issue is the ability of network operators to do any of several things:=
  • Identify all DoH traffic regardless of destination
    • <= li>Block all DoH traffic
  • Reactively block individual DoH destinatio= ns that have been identified as problematic (regardless of how/why)
    • Accommodate mandated legal filtering requirements within appropriate juris= dictions (e.g. in the UK) by limiting resolver choice to resolvers which co= mply with those mandates
  • Limit DoH destinations to a white list of = addresses (e.g. TRR lists)
And to reiterate: the purpose of t= his is to reach a balance, and to specifically encourage and promote the us= e of TLS for privacy on DNS traffic, speaking only for myself at least.

Brian
--0000000000005cc3d305979d3083-- From nobody Mon Nov 18 03:34:03 2019 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 9E8321200E9 for ; Mon, 18 Nov 2019 03:34:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 ovmcGO9G1xI5 for ; Mon, 18 Nov 2019 03:34:00 -0800 (PST) Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 8CFA7120947 for ; Mon, 18 Nov 2019 03:34:00 -0800 (PST) Received: by mail-vs1-xe34.google.com with SMTP id a143so11225007vsd.9 for ; Mon, 18 Nov 2019 03:34:00 -0800 (PST) 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=Bd0ZQD8k4vuzLbN+PQH2mtVTGx1staJzMz9I7cBnUFY=; b=BlOx5iJ16q3oH48LIPfWLgSnwx8u9PGv8GAuOyAISudMZNt3o5d3jSfKRQV5XvoDqs ELEBUDCIHOJ7UDELnHWJRHonBD7UB5wugpdUaoAyJH9OgrMwD+WAnrT411flynoQRMkJ fkzgZyDSy7Ptty5Fb+WDRrworlGqtKcxRXDRMnN6JuaFe8j/1Jegw+GNFE5IiWrU9Roy BsTpHBp6mfUotFwdCexPHDn2GG7D+5PXA7Je1lgWR87YiIIIVey+TbqbeB4SBbGRpZ4a U+dWGMjKWJEwetCsGBRi3eTNhEHCpgsJtW2IBauKYgbJsSQoY+fYsBjvpDCEyqWOLxvk Lisw== 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=Bd0ZQD8k4vuzLbN+PQH2mtVTGx1staJzMz9I7cBnUFY=; b=Fmiw7nIgNCVja/9b9c2tfr6l3STs03aLMUSbXY5KiAYB1Xa6LXao8q/T1q9CsNxeZP 06N3grX6USmAS4/+D+JLA60IezSZp9mVKwuHNRRIyRphCP11XROqpe2vsd04QtcbuRtk 1MoeTaEWf0P/NyUoiw/xgZu5np4gDD1K9+78SdKrY/2XdwtMzvm7s84O8DatQddm2T5v 0KYbJtEv23BR4Qh2z3a1yyn7fxFEaVto0QuOxkzFcYrwmaDCIfqpCPOBpvZTeww131Za u7sHeo39d5dlFU0/lCYlBdYqrfSG3ir/N5mxpK2hAlOzYBC7vdDQK7xj39I6a6Ipoayr 4mUg== X-Gm-Message-State: APjAAAWcwVpCGqjQ1zVDiK4kv4IPDBQmRmz4couqsLBLFD2K8UuHUSFn tas+Up3KlBofQIeXiq0IUNdaHBqDggaUjH/T17U= X-Google-Smtp-Source: APXvYqycwwT0jqTOQSF3kGTCNQOLR+p9t0/88wwXc/C8Xd1d3eKpOvt2kcPkOxBPMKkNLQV6Spnx1gLbxirkG20i/DU= X-Received: by 2002:a67:f744:: with SMTP id w4mr6864883vso.219.1574076839470; Mon, 18 Nov 2019 03:33:59 -0800 (PST) MIME-Version: 1.0 References: <1E524D44-E988-4E95-8C71-30C5D5BF7225@fugue.com> In-Reply-To: From: Brian Dickson Date: Mon, 18 Nov 2019 19:33:42 +0800 Message-ID: To: Ted Lemon Cc: Andrew Campling , Ben Schwartz , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000ddaa8005979d52c0" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 11:34:03 -0000 --000000000000ddaa8005979d52c0 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 18, 2019 at 7:24 PM Brian Dickson wrote: > > (It may be necessary to also specify a new namespace specifier analogous > to "https:", call it "doh:". I believe the contents of 2818 could be > trivially transformed by modifying the document name, and changing sections > 2.3 and 2.4 to specify "doh:" and the new port number, and doing basic > housekeeping. Then 8484-bis would refer to this in place of 2818, and use > the new doh: URI component in place of https: .) > I hate doing a self-reply-to-all so soon after my previous email. I should suggest a better update method: do a new RFC that "updates" 8484, to add sections 2.5 and 2.6 which mirror 2.3 and 2.4, but use the new name and port numbers, adding "for DNS" to the section heading. Brian --000000000000ddaa8005979d52c0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 18, 2019 at 7:24 PM Brian= Dickson <brian.peter.d= ickson@gmail.com> wrote:

(It may be necessary to also specify a new namespace specifier = analogous to "https:", call it "doh:". I believe the co= ntents of 2818 could be trivially transformed by modifying the document nam= e, and changing sections 2.3 and 2.4 to specify "doh:" and the ne= w port number, and doing basic housekeeping. Then 8484-bis would refer to t= his in place of 2818, and use the new doh: URI component in place of https:= .)

I hate doing a self-rep= ly-to-all so soon after my previous email.

I shoul= d suggest a better update method: do a new RFC that "updates" 848= 4, to add sections 2.5 and 2.6 which mirror 2.3 and 2.4, but use the new na= me and port numbers, adding "for DNS" to the section heading.

Brian=C2=A0
--000000000000ddaa8005979d52c0-- From nobody Mon Nov 18 03:51:04 2019 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 E6A33120059 for ; Mon, 18 Nov 2019 03:51:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 (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 QDp-5dZXaHFf for ; Mon, 18 Nov 2019 03:51:01 -0800 (PST) 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 ED90F120018 for ; Mon, 18 Nov 2019 03:51:00 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 47GnN24ngRz72s; Mon, 18 Nov 2019 12:50:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1574077858; bh=vheJDyb/8uAQKuUbpvs6M6JhexWYIN/F1yKzrm+6hfs=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=J9nmL5+bQmlM72AbttuL8d7TR6yETTY4ppC3ehvThgdTmQRODc4rG7MC5lSH8DhIH hzazTCqmKcMjpa22msBeb7D8cV1ttGkDL0XoYGjqV7Zwb/1NFMi7R4zQtzonwTxMtN KaHFJ7cZJoytNppV5psxx09TqiusDVTHy4ZTiB34= 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 A_hfTXXoyGq8; Mon, 18 Nov 2019 12:50:57 +0100 (CET) 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; Mon, 18 Nov 2019 12:50:56 +0100 (CET) Received: from [10.0.72.156] (unknown [42.61.211.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bofh.nohats.ca (Postfix) with ESMTPSA id 6D9F8607CC65; Mon, 18 Nov 2019 06:50:55 -0500 (EST) Content-Type: multipart/alternative; boundary=Apple-Mail-A9C7DC3C-5D91-4DC7-9D95-042F16EFD740 Mime-Version: 1.0 (1.0) From: Paul Wouters X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Mon, 18 Nov 2019 19:50:47 +0800 Cc: ADD Mailing list Content-Transfer-Encoding: 7bit Message-Id: References: <1E524D44-E988-4E95-8C71-30C5D5BF7225@fugue.com> To: Andrew Campling Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 11:51:03 -0000 --Apple-Mail-A9C7DC3C-5D91-4DC7-9D95-042F16EFD740 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > On Nov 18, 2019, at 17:26, Andrew Campling wrote: > =20 > I believe that one of the issues that is hindering an effective discussion= about DoH is the lack of documented use cases that enable an objective asse= ssment of various proposals. One use case is =E2=80=9Cnever see anything in my DNS stream=E2=80=9D and th= e other use case is =E2=80=9Cwe want to be able to see everything in the DNS= stream=E2=80=9D. Documenting the use cases in detail isn=E2=80=99t going to help an =E2=80=9C= effective discussion=E2=80=9D because the two camps can not compromise on th= eir requirements. This is the same issue as the TLS 1.3 discussion on enterp= rise monitoring. > It would be particularly helpful for the WG charter to include the captu= re, document and then validate the relevance of use cases so that we have an= agreed set for future reference. I honestly don=E2=80=99t see value in this and I don=E2=80=99t see how this W= G could produce results other than advancing one of the two camps at the ex= pense of the other of the two camps. > I suspect that one of the areas of angst is who that =E2=80=9Csomeone=E2=80= =9D is =E2=80=93 ie whether it=E2=80=99s an actual end user (individual or e= nterprise) or whether it=E2=80=99s a tech company driven by a =E2=80=9Ccomme= rcial imperative=E2=80=9D. As above, documented use cases would help here. I think using the word angst here is not a fair description. Describing the attacker in more detail doesn=E2=80=99t change the fact that o= ne camp has defined all of them as attacker and the other camp wants to be s= een as the benevolent party instead.=20 Seeing the discussion on this list about the charter alone seems to make it p= retty clear that DoH remains a feature or a bug, depending on your view. Pro= ducing more documents isn=E2=80=99t going to change that. Paul= --Apple-Mail-A9C7DC3C-5D91-4DC7-9D95-042F16EFD740 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On Nov 18, 2019, at 17= :26, Andrew Campling <a= ndrew.campling@419.consulting> wrote:

 

I believe that one o= f the issues that is hindering an effective discussion about DoH is the lack= of documented use cases that enable an objective assessment of various prop= osals.


One use c= ase is =E2=80=9Cnever see anything in my DNS stream=E2=80=9D and the other u= se case is =E2=80=9Cwe want to be able to see everything in the DNS stream=E2= =80=9D.

Documenting the use cases in detail isn=E2=80= =99t going to help an =E2=80=9Ceffective discussion=E2=80=9D because the two= camps can not compromise on their requirements. This is the same issue as t= he TLS 1.3 discussion on enterprise monitoring.

  It would be particularly helpful for the WG charter to include the capture, document and then valida= te the relevance of use cases so that we have an agreed set for future refer= ence.


I honestl= y don=E2=80=99t see value in this and I don=E2=80=99t see how this WG could p= roduce results other  than advancing one of the two camps at the expens= e of the other of the two camps.

I suspect that one o= f the areas of angst is who that =E2=80=9Csomeone=E2=80=9D is =E2=80=93 ie w= hether it=E2=80=99s an actual end user (individual or enterprise) or whether= it=E2=80=99s a tech company driven by a =E2=80=9Ccommercial imperative=E2=80= =9D.  As above, documented use cases would help here.


I think using the word angst here is not a fair desc= ription.

Describing the attacker in more detail doe= sn=E2=80=99t change the fact that one camp has defined all of them as attack= er and the other camp wants to be seen as the benevolent party instead. = ;

Seeing the discussion on this list about the charter alone s= eems to make it pretty clear that DoH remains a feature or a bug, depending o= n your view. Producing more documents isn=E2=80=99t going to change that.

Paul
= --Apple-Mail-A9C7DC3C-5D91-4DC7-9D95-042F16EFD740-- From nobody Mon Nov 18 06:20:01 2019 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 CAB5512083D for ; Mon, 18 Nov 2019 06:19:59 -0800 (PST) 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 ETpl6JbvohIj for ; Mon, 18 Nov 2019 06:19:58 -0800 (PST) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AD9B1200F5 for ; Mon, 18 Nov 2019 06:19:57 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 7569B91FBC; Mon, 18 Nov 2019 09:19:56 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24018.43148.463202.630086@gro.dd.org> Date: Mon, 18 Nov 2019 09:19:56 -0500 From: Dave Lawrence To: ADD Mailing list In-Reply-To: <509F49E3-6B10-4AAE-8C65-1B5B144193FD@cable.comcast.com> References: <299277505.7138.1574037347987@appsuite-gw2.open-xchange.com> <20D27080-7049-4D42-B020-6F574FD45140@isoc.org> <509F49E3-6B10-4AAE-8C65-1B5B144193FD@cable.comcast.com> Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 14:20:00 -0000 Livingood, Jason writes: > It seemed the out of bounds topics would make consensus impossible > which would then prevent WG formation. (No hats.) I've got a few thoughts around this general idea of (nigh) impossible consensus and the various angles on it that have been presented in the thread so far, but in advance of the meeting I'll try to be succinct with one main thought that I haven't really seen represented. Without a suitable home in the IETF for these difficult topics to be discussed, it does not mean that they are not discussed and yet they will still colour a lot of the work that the IETF does. It would still be useful work for a group to address why they are fundamentally intractable topics for which no consensus is possible, and release documentation to that effect. That is, of course, not the focus of the proposed group. We're looking first and foremost for the largely technical work on relatively policy-neutral topics where it seems likely we can still achieve some victories. Yes, I can readily see how including the difficult topics in the charter looks like an attractive nuisance for getting bogged down on them, suffocating out the more straightforward work. On the other hand it also seems that leaving them out means there's no other good outlet, and doesn't intrinsically mean that they won't come up. It only means that the chairs have a tool of declaring "off topic!" to manage the list. Working group chairs already loosely have the ability to redirect unproductive discussion though, even without that specific objection of charter-relevance. Effective chairs/ADs will keep things on track for work product that we actually achieve. Yes this whole area represents a significant disruption to the DNS business-as-usual. We'll inevitably have some bumps along the way. I, speaking as an individual, would prefer to see that they be openly discussed and documented rather than simply declared to be off-limits. From nobody Mon Nov 18 06:38:00 2019 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 B4EFE120933 for ; Mon, 18 Nov 2019 06:37:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 p5hPKXH6WLUS for ; Mon, 18 Nov 2019 06:37:55 -0800 (PST) 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 28107120100 for ; Mon, 18 Nov 2019 06:37:55 -0800 (PST) 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)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 3FBFC6A230; Mon, 18 Nov 2019 15:37:53 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1574087873; bh=z1e4VsKWUKsr0RuCxdcQmxDBXPKLgmkDcvHFQKRw35w=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=81qyxf7s4C7Q3naHXeGRvD07wb/vKYlYvElogYRr3r9V+dFQxHrTEsTqWg4gz27dZ 3nzTJWVQ7tZTol6Q5s2xwY0pMSpGKw+RGOpozg2eZQm050pkTkZ60iiEAwro/LiccR KeSQjetBxix/NIW2YwfiQXuy+toAHFmF+kIiH5ABH02iIevkOdGLtfTos2MVREzzRn pHETpZxnwPasLr/UY9gvznbGYqLTPNjKRLivAwGzqS43Eol18cwe5NMS3X+QUHCZLm Ks1ILWbZBGh2GrC6f2fconN1Chs8r5BoDb51Hvi8uSo+tIO3Wwn1RHTqf2r6xfmjzy FUXkQqAeZu46g== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (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 3248F3C0306; Mon, 18 Nov 2019 15:37:52 +0100 (CET) Date: Mon, 18 Nov 2019 15:37:52 +0100 (CET) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Rob Sayre Cc: ADD Mailing list Message-ID: <606328879.9505.1574087872909@appsuite-gw2.open-xchange.com> In-Reply-To: References: <6.2.5.6.2.20191116232455.10209e78@elandnews.com> <2105867190.7141.1574038197898@appsuite-gw2.open-xchange.com> <24018.1739.610788.280101@gro.dd.org> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev17 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] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 14:37:58 -0000

Il 18 novembre 2019 07:46 Rob Sayre <sayrer@gmail.com> ha scritto:




On Sun, Nov 17, 2019 at 6:49 PM Dave Lawrence < tale@dd.org> wrote:
Vittorio Bertola writes:
> I still find it weird that people at the IETF challenge jurisdiction
> and national sovereignty so directly.

You were careful with your words and I appreciate that. 

I'd like to understand the use case better.

Is the idea that some software companies are selling DNS filtering software to any government, and letting those governments configure the policy?
No company is "selling DNS filtering software to any government", for the simple reason that governments do not normally operate end-user DNS resolver platforms.

On the other hand, every DNS operator (either ISP or third party, including Do* operators) has to abide by the laws of its own country, which in many countries mandate blocking of certain domains, with procedures, reasons, objectives and numbers that depend a lot on the specific country. In some cases, operators abide by self-regulatory codes of conduct that would have otherwise been mandated by law, possibly in stricter form.

The objectives of these laws (or deriving court orders, or codes of conduct) may or may not be related to censorship, i.e. blocking access to content for political reasons. In Europe, the most common case is rather blocking access to illegal audiovisual content (Pirate Bay and Rojadirecta above all). Frequently blocked content types also include child sexual abuse material, unlicensed gambling websites and counterfeit shops. I would not call any of this "censorship", though there are people at the IETF that seem to do so (e.g. see this PEARG draft https://datatracker.ietf.org/doc/draft-irtf-pearg-censorship/ to which I made the same objection - I think it adopts a too broad and vague definition of censorship).

So I find terms like "DNS censorship" not useful, at least if applied to DNS filtering in general, also because law-mandated blocking is not the only use of DNS filtering. Several other uses related instead to network and user security, or to user-requested content blocking; stuff like malware, phishing websites, bots - this has already been explained multiple times.

This is also why there is no such thing as "DNS filtering software"; filtering is simply a feature in more or less any major DNS recursor implementation, for example via RPZ support (see a list here https://dnsrpz.info/ ). Recursors would simply be useless for professional deployments if they did not have this capability.

Moreover, many of these recursors (including the one developed by my colleagues) are released under free software licenses, which means that we do not "sell" the software, nor we would be able to prevent anyone to use the software for whatever purpose. Of course we sell support, custom development and extensions, which is why we decided, when asked, not to sell DNS-related services to a very big telco located in an authoritarian country just outside of Europe. But we cannot prevent them from downloading and compiling our code, or another free DNS implementation that does the same things - or they could just implement a DNS server themselves, since it is an open protocol.

Finally, I would expect that a likely regulatory response in Europe to DNS recursion moving abroad in mass would be to extend the above legal filtering obligations to global players that operate in Europe, independently from where the service platform is located, as already done for privacy obligations through the GDPR. So the result of all this effort might not be what you expect - in fact, like for the GDPR, some operators might even decide to apply the union of all restrictions to all users.

I hope this clarifies the use case and helps making the discussion more constructive.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
From nobody Mon Nov 18 06:38:52 2019 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 DAE4D120933 for ; Mon, 18 Nov 2019 06:38:50 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 qlNAQ_4Q_WU7 for ; Mon, 18 Nov 2019 06:38:47 -0800 (PST) Received: from mail-qk1-x72a.google.com (mail-qk1-x72a.google.com [IPv6:2607:f8b0:4864:20::72a]) (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 99449120100 for ; Mon, 18 Nov 2019 06:38:47 -0800 (PST) Received: by mail-qk1-x72a.google.com with SMTP id e187so14589925qkf.4 for ; Mon, 18 Nov 2019 06:38:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=utodudZ66Qf+HNrIOCBn4Nv8bXYkDrzpOwHjv5ZNXs4=; b=NU5hHDjtUtpsautnMjnP/JA6lnHl0wdmkkHedwfg0BRJAEOhgIsoTNVCfRoGWeEqIw U4JhQgCS8ikr4v7Q38O+9FpXQworWynBuni2djKbQWpCzdSWHn17vxL1JUGaAhD/eaua N2JCtoG7mjC9K69mBwyy/3BIF+CSUMItpFBLzuE+52vwmu4O3jjeHzoCuMFPkzlIVoia viwJlQcQlkL6C9Wb1wrKAdNNKbi1/5DEfup7jENG/vdnFCYDWD2891xRrTOcZobvl5aA EZtxkH6SgZ9stmr/bndkPzKd7idwEJJ1UNLYrpCmF83lQ1ay1jjGWR65d6v5XCMHI/5a JvFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=utodudZ66Qf+HNrIOCBn4Nv8bXYkDrzpOwHjv5ZNXs4=; b=nOI8XrEBj13iB/dbuO9Tn3Z0Ibr8w1rjFVie8qbCQwfiEgiAXtwRhtWu9p/qESPTTU Lvx+xxsNCC53+39ebI+V9I/ESA0XSB02kns3MfDkRNam0eVI2jQcSiZYFzQwCCQh8fLx kOBnk3qk47WV8QxngYVPnQvYg83KcHCins69Cf1x6Jt339KcvKYZ8hpa9V8Rog155bRF N82jCdKiJoZvcmMysz/rg5Bps3iP9wCN2O7NgTH5I08dfTRa+lgGtbvctu3UV4hywAgy FzGz9U26G4fAnKNdAIFW96AibjvxlDNg59eY8pjd0Ts1XzZTxFWB4h2p5qrqkJlC6TC9 pLsg== X-Gm-Message-State: APjAAAWHNzAYljifoQNrgMMiLb+hs06qS1sjlJsf3+XVHyT3yi0Ffh+F zrle6+kkgQgQbhDQhZvTf/554LR6Tb+6NA== X-Google-Smtp-Source: APXvYqz3hz5bfw2VyMHCtznB+JyBm4fdDpGtJi5D4/+RktSY/mD8zmCfprU9iVIPzD23tbmpMnyLyA== X-Received: by 2002:a05:620a:2112:: with SMTP id l18mr24423044qkl.384.1574087926434; Mon, 18 Nov 2019 06:38:46 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:75cb:e774:f252:f1fd? ([2601:18b:300:36ee:75cb:e774:f252:f1fd]) by smtp.gmail.com with ESMTPSA id q8sm10747890qta.31.2019.11.18.06.38.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 18 Nov 2019 06:38:45 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Ted Lemon Mime-Version: 1.0 (1.0) Date: Mon, 18 Nov 2019 09:38:44 -0500 Message-Id: <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> References: <24018.43148.463202.630086@gro.dd.org> Cc: ADD Mailing list In-Reply-To: <24018.43148.463202.630086@gro.dd.org> To: Dave Lawrence X-Mailer: iPhone Mail (17E180a) Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 14:38:51 -0000 David, we can and do discuss these topics in the IETF already. We=E2=80=99re= doing it now, and have done it elsewhere in the past.=20 What putting it in the charter does is not merely to give us permission to d= iscuss it, which we already have, but rather indicates that there is consens= us to work on those things, which there clearly is not. Hence, they do not b= elong in the charter.=20 > On Nov 18, 2019, at 09:20, Dave Lawrence wrote: >=20 > =EF=BB=BFLivingood, Jason writes: >> It seemed the out of bounds topics would make consensus impossible >> which would then prevent WG formation. >=20 > (No hats.) >=20 > I've got a few thoughts around this general idea of (nigh) impossible > consensus and the various angles on it that have been presented in the > thread so far, but in advance of the meeting I'll try to be succinct > with one main thought that I haven't really seen represented. >=20 > Without a suitable home in the IETF for these difficult topics to be > discussed, it does not mean that they are not discussed and yet they > will still colour a lot of the work that the IETF does. It would > still be useful work for a group to address why they are fundamentally > intractable topics for which no consensus is possible, and release > documentation to that effect. >=20 > That is, of course, not the focus of the proposed group. We're > looking first and foremost for the largely technical work on > relatively policy-neutral topics where it seems likely we can still > achieve some victories. >=20 > Yes, I can readily see how including the difficult topics in the > charter looks like an attractive nuisance for getting bogged down on > them, suffocating out the more straightforward work. On the other > hand it also seems that leaving them out means there's no other good > outlet, and doesn't intrinsically mean that they won't come up. It > only means that the chairs have a tool of declaring "off topic!" to > manage the list. Working group chairs already loosely have the > ability to redirect unproductive discussion though, even without that > specific objection of charter-relevance. Effective chairs/ADs will > keep things on track for work product that we actually achieve. >=20 > Yes this whole area represents a significant disruption to the DNS > business-as-usual. We'll inevitably have some bumps along the way. > I, speaking as an individual, would prefer to see that they be openly > discussed and documented rather than simply declared to be off-limits. >=20 >=20 >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Mon Nov 18 07:04:08 2019 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 01D2812094E for ; Mon, 18 Nov 2019 07:04:07 -0800 (PST) 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 LE4zC20zEBAY for ; Mon, 18 Nov 2019 07:04:06 -0800 (PST) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCCD3120842 for ; Mon, 18 Nov 2019 07:04:05 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 11D7892013; Mon, 18 Nov 2019 10:04:05 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24018.45797.55312.687430@gro.dd.org> Date: Mon, 18 Nov 2019 10:04:05 -0500 From: Dave Lawrence To: ADD Mailing list In-Reply-To: <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 15:04:07 -0000 Ted Lemon writes: > What putting it in the charter does is not merely to give us > permission to discuss it, which we already have, but rather > indicates that there is consensus to work on those things, which > there clearly is not. Hence, they do not belong in the charter. Apparently despite my efforts I was not clear. I see it as something that can be discussed toward the end of still producing documents that describe why exactly we are not able to otherwise achieve consensus on some issue. That, to me, is meaningfully different than just going round and round in circles. That provides a useful statement of why the IETF is where it is on those topics. From nobody Mon Nov 18 11:43:51 2019 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 93A3312081C for ; Mon, 18 Nov 2019 11:43:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gb8NtX0ZiP36 for ; Mon, 18 Nov 2019 11:43:46 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0: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 ED791120808 for ; Mon, 18 Nov 2019 11:43:45 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id q1so17128042ile.13 for ; Mon, 18 Nov 2019 11:43:45 -0800 (PST) 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=V6TGPbdUdzyR2Wcs54QoRQ4jtYcG7T4+B4hf1MR/w+w=; b=M3h4urfbO+kCtcUtY/aBTOo3Vwk8ef2HVFkmPrYCowQpYa/VI1QKtDH29ftT9jcvZO OWAomyzK7zbVd+ZFbeRDvcpRTswjU1JXsgKu8Kikr7r6eBqPJKb/PnutC03ZLz81Ot4M 1z/4fvIWWPeZQTBIMuxhLh4K6C4Q43sO1c/tXxU8n5CldMV86ciCgndbtPzcFTZvCT4f XcPq3JS6pa8yZ2GpsUxMAnhsw8cbApTx6v5tuPAMQkp0tcjMaQFedCBvpRtT57fylTZL XS0dtuA97L4edHJOdti+2AbiBz0ZHL16fPW3CvZTWy+ZK9CbHfcsmEs41USSyLvs+ciM lSuQ== 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=V6TGPbdUdzyR2Wcs54QoRQ4jtYcG7T4+B4hf1MR/w+w=; b=FycneHpxBd/YXXulez9txI5ncUYj0IR38m/bAU2acd9JuXqbCdlmu4pGS4SA4Tc1vn tZzAtv03g9d/YrvITxT7HUHzU261KXvvRzdjo/BR8qp3vkIT3Z8AO6HvGymIWHN3iaAA +k6wBLiwsU+N2sdHySj4gYtTfHoytFv+W1i8jylo8O3Hp4lGpx85avtula7dVi/fK4QV Y7Ov4qWTBlKkAe01p9lHLow/SnnnwDe05DCygEUeHckjj3DrMh0/Tj3WeLJf34HUvKLy NkSLs7KkLgoXUFoZyTkfCcFA1wQhcx64+eBOCDgXjv5a2ypi8Tz5RG4nz8IhbI+SR+jz ohWQ== X-Gm-Message-State: APjAAAVYDK5QRGJZbEuvZFjj3qKBcUtPz/yrU3QQMVNKxeDrhsjvSV3q GNn4IzruUgKSUXeiDGt170Q4+a909nOK7sOM8Kg= X-Google-Smtp-Source: APXvYqxle3tllQk2KAgR0TEPxSW/gYmFYyiPwdpoqiVQd2aMSln5rpcDc1GA5FMZvMOqFKKOwwwktT6fb4hAYz49d6k= X-Received: by 2002:a92:8394:: with SMTP id p20mr18265812ilk.73.1574106225045; Mon, 18 Nov 2019 11:43:45 -0800 (PST) MIME-Version: 1.0 References: <299277505.7138.1574037347987@appsuite-gw2.open-xchange.com> <20D27080-7049-4D42-B020-6F574FD45140@isoc.org> <509F49E3-6B10-4AAE-8C65-1B5B144193FD@cable.comcast.com> In-Reply-To: <509F49E3-6B10-4AAE-8C65-1B5B144193FD@cable.comcast.com> From: Rob Sayre Date: Mon, 18 Nov 2019 11:43:33 -0800 Message-ID: To: "Livingood, Jason" Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000061f4750597a42a93" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 19:43:49 -0000 --00000000000061f4750597a42a93 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2019 at 12:04 AM Livingood, Jason < Jason_Livingood@comcast.com> wrote: > *From: *Add on behalf of Rob Sayre < > sayrer@gmail.com> > On Sun, Nov 17, 2019 at 9:51 PM Joseph Lorenzo Hall wrote= : > > > > I agree with Patrick that this is one of a number of aspects of the > ongoing ABCD/ADD discussion that seems to indicate we would be =E2=80=9Cs= pinning > the wheels=E2=80=9D (not getting much productive done) in a WG. I like wh= ere > Livingood is going on this thread with suggested changes to the proposed > charter to make the work here more crisp > > > > > I agree that some of Livingood's additions are a little better. But his > edits seem to remove out-of-bounds topics, which seems misguided. > > > > [JL] It seemed the =E2=80=98out of bounds=E2=80=99 topics would make cons= ensus impossible > =E2=80=93 which would then prevent WG formation. So proposing removal was= an > approach to see if we might identify those few areas where there is > agreement. I am not sure how that is misguided, but it wouldn=E2=80=99t b= e the > first time I=E2=80=99ve been accused of being misguided, confused, crazy,= deluded > or whatever else. LOL. > :) I didn't accuse the person of being misguided, just the edit. I like the way the charter is written on these topics, because it makes it clear that consensus on these topics is extremely unlikely. thanks, Rob --00000000000061f4750597a42a93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 18, 2019 at 12:04 AM Livi= ngood, Jason <Jason_Livin= good@comcast.com> wrote:

From: = Add <add-bounces@ietf.org> o= n behalf of Rob Sayre <sayrer@gmail.com>
On Sun, Nov 17, 2019 at 9:51 PM Joseph Lorenzo Hall <hall@isoc.org> wrote:<= u>

=C2=A0

I agree with Patrick that this is one of a number of= aspects of the ongoing ABCD/ADD discussion that seems to indicate we would= be =E2=80=9Cspinning the wheels=E2=80=9D (not getting much productive done= ) in a WG. I like where Livingood is going on this thread with suggested changes to the proposed charter to make the work her= e more crisp

=C2=A0

> I agree that some of Livingood's additions = are a little better. But his edits seem to remove out-of-bounds topics, whi= ch seems misguided.

=C2=A0

[JL] It seemed the = =E2=80=98out of bounds=E2=80=99 topics would make consensus impossible =E2= =80=93 which would then prevent WG formation. So proposing removal was an a= pproach to see if we might identify those few areas where there is agreement. I am not sure how that is misguided, but it wouldn=E2=80=99t= be the first time I=E2=80=99ve been accused of being misguided, confused, = crazy, deluded or whatever else. LOL.


:) I didn't accuse the person of being mi= sguided, just the edit.

I like the way the cha= rter is written on these topics, because it makes it clear that consensus o= n these topics is extremely unlikely.

thanks,
Rob
--00000000000061f4750597a42a93-- From nobody Mon Nov 18 12:53:02 2019 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 3A8E7120B53 for ; Mon, 18 Nov 2019 12:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=elandsys.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 Qh9t-kYSFw1X for ; Mon, 18 Nov 2019 12:52:59 -0800 (PST) Received: from mx.elandsys.com (mx.elandsys.com [162.213.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id A5EE0120B51 for ; Mon, 18 Nov 2019 12:52:59 -0800 (PST) Received: from DESKTOP-K6V9C2L.elandsys.com ([102.116.63.5]) (authenticated bits=0) by mx.elandsys.com (8.15.2/8.14.5) with ESMTPSA id xAIKqg0a005899 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Nov 2019 12:52:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=elandsys.com; s=mail; t=1574110374; x=1574196774; i=@elandsys.com; bh=KfNfAAYoHCVQptgysVsrl4x2ZQm0eWn/o7gZq45QqVU=; h=Date:To:From:Subject:In-Reply-To:References; b=mnKvIXrtcjuZCV+7ZFkqsk9cAuAjQzKzFsiqk0qHX5FU4Pa7Kh3VF88Xhj+9ymqDt D+YwKkaTiU+66naQ8lq9r6Dl7U/u9GQX3tHjIsdWxhf5l28YAj36+XlQd7ajCyJoef oTY0dHkHeGJuaX2Bk+Ar0VBurWcdQuDGMW7xitI4= Message-Id: <6.2.5.6.2.20191118120357.0c72ae50@elandnews.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Mon, 18 Nov 2019 12:52:12 -0800 To: Vittorio Bertola , add@ietf.org From: S Moonesamy In-Reply-To: <2105867190.7141.1574038197898@appsuite-gw2.open-xchange.co m> References: <6.2.5.6.2.20191116232455.10209e78@elandnews.com> <2105867190.7141.1574038197898@appsuite-gw2.open-xchange.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 20:53:00 -0000 Hi Vittorio, At 04:49 PM 17-11-2019, Vittorio Bertola wrote: >I still find it weird that people at the IETF challenge jurisdiction >and national sovereignty so directly. Whether we like it or not, >that concept is what keeps the world together and more or less at >peace, granting peoples the right to self-govern. In the end, a good >architecture for the DNS would support the ability of each country >to make and enforce rules over their citizens' use of it. The >opposite, in the end, is only going to replace one jurisdiction with >another, which is unacceptable to even the most democratic governments. I would not disagree with some of the points in the above. Regards, S. Moonesamy From nobody Mon Nov 18 13:22:43 2019 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 2E867120B56 for ; Mon, 18 Nov 2019 13:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.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 FzcfmJ9hxioc for ; Mon, 18 Nov 2019 13:22:37 -0800 (PST) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 8AB73120B4F for ; Mon, 18 Nov 2019 13:22:37 -0800 (PST) Received: by mail-ot1-x32a.google.com with SMTP id b16so15862729otk.9 for ; Mon, 18 Nov 2019 13:22:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-transfer-encoding; bh=vr4KzJh877S2JCR0MZ4TheTAVFcQMuFOgxJJo8lefWg=; b=Y3c73CnY42187DODAMndjy9qVNAPMRsesaiwduymDm0m6pTNBaKOHzxgJR/JilgQr0 fQIX23Ev+UWaFBZAhfDXhFmcWoRQ0vbvsRxMixU7SuhWQPk0zesU8D9FosM72n21s61k THOgk5dfnz4Vcs44km0TLxwAH8l7W/+uA3Ijw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-transfer-encoding; bh=vr4KzJh877S2JCR0MZ4TheTAVFcQMuFOgxJJo8lefWg=; b=hYdXtuPbT+3Br2koI9mQMa7jQHOPwGrnNMrirQKDfMscg0LkANQ5RpjP9nXIaR0Lxr IF4c9mw0bT1lMLyIY5L4jaSLRu8j9hsyi6qBGFSqq2PpO3DSpvHZF8rx2mwkEXtbV5ft ZM6HdzmmMOcCVnUWqYR+l0fastBRJmY8qKMs3lIEmJjxrlg6ufMacVP6DEJGKnt8Iqv8 mUHAZgE1M0UVQJh7FqjisOEm4nxvgyiSmVnZbHpUYC3IuVPlVyZQMWMuNxI4VYgQ4xow YT8ydH1r6XFActvpSgU2VPpWhthpa2S/G9Wvh2j4AiePw8+bJHl9VSfEQdM2GTHczorI X6sw== X-Gm-Message-State: APjAAAWKpVgvv6NIIKzwf9IO0dFWnAebImsFA2W/YrHoYRrYUuqG2m0E aMD31npttJGHevr0kBg8a6ISDSuLIBBLjt/8ca5r4npgaRw= X-Google-Smtp-Source: APXvYqxj4XWI+VZYIzYxVNfh5fEHTDe5BXzo1ymeHazfO62wsX718sjpFq183BVwDNajOOnK2fcwltj35QTuf4IGlLs= X-Received: by 2002:a9d:590c:: with SMTP id t12mr1062326oth.103.1574112156742; Mon, 18 Nov 2019 13:22:36 -0800 (PST) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Mon, 18 Nov 2019 16:22:36 -0500 From: Joe Abley Mime-Version: 1.0 (1.0) References: <20191118020806.AD1D51969BB0@fafnir.remote.dragon.net> In-Reply-To: <20191118020806.AD1D51969BB0@fafnir.remote.dragon.net> Date: Mon, 18 Nov 2019 16:22:36 -0500 Message-ID: To: Paul Ebersman Cc: Andrew Campling , "add@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 21:22:42 -0000 On Nov 17, 2019, at 21:08, Paul Ebersman wrote: > =EF=BB=BFsm> Commenting about jurisdiction, an IETF Area Director was quo= ted as > sm> stating that: "[DoH] will allow journalists in hostile regimes to do > sm> their jobs more safely, or people in heavily censored countries to > sm> get access to the truth". First of all, that is a very narrow > sm> use-case. Secondly, the argument of "getting access to the truth" > sm> sounds very convenient. > > acampling> I agree that the use case is indeed very narrow. I'd add > acampling> that better tools are already available to aid dissidents and > acampling> others that do not impair the use of the web by other large > acampling> groups (eg children, enterprise users etc) and in any case > acampling> question the validity of the dissident use case for DoH, do > acampling> not believe that it stands up to examination. > > Agreed. Tor/VPN and similar solve the dissident case; DoH is an > insufficient protection against state actors or folks with similar > resources. > I don't know whether I agree with this or not. This commentary misses the more general point that if only dissidents use these other options, it will be obvious to an observer that dissidents are speaking. Is that ok? This seems similar to the argument that you only need encryption if you have something to hide. I thought IETF consensus was different. The problem with VPNs in general is that naive users (most users) have no good way to trust their tunnel termination points. There are also fewer termination points than there are potential users, so this is another example of centralisation which in general I think is reasonable to be considered at odds with privacy. In some sense, tor is a dynamic VPN with source identity protection. The concentration problem remains. I don't think this is as simple as some in this thread might suggest. Joe From nobody Mon Nov 18 14:36:40 2019 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 37D59120B5F for ; Mon, 18 Nov 2019 14:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.336 X-Spam-Level: * X-Spam-Status: No, score=1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-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 dl5LhM0QqsW3 for ; Mon, 18 Nov 2019 14:36:35 -0800 (PST) Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) (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 E7E85120B47 for ; Mon, 18 Nov 2019 14:36:34 -0800 (PST) Received: by mail-pj1-x102e.google.com with SMTP id bo14so1917916pjb.1 for ; Mon, 18 Nov 2019 14:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=aDq0kNBJsnSYd1cicfZMAYlWgFp8jljA2GgxoQ8Xj50=; b=vZp0ZeEO+KyImIk0fqI3iviJYXis/xHx+hHbdhFrmVLhSDJoak3yzjPFbo7PcuDfrc gmI1MmzvDviy5JzFzeofFvPaF9p6ei5fT+0ETPlinNCrjDfEEUy5Abe+kCvF+5gnHNyv iJe61ILIGswhgeTJ/4lxDBIbdyd6P+/P4AFztx1mgpIxbe4Vf4/muuNwrHbF9W3Qyq+w F6p9SdGfkhz0LGfVBa5JVa/JaYWoXlT9NnntY6im0e7y/h7kykrkQbDsoNdoce3e9Gya utTIYshXmQvSLEAU/LWkvG4bjgmArEyt5dWhmWllxKQ6O4eyqSa+82ZPYuwopZwCAqYg Ck6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=aDq0kNBJsnSYd1cicfZMAYlWgFp8jljA2GgxoQ8Xj50=; b=noAtx+MuIDtDcstUboIXfW43BKLY46Xie1sfEA7m1nPdIirTQ4hiZEoyES3SmhPuEu MZ/NfEt2MhrJevAnJvZ5el4G95P+rCKl/nVeuquJtuvm1JhEC2XuXKl368aoYsPgW20I ysV7taBInwtjUcwtneUlJcJ0GONYw58AjCuQwRzTeWUDF14J1GV4zMyCntakI8OZj6YW 9JV360N+d5iYzva61flJkooT8epOS8pr9RRBgsXsANffls6H8bPNV4INygsm9hhVglmS Kb+PM35/3wOOKeD52qKVOiJ0bUBb5+4OXw1VoVIDH0zgZBGrVma93Go7E/NAJrWcp3bq //8A== X-Gm-Message-State: APjAAAVOPkDQwVXObcolEZKIQiIQggFj3mQ7cwe53ZAqbKoTppIVJjw5 8v9g6zTVrFGegcb/xqwHeJ8= X-Google-Smtp-Source: APXvYqyN33jrkwCx7nE/u4ECXSXSIl+UyBjAkWZEwtTYDTlRt6K87zfd3lvH5Zfqsz16Ic3lzjZu5Q== X-Received: by 2002:a17:902:8c8a:: with SMTP id t10mr25066010plo.325.1574116594338; Mon, 18 Nov 2019 14:36:34 -0800 (PST) Received: from [172.16.186.40] ([101.100.166.67]) by smtp.gmail.com with ESMTPSA id s18sm23081640pfm.27.2019.11.18.14.36.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 14:36:33 -0800 (PST) From: "Glenn Deen" To: "Joe Abley" Cc: add@ietf.org Date: Tue, 19 Nov 2019 06:36:31 +0800 X-Mailer: MailMate Trial (1.13r5655) Message-ID: In-Reply-To: References: <20191118020806.AD1D51969BB0@fafnir.remote.dragon.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 22:36:39 -0000 On 19 Nov 2019, at 5:22, Joe Abley wrote: > On Nov 17, 2019, at 21:08, Paul Ebersman wrote: > >> sm> Commenting about jurisdiction, an IETF Area Director was >> quoted as >> sm> stating that: "[DoH] will allow journalists in hostile regimes to >> do >> sm> their jobs more safely, or people in heavily censored countries >> to >> sm> get access to the truth". First of all, that is a very narrow >> sm> use-case. Secondly, the argument of "getting access to the >> truth" >> sm> sounds very convenient. >> >> acampling> I agree that the use case is indeed very narrow. I'd add >> acampling> that better tools are already available to aid dissidents >> and >> acampling> others that do not impair the use of the web by other >> large >> acampling> groups (eg children, enterprise users etc) and in any case >> acampling> question the validity of the dissident use case for DoH, >> do >> acampling> not believe that it stands up to examination. >> >> Agreed. Tor/VPN and similar solve the dissident case; DoH is an >> insufficient protection against state actors or folks with similar >> resources. >> > > I don't know whether I agree with this or not. This commentary misses > the more general point that if only dissidents use these other > options, it will be obvious to an observer that dissidents are > speaking. Is that ok? I don’t agree with that analysis. It would require VPN or TOR use to be only a tiny portion of network traffic which isn’t true. Both are robust and growing. There is a very healthy and diverse amount of network traffic for these today and it’s continuing to grow. Tor/VPN remains the very best ways to hide if you need and want too. > > This seems similar to the argument that you only need encryption if > you have something to hide. I thought IETF consensus was different. I don’t think we ever reached consensus on the idea that just throwing encryption at something solved the privacy issues. We did talk about the need for solutions to the problem of monitoring, but I thought the consensus was that each situation needs analysis, understanding, and thought to address. Encryption may be a tool in some situations, but if it’s entirely possible to add encryption but not actually fix the monitoring problem you set out to fix. . > > The problem with VPNs in general is that naive users (most users) have > no good way to trust their tunnel termination points. That problem is 100% true of DoH and DoT as well. The surface on that issue is unchanged by anything we are discussing here as it’s entirely a trust-policy issue and not technical. > There are also > fewer termination points than there are potential users, so this is > another example of centralisation which in general I think is > reasonable to be considered at odds with privacy. That’s not entirely accurate. There are tremendous numbers and diversity of VPN endpoints on the network and they are constantly adding new ones and removing old ones. -glenn From nobody Mon Nov 18 14:46:16 2019 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 D4093120B6A for ; Mon, 18 Nov 2019 14:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.336 X-Spam-Level: * X-Spam-Status: No, score=1.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_PASS=-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 eawj8Wd75P6p for ; Mon, 18 Nov 2019 14:46:13 -0800 (PST) Received: from mail-pj1-x1033.google.com (mail-pj1-x1033.google.com [IPv6:2607:f8b0:4864:20::1033]) (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 A7125120B69 for ; Mon, 18 Nov 2019 14:46:13 -0800 (PST) Received: by mail-pj1-x1033.google.com with SMTP id w8so1920891pjh.11 for ; Mon, 18 Nov 2019 14:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=HHl4Go2r0VEH5miXZ1NMAPzHYDkJkB3JzJrpRdGXN2g=; b=OrhxMBQx6Ujr0GlYAp8pM049PlouDnTM6PWyxD0H38KjT/wbPENMSoRc/iqZIbErbt Ayb5C/+furhVaY2VDBvLTGW7fzfn11+5+vcQIJLykRtKyci1gCD+/N+xV23ojuXVLmBf xaZLDJvOdTvD7qrzP6oMuy35dorXzBViY0Is+69CLm+gcrPQS78vqZtFMt4ISU9YTGTl 5swFR4o5jT3UAAeiLf0enZkwK03thqPoYKyinyIJUfNzYDbyxeM3LmBq8AS59JFN4Y7J qvJQJ3xilqb/O3+zI8j1o7V2HA6WcZi+bfbQfc9t/Qf51pwn8BWf3DjYLQ+5lWT3SeNt o2uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=HHl4Go2r0VEH5miXZ1NMAPzHYDkJkB3JzJrpRdGXN2g=; b=D385syLN92IT3vpQE5AwUYQcj/zEm0BbhXZZQiNB3h3rqeXTBGGMsjMm2U1+9ynWoU 8xpVBwsohh9QTvAc8tyQ3wOyIFrlKduuHqKegE5roMT8GoJIdqLIzzXYppdNCkEr/Emb ULo5Jpm/PPqt0x2KrjOkEpnqPsQ99VD+M1IKAJP+L0ZJQ00bYWKabGwJwvK8GW+KyqyX 6w+9g09vk0RUDj9gNZLKketR3L08FKHvYHNTzLnsiD0EflJv2wpWBIWfXMyW0beZ0/0R WsHy0zaoSB1Gln6Ft0YV18FKLyXnNLI9qaM+yMiF+Y6z6bi5N60VRj7r0S/Q2ucTvYf+ xPag== X-Gm-Message-State: APjAAAUeLFFL+5MiyVf4+1DKM30AY/0f7RU/vWMmfGPbCrvFM9h9zARs QzC71XBY0SQDtrZCETOY7y8= X-Google-Smtp-Source: APXvYqwx/fdN+KlGkEWut/d0AI7AQQF1k8nChJOQuIBLhoyUTf6GwaIvX7IAQqZrZhToJrvlr/PLSA== X-Received: by 2002:a17:90a:fa96:: with SMTP id cu22mr1783644pjb.121.1574117173179; Mon, 18 Nov 2019 14:46:13 -0800 (PST) Received: from [172.16.186.40] ([101.100.166.67]) by smtp.gmail.com with ESMTPSA id p16sm22579453pfn.171.2019.11.18.14.46.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 14:46:12 -0800 (PST) From: "Glenn Deen" To: "Dave Lawrence" Cc: "ADD Mailing list" Date: Tue, 19 Nov 2019 06:46:10 +0800 X-Mailer: MailMate Trial (1.13r5655) Message-ID: <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> In-Reply-To: <24018.45797.55312.687430@gro.dd.org> References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 22:46:15 -0000 On 18 Nov 2019, at 23:04, Dave Lawrence wrote: > Ted Lemon writes: >> What putting it in the charter does is not merely to give us >> permission to discuss it, which we already have, but rather >> indicates that there is consensus to work on those things, which >> there clearly is not. Hence, they do not belong in the charter. > > Apparently despite my efforts I was not clear. I see it as something > that can be discussed toward the end of still producing documents that > describe why exactly we are not able to otherwise achieve consensus on > some issue. That, to me, is meaningfully different than just going > round and round in circles. That provides a useful statement of why > the IETF is where it is on those topics. > If I’m understanding that the suggestion is to have people write drafts on which consensus won’t ever be reached? If that was done it doesn’t quite work in the IETF process as things which are just drafts and do not get consensus and do not get adopted carry no weight/meaning and expire. This would be a lot of work by the WG with no work product to show for it. It seems that a large portion of the topics that won’t get consensus are in fact policy and not technical topics and hence aren’t good topics anyway to work on at the IETF as we create protocols not policy. That’s not to say that the policy world doesn’t provide requirements that IETF protocols must address, it’s just that the policy isn’t drafted, crafted, or created in the IETF. If you were to remove the policy topics from the charter it would greatly simplify and focus the work product of the WG to streams that actually would produce output results. -glenn From nobody Mon Nov 18 14:51:18 2019 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 60C8C120B92 for ; Mon, 18 Nov 2019 14:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.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 ngrjyyFB14lZ for ; Mon, 18 Nov 2019 14:51:08 -0800 (PST) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (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 6B59E120BAE for ; Mon, 18 Nov 2019 14:51:08 -0800 (PST) Received: by mail-qv1-xf2a.google.com with SMTP id cv8so7163769qvb.3 for ; Mon, 18 Nov 2019 14:51:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=zVpgznuQTso40Sh0Rtc8owH99114hjHm4h2N1LdapPw=; b=IavQQyEVOmF4c5tZht7xOaDl7ikt4u5nzzJtAZXZ7JqXqYwmRBp6G0merHJQCfFbsy rbB4ZWI+SBlcp+jkAu9B87K1I9B3Fe2/iY0g+HCzxvskY60w6yuzm3JUD97FRpKMNaZv /P87irMKayDBjV4tPf8g3rOd32rNfbo4wzrzM= 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=zVpgznuQTso40Sh0Rtc8owH99114hjHm4h2N1LdapPw=; b=jn9vje27kbOTm1KoSq8C1pAa2aZ/5hHV/WIDks1yxQrkZj8S4Z2yEFeurCQwmMaYVI iQyFZd/d7UuG5MceiWhTOlWS+QMTdwI2Bvy3z4IzO1ps6oKeedPl6YKvPcR2Obbkb0XP tSi3a5cS5eY6+p1lU/y7i/5EMdIvBz9gsNOLg/JIp3WV33JaWiKaBrs/MuQztbzIt6rC o0/Taky6vUEL+KWfPukv9Ut/iaEOAPD6jSlW2JqXdUlpeWtb5K5TGOj9ymystzZQ+3LA owUtzwPNS8X9MHmtQByrdahLi2E0l99G4d4ndzKrpxNcX+wTJl6w+t4tjg9ttqdtEH5J zaJg== X-Gm-Message-State: APjAAAV15raPRfFPuAMLQJkbeXaeECrVuO/hrRtM3/Pn1bt646GMh913 BpChANIbcnC5AFE0sdzAa8hwUYjzEdzti1LY X-Google-Smtp-Source: APXvYqzjLKZRozRcTPstCsQpcKYGHC0Dn3HVYLA6xApr5aqqD8uts4JXBAhC4SbTu5f/5V5Cvxc9Tg== X-Received: by 2002:a0c:80c9:: with SMTP id 67mr26905732qvb.178.1574117467277; Mon, 18 Nov 2019 14:51:07 -0800 (PST) Received: from ?IPv6:2607:f2c0:e784:350b:adf3:d11e:e172:d325? ([2607:f2c0:e784:350b:adf3:d11e:e172:d325]) by smtp.gmail.com with ESMTPSA id o3sm11487907qta.3.2019.11.18.14.51.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 14:51:06 -0800 (PST) From: Joe Abley Message-Id: <48194467-906E-4195-9342-BBCC87A031D2@hopcount.ca> Content-Type: multipart/alternative; boundary="Apple-Mail=_6C8EF498-EE73-4774-AF7F-8309393029C8" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\)) Date: Mon, 18 Nov 2019 17:51:05 -0500 In-Reply-To: Cc: add@ietf.org To: Glenn Deen References: <20191118020806.AD1D51969BB0@fafnir.remote.dragon.net> X-Mailer: Apple Mail (2.3601.0.10) Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 18 Nov 2019 22:51:16 -0000 --Apple-Mail=_6C8EF498-EE73-4774-AF7F-8309393029C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 18 Nov 2019, at 17:36, Glenn Deen wrote: > I don=E2=80=99t agree with that analysis. I'm obviously not writing very clearly. My point is that I think the = problem deserves more analysis, not that the illustrations of that point = I tried to come up with in my e-mail were sufficient. > I don=E2=80=99t think we ever reached consensus on the idea that just = throwing encryption at something solved the privacy issues. Sure, but that's not actually what I am saying. I'm talking about the = idea of encrypting just what needs to be encrypted vs. encrypting = everything. There was a groundswell of support for encrypting = everything. The prevalence of TLS for HTTP is frequently cited as a = great success. >> The problem with VPNs in general is that naive users (most users) = have >> no good way to trust their tunnel termination points. >=20 > That problem is 100% true of DoH and DoT as well. In the sense that I intended that could well be true, except that we = have not got as far as designing service discovery mechanisms or = specifying the authentication or service description facilities around = how those protocols can be deployed, so the door is still somewhat open. >> There are also >> fewer termination points than there are potential users, so this is >> another example of centralisation which in general I think is >> reasonable to be considered at odds with privacy. >=20 > That=E2=80=99s not entirely accurate. There are tremendous numbers = and diversity of VPN endpoints on the network and they are constantly = adding new ones and removing old ones. I think it's uncontentious to say that the numbers and diversity of = endpoints for any VPN (or tor-like network) are definitively less than = the number of possible sources of traffic on the Internet. Any routing = of traffic through such a network is absolutely a concentration of = traffic. Joe= --Apple-Mail=_6C8EF498-EE73-4774-AF7F-8309393029C8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = 18 Nov 2019, at 17:36, Glenn Deen <rgd.ietf@gmail.com> = wrote:

I don=E2=80=99t agree with that = analysis.

I'm = obviously not writing very clearly. My point is that I think the problem = deserves more analysis, not that the illustrations of that point I tried = to come up with in my e-mail were sufficient.

I don=E2=80=99t= think we ever reached consensus on the idea that just throwing = encryption at something solved the privacy = issues.

Sure, = but that's not actually what I am saying. I'm talking about the idea of = encrypting just what needs to be encrypted vs. encrypting everything. = There was a groundswell of support for encrypting everything. The = prevalence of TLS for HTTP is frequently cited as a great = success.

The = problem with VPNs in general is that naive users (most users) have
no good way to trust their tunnel termination points.

That problem is 100% true of DoH and DoT as = well.

In the = sense that I intended that could well be true, except that we have not = got as far as designing service discovery mechanisms or specifying the = authentication or service description facilities around how those = protocols can be deployed, so the door is still somewhat = open.

There = are also
fewer termination points than there are potential = users, so this is
another example of centralisation which = in general I think is
reasonable to be considered at odds = with privacy.

That=E2=80=99s not entirely accurate.  There are = tremendous numbers and diversity of VPN endpoints on the network and = they are constantly adding new ones and removing old ones.

I = think it's uncontentious to say that the numbers and diversity of = endpoints for any VPN (or tor-like network) are definitively less than = the number of possible sources of traffic on the Internet. Any routing = of traffic through such a network is absolutely a concentration of = traffic.


Joe
= --Apple-Mail=_6C8EF498-EE73-4774-AF7F-8309393029C8-- From nobody Mon Nov 18 14:52:05 2019 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 D7103120B9C; Mon, 18 Nov 2019 14:51:51 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 m5DHwyYExu_V; Mon, 18 Nov 2019 14:51:50 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 08664120BB6; Mon, 18 Nov 2019 14:51:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id F08B666018F; Tue, 19 Nov 2019 00:51:48 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UIE_9Uts1Ooq; Tue, 19 Nov 2019 00:51:47 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id DA4316600AB; Tue, 19 Nov 2019 00:51:45 +0200 (EET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Jari Arkko In-Reply-To: Date: Tue, 19 Nov 2019 06:51:42 +0800 Cc: dns-privacy@ietf.org, ADD Mailing list , Ted Hardie , Martin Thomson Content-Transfer-Encoding: quoted-printable Message-Id: <60E5B91A-68A3-4799-B365-CDF261DAB133@piuha.net> References: <680390BE-E819-4951-98EE-C77E9C60E495@piuha.net> To: Brian Dickson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Add] [dns-privacy] Draft on the use of multiple recursive 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, 18 Nov 2019 22:51:58 -0000 Brian, Thanks for your comments. Focusing on one item: > Using bind-style syntax, I would imagine something like: Something like this would definitely be useful. It is important to = observe though that there are interactions with the ability to keep = things private and excessive round-robining/going-to-alternate. The = second bullet in Section 3 talks about this in the draft. With that = caveat, having an expressive way to define which resolvers you want to = talk to is much needed. Jari From nobody Mon Nov 18 15:12:05 2019 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 D842D120A3D for ; Mon, 18 Nov 2019 15:12:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aL5U7AVUqOGw for ; Mon, 18 Nov 2019 15:12:01 -0800 (PST) Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (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 286D8120919 for ; Mon, 18 Nov 2019 15:12:01 -0800 (PST) Received: by mail-io1-xd34.google.com with SMTP id x21so20920138ior.2 for ; Mon, 18 Nov 2019 15:12:01 -0800 (PST) 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=c+Cnm7lumadMgyyaagrj538/M8yHMyjygAbW7/SyrhA=; b=tyvbXoRqOFF3P0eezUoNDnBGzQAnT+X54MwS2BiIGV5K5Usx8OU3pLBqKCaYtdbP3/ dfAC3IVWIP4sqbjoD/dGqdIHRfJGkQezmuvd1d+2L+oH4sxXeOkOT6pak7/BMXS4FQfA 31CdJxUirPl8+JE3bFIZKZX7d/txK2HbxbNU+jUqJ9YY7tkxW5yn746IhxiDSNFZCzTu mqME3LleL1ju1wt/gDIkqTcAadU+hL4u0BRX2AweCmXmppFXk7aJosLhE15mr6NEIuoN KY65+aR8zlKVHDvwX0DxDoRLV+Ofh+yRET7M2/M8Se7zrdnMs5gPpaL8CGy40kimYfm4 0rOw== 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=c+Cnm7lumadMgyyaagrj538/M8yHMyjygAbW7/SyrhA=; b=F+iKobFyaKK6m6U+T2rVMwN9uM2T7esYiFFzzTuOz6PpFuirf81qiBr/CIPkFabygr S/GrcQMwk6AnzvF8nvThdS4oTtwdHnGSU5d4PgZvwDeWc1yQc77KdsMXklqRwvERPYLv HZbA83pYzYO3ICblv71uaUwPeC7Y4bAifJQvtblf+NP72rETouk8yWMj5GJCTjtliCCj B3gvLRotzbJsaBawsb2svJt/1I5js5lQYdBUhaQNsZqYpXG+IxSL1/A7svLJ1zn9VCmO lYmdbUPnP0I4WGRiMgUyrZH2jtMu0O52G93IijNhjfOXUgWvef8Imp4ohSklx6WPcUci iCcg== X-Gm-Message-State: APjAAAVoK62rWIGr92bB3laW0P8t1DVrO25IaLng/fCIlLqKr4LKHp+/ 0FI3n5SC9xfTezC8wdmGQ3m+89su2gAeUB1cvAk= X-Google-Smtp-Source: APXvYqyDbNtnefNPdUgha7mtCfq0/dCCQo4J4MCMYgVjNbiJszxOt5QsWzU3K4iL+rkrojHmtqieToQehQCDSitLvGA= X-Received: by 2002:a05:6602:22c3:: with SMTP id e3mr6004392ioe.73.1574118720132; Mon, 18 Nov 2019 15:12:00 -0800 (PST) MIME-Version: 1.0 References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> In-Reply-To: <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> From: Rob Sayre Date: Mon, 18 Nov 2019 15:11:48 -0800 Message-ID: To: Glenn Deen Cc: Dave Lawrence , ADD Mailing list Content-Type: multipart/alternative; boundary="00000000000025ddf80597a713d3" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 18 Nov 2019 23:12:03 -0000 --00000000000025ddf80597a713d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 18, 2019 at 2:46 PM Glenn Deen wrote: > On 18 Nov 2019, at 23:04, Dave Lawrence wrote: > > > Ted Lemon writes: > >> What putting it in the charter does is not merely to give us > >> permission to discuss it, which we already have, but rather > >> indicates that there is consensus to work on those things, which > >> there clearly is not. Hence, they do not belong in the charter. > > > > Apparently despite my efforts I was not clear. I see it as something > > that can be discussed toward the end of still producing documents that > > describe why exactly we are not able to otherwise achieve consensus on > > some issue. That, to me, is meaningfully different than just going > > round and round in circles. That provides a useful statement of why > > the IETF is where it is on those topics. > > > > If I=E2=80=99m understanding that the suggestion is to have people write > drafts on which consensus won=E2=80=99t ever be reached? > I don't think that's the intent. I believe the aim is to prevent protocol discussions from being derailed by policy interjections. That way, WG participants will understand that concerns around items from the second list in the charter will not delay progress on items from the first list. thanks, Rob --00000000000025ddf80597a713d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 18, 2019 at 2:46 PM Glenn Dee= n <rgd.ietf@gmail.com> wrot= e:
On 18 Nov 2019, at 23:04, Dave Lawrence wrote:

> Ted Lemon writes:
>> What putting it in the charter does is not merely to give us
>> permission to discuss it, which we already have, but rather
>> indicates that there is consensus to work on those things, which >> there clearly is not. Hence, they do not belong in the charter. >
> Apparently despite my efforts I was not clear.=C2=A0 I see it as somet= hing
> that can be discussed toward the end of still producing documents that=
> describe why exactly we are not able to otherwise achieve consensus on=
> some issue.=C2=A0 That, to me, is meaningfully different than just goi= ng
> round and round in circles.=C2=A0 That provides a useful statement of = why
> the IETF is where it is on those topics.
>

If I=E2=80=99m understanding that the suggestion is to have people write drafts on which consensus won=E2=80=99t ever be reached?=C2=A0

I don't think that's the intent. I believe = the aim is to prevent protocol discussions from being derailed by policy in= terjections.

That way, WG participants will unders= tand that concerns around items from the second list in the charter will no= t delay progress on items from the first list.

tha= nks,
Rob

--00000000000025ddf80597a713d3-- From nobody Mon Nov 18 16:56:11 2019 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 BF28812004A for ; Mon, 18 Nov 2019 16:56:10 -0800 (PST) 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 RAAuspHjbvsr for ; Mon, 18 Nov 2019 16:56:09 -0800 (PST) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17E44120025 for ; Mon, 18 Nov 2019 16:56:08 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id E785A924BF; Mon, 18 Nov 2019 19:56:06 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24019.15782.928519.38360@gro.dd.org> Date: Mon, 18 Nov 2019 19:56:06 -0500 From: Dave Lawrence To: "ADD Mailing list" In-Reply-To: <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 00:56:11 -0000 Glenn Deen writes: > If I=E2=80=99m understanding that the suggestion is to have people wr= ite=20 > drafts on which consensus won=E2=80=99t ever be reached=3F [...] Thi= s would > be a lot of work by the WG with no work product to show for it. "If you choose not to decide / You still have made a choice" -- Neil Peart There would be work product. Published documents that explain why the issues are sufficiently difficult that the IETF is taking a pass. Maybe it's because what I am saying is admittedly uncommon in the IETF that I've not been successful in getting the idea across. It's something that I've been advocating for a while though, that we should have a more effective history of not only proposals that succeed but also those that, for whatever reason, did not. =20 We publish the Request for Comments series, which is what made it through the gauntlet already, with discussion largely done rather than beginning. I'm not suggesting that be changed, just that we do better about debriefing why drafts failed. Sometimes it's fairly innocuous, sometimes it is volatile, but either way it is difficult for someone who wasn't part of it to know. These needn't be long, heavy documents the relitigate every aspect that brought us to the judgment that we just won't be able to reach consensus. Sometimes the explanations are fairly simple, that tautologically the immovable object is in irreconcilable conflict with the unstoppable force -- or more aptly, that two immovable objects sit separated by an insurmountable mount. Sometimes the explanation is essentially a reference to RFC 3935 (A Mission Statement for the IETF). RFC 7258 (Pervasive Monitoring Is An Attack), or the like. In any event it should be easier to achieve consensus on why consensus isn't possible, and document it for everyone. And again, my thoughts here are predicated on my belief that the IETF not working on something doesn't mean it isn't worked on, it's just worked on elsewhere to various effects, one of which is sometimes that it's still a relentless issue within the IETF anyway. (NAT, anyone=3F)= The IETF has an ongoing challenge in maintaining its relevance, and I think that providing more transparency not only through discussion but also via clear summaries of tough issues is one important aspect of doing that. I hope this makes my view clearer. --tale From nobody Mon Nov 18 17:06:56 2019 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 B08021200F7 for ; Mon, 18 Nov 2019 17:06:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dne1MzL7mqgr for ; Mon, 18 Nov 2019 17:06:51 -0800 (PST) Received: from mail-pl1-x633.google.com (mail-pl1-x633.google.com [IPv6:2607:f8b0:4864:20::633]) (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 9980A12000F for ; Mon, 18 Nov 2019 17:06:51 -0800 (PST) Received: by mail-pl1-x633.google.com with SMTP id h13so10794084plr.1 for ; Mon, 18 Nov 2019 17:06:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding; bh=4hiUYJOuzeBcJzbwy0+7oWVMbVdEeypO6Nkw71U68iA=; b=n6l7xK4R4drz34yVlDUntXfk29bNV+IZFKC86uE+AMKWoY1syZElq6gO+17Dt+XZ0i BOnZvOIfG8raKUL2RqllYnezg2aa3yfIQg6s5z3KwQ3cFvm6NOd0OJwTRX1RQ5hn/BPt hGrQ5ltzfC5+R74JdFCqzQXtE1zFR2koSYEwz17ho4dN/mwqrfpHRjY9rvPSP4WTmrsa ZvUUwuFJ8AxqqGWnGl3iMBOXNbUrCR2j102tCRWvfMSaGaJSF/CKxk8bimU83IrNjEkt YNdD5/DQYbHfwVeBY721W/dhuNUnWucRIXajRn6y6iXvrcE2m7wU0yVEJZZaR7YpZEe3 378Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=4hiUYJOuzeBcJzbwy0+7oWVMbVdEeypO6Nkw71U68iA=; b=rt5jr2Ry/c44Xv7UsORguaLQHV0b/T50I5X36dY4xHXwzb4bAPQ6UGYmNHl22AhYqf r2zgjRDN3cRigRSISYcsUNjC8Pkyh04HG+0ywoXl5KGFFNbN+IQZK2IiosahQVrK/xNS eKgCMLLITtT8EzBtYNcqE9HFMwYDgAxuTLJv/NBwERn44esw3SPG58G7hM+mOsaEbOew 8I9wg8yRq3lnjo2ZQyUEL69x0HKJK8bFOB2V0CkVSv76Vb7TjZ8+QTKgK0cTKsrDpjV7 rB8Y2kB4GQ8IkrBmZWbJTqkKaq2Omn205DaeGbQnrJABm+7ZNrBpkEroD+vAhfXVtWK1 Fu1Q== X-Gm-Message-State: APjAAAXP6Qn5ER+P0WKGdWbfe5K9fxqtP/yNKYN886gdDNW8Z2oH4ytX PYk4t5F/LLqz7TpWOKviFl0= X-Google-Smtp-Source: APXvYqxGmQ49Z1XIx7LzFViOYDK8qlVRnRBV9Jep3oyTSYl5A5bhraIhQRi+Qu7cFMjh2K+hpLX/TQ== X-Received: by 2002:a17:90a:4e5:: with SMTP id g92mr2611347pjg.94.1574125610862; Mon, 18 Nov 2019 17:06:50 -0800 (PST) Received: from [31.133.131.48] ([2001:67c:370:128:8cc2:92b8:3428:6dcb]) by smtp.gmail.com with ESMTPSA id a66sm23118458pfb.166.2019.11.18.17.06.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 17:06:50 -0800 (PST) From: "Glenn Deen" To: "Joe Abley" Cc: add@ietf.org Date: Tue, 19 Nov 2019 09:06:47 +0800 X-Mailer: MailMate Trial (1.13r5655) Message-ID: <08FF5C55-C356-468E-8B25-BA8046318279@gmail.com> In-Reply-To: <48194467-906E-4195-9342-BBCC87A031D2@hopcount.ca> References: <20191118020806.AD1D51969BB0@fafnir.remote.dragon.net> <48194467-906E-4195-9342-BBCC87A031D2@hopcount.ca> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 19 Nov 2019 01:06:55 -0000 On 19 Nov 2019, at 6:51, Joe Abley wrote: > On 18 Nov 2019, at 17:36, Glenn Deen wrote: > >> I don’t agree with that analysis. > > I'm obviously not writing very clearly. My point is that I think the > problem deserves more analysis, not that the illustrations of that > point I tried to come up with in my e-mail were sufficient. > >> I don’t think we ever reached consensus on the idea that just >> throwing encryption at something solved the privacy issues. > > Sure, but that's not actually what I am saying. I'm talking about the > idea of encrypting just what needs to be encrypted vs. encrypting > everything. There was a groundswell of support for encrypting > everything. The prevalence of TLS for HTTP is frequently cited as a > great success. > >>> The problem with VPNs in general is that naive users (most users) >>> have >>> no good way to trust their tunnel termination points. >> >> That problem is 100% true of DoH and DoT as well. > > In the sense that I intended that could well be true, except that we > have not got as far as designing service discovery mechanisms or > specifying the authentication or service description facilities around > how those protocols can be deployed, so the door is still somewhat > open. While I’m 100% supportive of the work on service discovery mechanisms, that’s technical work which I do support being done here. I would still suggest the policy aspects of “who can you trust” will always be beyond the scope and ability of an IETF WG to define as it’s a subjective evaluation or legal evaluation or regulatory evaluation and not a technical one. I’ll observe that if we can agree on that, it will help clear the path forward. It’s not that I’m saying not to work on protocol features that can be used to carry choices, I am saying we keep getting mired in various discussions on what people would like to see developed as policy vs how would a protocol carry choices. > >>> There are also >>> fewer termination points than there are potential users, so this is >>> another example of centralisation which in general I think is >>> reasonable to be considered at odds with privacy. >> >> That’s not entirely accurate. There are tremendous numbers and >> diversity of VPN endpoints on the network and they are constantly >> adding new ones and removing old ones. > > I think it's uncontentious to say that the numbers and diversity of > endpoints for any VPN (or tor-like network) are definitively less than > the number of possible sources of traffic on the Internet. Any routing > of traffic through such a network is absolutely a concentration of > traffic. This is a great example of a question that leads to policy and not technology. There already are technologies which will let any device to act as an endpoint for a VPN or TOR or even other hiding methods such as the one that lets any website act as a proxy to any other website. The technology for that has not only been done, but done in a variety of flavors. The choice to deploy or not is a architecture, policy, and business choice that is out of scope at the IETF. Yes there are policy pieces that need someone(else) to work on that would use the work in the IETF, but the IETF is not the place to try and have such discussions precisely because we don’t have the process, people, or practices to come to consensus on them. I’m suggesting the IETF path forward is to focus only on what work product the ABCD WG can produce - things like discovery mechanisms and not things that fall into policy. If it can’t be a practical work produce of the WG, it shouldn’t be in the charter beyond identifying that there are policy issues that will come in from OUTSIDE of the IETF. Basically I’m advocating for applying a narrow charter on actual possible deliverables, that acknowledges there is more in the topic but it’s out of scope. -glenn From nobody Mon Nov 18 17:11:40 2019 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 9F52D120025 for ; Mon, 18 Nov 2019 17:11:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FE0yCy22UBfZ for ; Mon, 18 Nov 2019 17:11:37 -0800 (PST) Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (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 AE54812000F for ; Mon, 18 Nov 2019 17:11:37 -0800 (PST) Received: by mail-pg1-x52f.google.com with SMTP id z188so10502786pgb.1 for ; Mon, 18 Nov 2019 17:11:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:in-reply-to:references:mime-version :content-transfer-encoding; bh=GgukSmXxRT3XFElODKsRcKRBdzUjhx63YLMsYEVMCaY=; b=oWTB3eCDDP4VJOc05DJDs3D2xEiHzrcrV6XumVq4IktaTPviorrOxMEllS+W2EM15U Z6igKNBQIjTElbzlcgFthRK1KVi0WTpbdRkVLxk1Yp5MxPsdZ8S7uJwA1JCxviZzkJmY U80CXzbTbOG2cqUcSI8+rKbKaDC+swmX8QFSmoFso/N6lfA3voZAFKXrWc44EHq5SqwW YqJiBLB4tX5PcKmZhqJ1mVOSyJ+xU2atVy73PsrJGkFsGzoxTU9r+FQgEB+LPEdBR/Kj mEfQ789IPDubRgIRp0jjXqyyB95bWlKGw3L7QoStQVc/vmgOxR9Dxy3RgQ+wNIhJCP1H BnRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=GgukSmXxRT3XFElODKsRcKRBdzUjhx63YLMsYEVMCaY=; b=AaULiZJelI7iDHvarR+//EDxpyO8imcOcx05LMFyk+r0orYZ4uDIVdnMD1tUgXjF4P B0V2WQ1xtbSvcb6CJY2kx+wcsrGuhjmUSZGF0S7zp6ouPFd8oU+W/nFfIgf9AUW1Cf3N v5egoHRPZjjj6A08dC93/tj2n0bOSPZ2GadHWm/6tZZccuKWda6tedeNvrBYnUFk10VE qxqMd1KE4CjsMfMGIbQDM+Zpq+lIsZPoUFPtln1s2zvXDjQd6YnTJVOISfd3NY0GwiDD B2op9o6KARZ27cPs2ohHsdnkeUAMsDiIqlSshsLixeuNsx206qF2T32zl77X/n5ZEUST kwIg== X-Gm-Message-State: APjAAAW/EO7EP/6ztmPjElVhPH2YZIVyAC1PJqYfhiIzMkWXdkql3zIm MLzupRUCHTyKsnwhYGrMHujN6tI+C5o= X-Google-Smtp-Source: APXvYqzdEZuEgijEBx94hMAZzgBV1nd88BVEdTaFtCxO3akAcsp8Hy38CKUm6qLIAeRVlp7xJFvtbw== X-Received: by 2002:a62:cd87:: with SMTP id o129mr1686242pfg.49.1574125897063; Mon, 18 Nov 2019 17:11:37 -0800 (PST) Received: from [31.133.131.48] (dhcp-8330.meeting.ietf.org. [31.133.131.48]) by smtp.gmail.com with ESMTPSA id h26sm13471071pfo.93.2019.11.18.17.11.35 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 17:11:36 -0800 (PST) From: "Glenn Deen" To: "ADD Mailing list" Date: Tue, 19 Nov 2019 09:11:33 +0800 X-Mailer: MailMate Trial (1.13r5655) Message-ID: <714429D6-F764-4730-ADAE-ED16E5A8E482@gmail.com> In-Reply-To: <24019.15782.928519.38360@gro.dd.org> References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> <24019.15782.928519.38360@gro.dd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 01:11:39 -0000 On 19 Nov 2019, at 8:56, Dave Lawrence wrote: > Glenn Deen writes: >> If I’m understanding that the suggestion is to have people write >> drafts on which consensus won’t ever be reached? [...] This would >> be a lot of work by the WG with no work product to show for it. > > "If you choose not to decide / You still have made a choice" > -- Neil Peart > > There would be work product. Published documents that explain why > the issues are sufficiently difficult that the IETF is taking a pass. > > Maybe it's because what I am saying is admittedly uncommon in the IETF > that I've not been successful in getting the idea across. It's > something that I've been advocating for a while though, that we > should have a more effective history of not only proposals that > succeed but also those that, for whatever reason, did not. > > We publish the Request for Comments series, which is what made it > through the gauntlet already, with discussion largely done rather than > beginning. I'm not suggesting that be changed, just that we do better > about debriefing why drafts failed. Sometimes it's fairly innocuous, > sometimes it is volatile, but either way it is difficult for someone > who wasn't part of it to know. > > These needn't be long, heavy documents the relitigate every aspect > that brought us to the judgment that we just won't be able to reach > consensus. Sometimes the explanations are fairly simple, that > tautologically the immovable object is in irreconcilable conflict with > the unstoppable force -- or more aptly, that two immovable objects sit > separated by an insurmountable mount. Sometimes the explanation is > essentially a reference to RFC 3935 (A Mission Statement for the > IETF). RFC 7258 (Pervasive Monitoring Is An Attack), or the like. In > any event it should be easier to achieve consensus on why consensus > isn't possible, and document it for everyone. > > And again, my thoughts here are predicated on my belief that the IETF > not working on something doesn't mean it isn't worked on, it's just > worked on elsewhere to various effects, one of which is sometimes that > it's still a relentless issue within the IETF anyway. (NAT, anyone?) > The IETF has an ongoing challenge in maintaining its relevance, and I > think that providing more transparency not only through discussion but > also via clear summaries of tough issues is one important aspect of > doing that. > > I hope this makes my view clearer. > > --tale > So basically document what’s not being worked on and why it’s not being worked on? From nobody Mon Nov 18 18:02:17 2019 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 E1A9512006E for ; Mon, 18 Nov 2019 18:02:15 -0800 (PST) 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 JPZwZQ6a9JIy for ; Mon, 18 Nov 2019 18:02:14 -0800 (PST) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7462C12004E for ; Mon, 18 Nov 2019 18:02:14 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id C3D3B92535; Mon, 18 Nov 2019 21:02:13 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <24019.19749.782889.506814@gro.dd.org> Date: Mon, 18 Nov 2019 21:02:13 -0500 From: Dave Lawrence To: "ADD Mailing list" In-Reply-To: <714429D6-F764-4730-ADAE-ED16E5A8E482@gmail.com> References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> <24019.15782.928519.38360@gro.dd.org> <714429D6-F764-4730-ADAE-ED16E5A8E482@gmail.com> Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 02:02:16 -0000 Glenn Deen writes: > So basically document what=E2=80=99s not being worked on and why it=E2= =80=99s not=20 > being worked on=3F Yes, I think the whys for the record are important. From nobody Mon Nov 18 18:13:19 2019 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 455561200B8 for ; Mon, 18 Nov 2019 18:13:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ducksong.com header.b=bFmmC0Dr; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=qP3XNmug 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 3AMrhzKANNUq for ; Mon, 18 Nov 2019 18:13:13 -0800 (PST) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (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 91C0412004E for ; Mon, 18 Nov 2019 18:13:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574129593; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=sfYxaHCHE3vR0zGN5L+xoNugzt/ITpmUhoLcPgcsL3cGM+mF8RsYIBDXTkFJyswOw3EuOfOn6AnZL tqE/kEeA8qF+E/ISXCBnYy1Eae627PHIo8koF30J5kgt2MHsPPOShqS86Zf+PmkgMklMTX5umvDUOW q6ElbxBjaDQT3Atux5n/x9/hYWQXNpmpDWcDThmRbiQzrcSdjObPjnDKVefffKUeIaT3Q5yDYqPFpP XZzqLfSpAbkhBDBbu4lOY3Ki/IFPSECOtx8SJBVbCJQ30o4Hhywq2isJH5loKvRrxBg3TIcX8dzKlz R6zwTQrOJpx+HO6Y+z1TMdotlN8h94g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=XEto97S6IWNJQzaHBQpnEz85s5tbt9l8Ql6nfGPiB/0=; b=WJLu125uV8FhOOcu/lTrmxQnIF+tEVbgA6dQdYCdp5fZgvi5bKVWhRgHxILmb82yoDAGh98Tr19G+ 72ppE4gAUPIoipxivgjOLf3EWvJ/puF7HuHBQ5v6K+9jpN8j4UsMnFc0pFVEBD6D3juW1EPwzwb1rG 4QAyE3C7GEu3Zdbd0hWkX9D+VByLujrj3xZ71PY2Qm37xBGzoeNMS2MONr+7CxK+3J42RcKWxnXUMX erzgLN1Vrvd7AlSfOMCEgY92RvdSHVjg7R6g+5gOxl+bK/ZA+9nuiMs/9sG9tLG3q4eh9lDIeXOpvu DmfNDX+0s3znTtEj8pb5InN7kUxL7kg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.178; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=XEto97S6IWNJQzaHBQpnEz85s5tbt9l8Ql6nfGPiB/0=; b=bFmmC0DrtpGBnXNT8T36SWAJRPiC7gOY+CbtXa9aIUpWOg3Qd0AhXd/Xv/qbI//1ou7GVutd5JUB7 f9+Kx7veo+U6llVVp1LcFG9AwgAMeWZ66seyWqW2rHLRvgxCgjhUC4nmCW3vlkQu3TzWN3n1igcdTZ Op+JF4x1WJ8WEEBg= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=XEto97S6IWNJQzaHBQpnEz85s5tbt9l8Ql6nfGPiB/0=; b=qP3XNmugSNI8LiaaDdgRG92WCzNC9kBmXiZFKP35pcPrYVN5Az8N7LIqEWDAGiwvqP9O6EyFKFGUP 9k/71cw8WUXF+XNLxCL6K9nR4nQ9YN2fCpiHwLYXX+DlOC9epy5JPuFCq0XCZ5svqbbxiIuS6dNC5s hngH4eeEpQCACTKgXy6nn25ILS5MqfUaMS7tgkNc2haNgQtrSjs3QZHhWaSdEGjrOecE3r2BwThKja 43ZaK/vHvV3CZc0Z5KuETHDsXVSKhoU++0mXt041aQFtrMNIGX8JUZ3LOksgr/sjdWyQZQhklWkCGq XWmVQD7r4dYoaUCvAU5qdFvA6k8a5dQ== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 22cbbcbc-0a72-11ea-829e-79a40d15cccd X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.167.178 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f178.google.com (unknown [209.85.167.178]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 22cbbcbc-0a72-11ea-829e-79a40d15cccd; Tue, 19 Nov 2019 02:13:12 +0000 (UTC) Received: by mail-oi1-f178.google.com with SMTP id 14so17378724oir.12 for ; Mon, 18 Nov 2019 18:13:11 -0800 (PST) X-Gm-Message-State: APjAAAW3i0a4JDJIHDexu44y77E5pig4Jrxzn5GOWJFisRzTE/b6RRfB wAYIeOQqZY60HqReZ2sp/Zvq74urcH8pHIWoU/I= X-Google-Smtp-Source: APXvYqyL3RcxwL0pcDJvq3UniF5ESr40F7aoxSczbF0izEPzZN/JZJEdgqqg8H+nw79FbaUJ0kwZHoUKcxp0RDLqAIs= X-Received: by 2002:aca:a842:: with SMTP id r63mr1776013oie.118.1574129591249; Mon, 18 Nov 2019 18:13:11 -0800 (PST) MIME-Version: 1.0 References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> <24019.15782.928519.38360@gro.dd.org> <714429D6-F764-4730-ADAE-ED16E5A8E482@gmail.com> <24019.19749.782889.506814@gro.dd.org> In-Reply-To: <24019.19749.782889.506814@gro.dd.org> From: Patrick McManus Date: Tue, 19 Nov 2019 10:12:59 +0800 X-Gmail-Original-Message-ID: Message-ID: To: Dave Lawrence Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000001df3300597a99b9a" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 02:13:18 -0000 --0000000000001df3300597a99b9a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable such a document is not explicitly in the charter as a deliverable. indeed there are no documents in the charter as deliverables - though the scope allows, without requiring, many things. This is not good footing for a high tension group. in your view - how is this compatible with the charter? Would it be subject to the mysterious 'full consensus' requirement? Do you believe we would have full consensus on such a thing (I do not). Alternatively, are you suggesting the WG produce a document to be published without full IETF consensus on its contents? Such things have been done, but are imo not a good idea. Let's be clear. -Patrick On Tue, Nov 19, 2019 at 10:02 AM Dave Lawrence wrote: > Glenn Deen writes: > > So basically document what=E2=80=99s not being worked on and why it=E2= =80=99s not > > being worked on? > > Yes, I think the whys for the record are important. > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000001df3300597a99b9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
such a document is not explicitly in the charter as a deli= verable. indeed there are no documents in the charter as deliverables - tho= ugh the scope allows, without requiring, many things. This is not good foot= ing for a high tension group.

in your view - how is this= compatible with the charter? Would it be subject to the mysterious 'fu= ll consensus' requirement? Do you believe we would have full consensus = on such a thing (I do not).

Alternatively, are you= suggesting the WG produce a document to be published without full IETF con= sensus on its contents? Such things have been done, but are imo not a good = idea. Let's be clear.

-Patrick

<= /div>

On Tue, Nov 19, 2019 at 10:02 AM Dave Lawrence <tale@dd.org> wrote:
Glenn Deen writes:
> So basically document what=E2=80=99s not being worked on and why it=E2= =80=99s not
> being worked on?

Yes, I think the whys for the record are important.

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000001df3300597a99b9a-- From nobody Mon Nov 18 18:23:27 2019 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 22DB5120232 for ; Mon, 18 Nov 2019 18:23:25 -0800 (PST) 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 DKTZpHTnWkwF for ; Mon, 18 Nov 2019 18:23:24 -0800 (PST) Received: from gro.dd.org (host2.dlawren-3-gw.cust.sover.net [207.136.201.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF6AA12002E for ; Mon, 18 Nov 2019 18:23:23 -0800 (PST) Received: by gro.dd.org (Postfix, from userid 102) id 16C8A9255C; Mon, 18 Nov 2019 21:23:23 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <24019.21019.75455.139414@gro.dd.org> Date: Mon, 18 Nov 2019 21:23:23 -0500 From: Dave Lawrence To: ADD Mailing list In-Reply-To: References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> <24019.15782.928519.38360@gro.dd.org> <714429D6-F764-4730-ADAE-ED16E5A8E482@gmail.com> <24019.19749.782889.506814@gro.dd.org> Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 02:23:25 -0000 Patrick McManus writes: > such a document is not explicitly in the charter as a > deliverable. indeed there are no documents in the charter as > deliverables - though the scope allows, without requiring, many > things. This is not good footing for a high tension group. > > in your view - how is this compatible with the charter? I agree with your first paragraph, and my own hope is that as we work to an acceptable charter then it would be clearer on this. > Would it be subject to the mysterious 'full consensus' requirement? I personally do not agree with the full consensus term, for the objections that others have already raised on the list. I think we should use consensus as the IETF has traditionally understood it. From nobody Mon Nov 18 18:52:53 2019 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 30A31120232 for ; Mon, 18 Nov 2019 18:52:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 LAQeI2wD1Wrz for ; Mon, 18 Nov 2019 18:52:47 -0800 (PST) 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 46CED120236 for ; Mon, 18 Nov 2019 18:52:47 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id 1so21413578iou.4 for ; Mon, 18 Nov 2019 18:52:47 -0800 (PST) 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=NlPktsfqwUnIRWmAKL/SxDd7vZ+svsaybsTAfqo6JNk=; b=kY0Twy3auKoY6cP7pgxxRE9y0LHJOBYMWvqOfnkaRige1JpiiIeM7iKTwRBwF3BmYQ Qa9WijRxaXeT2eZvgnS3ln8gikggQ8KzxmP/ZTr0F0uoYiw3vWS4EQgsC0Vz7ucw4Q96 xi7WcRwAkHQ5inhOWRGST4vEN9iblVTqh3tQKwhJdLkxLxd+36biOw4dYspwjyx51I6W D8mfR/ZN3I7lgZpUfNoqXW1Zhu2MVz21Ws6zhv7a9PZwoJnSPlXMfEnA7oAZAjO3rlph wJ/altRUYjYa24eERHjseQyNY4+sm6qR1HDbuSeLLL4909XXHOd64QgOY2c8BeNQGlAE yauQ== 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=NlPktsfqwUnIRWmAKL/SxDd7vZ+svsaybsTAfqo6JNk=; b=iW6GdU3gRaOhnlRMT1SCKwlz6RGeL7gEZNxrH7M93Rhjj46apqtrqcvfi4/qJ0Ngm8 /oE63s3kUhPzepDYuGqu9CKP5kpII3eBAh9BbXK3rAHWEYSywoawvP+SiKtVIJg6A3LO IJSBjEmxV1aEVIviiSKDd7139RaEjFelcE3ul7TKvNewsHIfZA2FCuxel/sUSCPqf1e9 V4TOG5J6DszM2L1DM0YtInxFA4XFGrAKtcPzjwkjI0FZKVF6AsCBvUNL67cfri91lmBf NgwN6JeYt5NuAP4nNOzbEn3VAGbnoFhCbUGq9+6yP5Tky+voqX3ftWrvWg81tHxkq7A6 Fupw== X-Gm-Message-State: APjAAAXacjKSy4yfZr+TOs8wzkM5we2c4gHd/4hqaz7vACwy5POAzG/a V8ImQC+ZY9FZeZ7n04h6Bg4C76wnKTx03I9AqK3ijQ== X-Google-Smtp-Source: APXvYqzaE3U14q8+AgF/fn5GeFuyBGk10uZDqdNBncwx+GrhdZQ/Q+2IG8/4X+4+ObDFqcrZoWv+Z06+V59ieXUlhXQ= X-Received: by 2002:a05:6602:8c:: with SMTP id h12mr16532421iob.254.1574131966451; Mon, 18 Nov 2019 18:52:46 -0800 (PST) MIME-Version: 1.0 References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> <24019.15782.928519.38360@gro.dd.org> <714429D6-F764-4730-ADAE-ED16E5A8E482@gmail.com> <24019.19749.782889.506814@gro.dd.org> <24019.21019.75455.139414@gro.dd.org> In-Reply-To: <24019.21019.75455.139414@gro.dd.org> From: Rob Sayre Date: Mon, 18 Nov 2019 18:52:34 -0800 Message-ID: To: Dave Lawrence Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000b0a37b0597aa2875" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 02:52:52 -0000 --000000000000b0a37b0597aa2875 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 18, 2019 at 6:23 PM Dave Lawrence wrote: > Patrick McManus writes: > > > Would it be subject to the mysterious 'full consensus' requirement? > > I personally do not agree with the full consensus term, for the > objections that others have already raised on the list. I think we > should use consensus as the IETF has traditionally understood it. > That term is kind of strange. Does it mean "unanimity"? thanks, Rob --000000000000b0a37b0597aa2875 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 18, 2019 at 6:23 PM Dave Lawr= ence <tale@dd.org> wrote:
Patrick McManus writes:

> Would it be subject to the mysterious 'full consensus' require= ment?

I personally do not agree with the full consensus term, for the
objections that others have already raised on the list.=C2=A0 I think we should use consensus as the IETF has traditionally understood it.

That term is kind of strange. Does it mean "= ;unanimity"?

thanks,
Rob=C2=A0
--000000000000b0a37b0597aa2875-- From nobody Mon Nov 18 18:55:10 2019 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 072041207FD for ; Mon, 18 Nov 2019 18:55:09 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netorgft5189650.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 DwcHqhxKr58S for ; Mon, 18 Nov 2019 18:55:07 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100058.outbound.protection.outlook.com [40.107.10.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8528120288 for ; Mon, 18 Nov 2019 18:55:06 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ir2oTTUAjH/akhZPJToU1QCBoI3tdyewAmRVLGbiuiJdBv5+f48u32QoJ88RGZkRlPnH+4PmVB9atwOyZAOKAwwM1UlvT+C7cRsqSu+lAmFtACUqkFosMHwE9rbOYNTl7pd+BbXr4kWjt+FG4TjMOD1pmVrF4j8bNJgBHuBwShV5WUeuNl4bjsLIaUge+xCovE/vZWnp2F9Y2tnpD/ARfr1OVNcQf/fTTogMkaGwlvxyUB3bdGiTZIQk2D7dJFCrf/Yo2wtELKJqae2/MoTbhnAThgIptibGhF38u+DKK9qktwSZp2rVk1g6fEwvviPgc1cZguFOIjkmL4DIj3umug== 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=8M0eulvfFyQBigSBam5L5tj9TUGf/t89pcSLC2INxGc=; b=Yul37v8oD0ZdJTDWj03f8ER3FfCEDLmjDTW3ExBj0zRuuQ97mYAAZ8Vv7l3tZp7bEWV8SoGn3nU173cetH6ZbXF4YbVbYAfukj0LtSdAIvEMbSZWLmS0qOO78gGt5jmLnB6nd2BM6T3mp2W1VDZW6uNP9GgbaHEYeuocR3SWzOYbmgsHq4ef+k3nBa5pPy/X5HdPS2nk72hOb5E8CiNhhNUv/aoSMaGQsWgye8yAB/IJtaDRJu8rXSkt8PO4Y5VQkxPjj6a4ad8iyyf10Wa3nSbx8Q8q7lpuTA6Sy4FjnxJCDBFYfiJMlNtAwrKlwa8qzTqlvDUyATvcOipIXsSUBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8M0eulvfFyQBigSBam5L5tj9TUGf/t89pcSLC2INxGc=; b=YQS+GoXgK+LKZiFimTEbEs2gie0q9cMp0jHv213hgn02aro9mnWEY6DApXZW1p0qUji38HZvaU75/dAR0V8WGGjuhRvSI6ruhXmr0aF5zSFiiYDkfWrzOHgUAT0Wx1CMfLCI8SZWYkv+2W4xF/XRzTRkh2edGV78LIAcstiHuOg= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB0287.GBRP265.PROD.OUTLOOK.COM (10.166.99.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.26; Tue, 19 Nov 2019 02:55:04 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712%7]) with mapi id 15.20.2451.029; Tue, 19 Nov 2019 02:55:04 +0000 From: Andrew Campling To: Rob Sayre , Glenn Deen CC: Dave Lawrence , ADD Mailing list Thread-Topic: [Add] Agenda and Revised Charter for the ABCD BoF Thread-Index: AQHVnnZRbfdauIILhE+N3YiK8SS306eRytIQ Date: Tue, 19 Nov 2019 02:55:04 +0000 Message-ID: References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [89.187.162.121] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d2be5ecc-8291-4d8e-1498-08d76c9be0d3 x-ms-traffictypediagnostic: LO2P265MB0287: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39830400003)(346002)(396003)(376002)(136003)(199004)(189003)(4326008)(66946007)(66476007)(64756008)(66446008)(8676002)(5660300002)(66556008)(52536014)(81166006)(81156014)(99286004)(8936002)(54906003)(110136005)(4744005)(316002)(25786009)(26005)(186003)(53546011)(76176011)(6506007)(102836004)(7736002)(74316002)(508600001)(14454004)(71190400001)(71200400001)(86362001)(256004)(7696005)(6246003)(9686003)(229853002)(6306002)(55016002)(6436002)(76116006)(446003)(11346002)(44832011)(486006)(476003)(54896002)(66066001)(790700001)(6116002)(3846002)(2906002)(33656002)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB0287; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7O96kqFWaHPGjZI0KKrBkJfIPQmhfqzvZiFR0Aczjn2ktftiifowLuqLFPgGWhlXO9e/W7bDyEZagLy5a4KQRIsm3drsGdxKwz8Ed2lXPNddUMj7JbF4y8bX5ubnMyV2ZfKcS5F4YhYD/SwGCi8ky/+Szz3pMgJrqkiH3keQk6D8V07ubCPBB+q1/1DPL/sY90yjzlg/TbMmHEZXdSfEi86SKoXpbD02cs45do03HfMdYEpML3yr5aaN8Cp8DfOZV0QpB/IFn9ocXLvoDRx0ewKlU3RXQx8HXxYLaG3Nk+tJxveCa6hQnuCJ9pvfAjM8CTciO4mvrvAzwez8wYh2CBz+b0Hzt7J/YDvVzVZMvHirMu4CyvYUEBPGRNSMnuu55mzwa5FX9BOmnsj/+5S3jB/yRS5+vZLmLHkS9xIK5BYUEw+t3TyE6NTBb7W6VrFs x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_LO2P265MB0573B911DB3DE99895B392FCC24C0LO2P265MB0573GBRP_" MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: d2be5ecc-8291-4d8e-1498-08d76c9be0d3 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 02:55:04.1106 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LwSruNq83Har1isqCOc1h3FHWMANzERa05wgow8obu+82F1XEn44IXyMVVuAIwEPYe9fgIF0fTsgxmVdTGqo7G36pq2Gxxyh39FmaMu9XyM= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0287 Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 02:55:09 -0000 --_000_LO2P265MB0573B911DB3DE99895B392FCC24C0LO2P265MB0573GBRP_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gTW9uLCBOb3YgMTksIDIwMTkgYXQgMjM6MDQgUm9iIFNheXJlIDxzYXlyZXJAZ21haWwuY29t PiB3cm90ZToNCg0KDQo+IEkgZG9uJ3QgdGhpbmsgdGhhdCdzIHRoZSBpbnRlbnQuIEkgYmVsaWV2 ZSB0aGUgYWltIGlzIHRvIHByZXZlbnQgcHJvdG9jb2wgZGlzY3Vzc2lvbnMNCg0KPiBmcm9tIGJl aW5nIGRlcmFpbGVkIGJ5IHBvbGljeSBpbnRlcmplY3Rpb25zLg0KPg0KPiBUaGF0IHdheSwgV0cg cGFydGljaXBhbnRzIHdpbGwgdW5kZXJzdGFuZCB0aGF0IGNvbmNlcm5zIGFyb3VuZCBpdGVtcyBm cm9tIHRoZQ0KPiBzZWNvbmQgbGlzdCBpbiB0aGUgY2hhcnRlciB3aWxsIG5vdCBkZWxheSBwcm9n cmVzcyBvbiBpdGVtcyBmcm9tIHRoZSBmaXJzdCBsaXN0Lg0KDQpJdCB3b3VsZCBxdWl0ZSBhIGxv dCBvZiB3b3JrIHRvIGRldGFpbCBldmVyeXRoaW5nIHRoYXQgYSBnaXZlbiBXRyB3b27igJl0IGNv dmVyISBJIHRoaW5rIGl0IG1vcmUgZWZmaWNpZW50IGZvciB0aGUgY2hhcnRlciB0byBkZXRhaWwg d2hhdCBpcyBpbiBzY29wZSBmb3IgdGhlIFdHIHRvIGF2b2lkIGFueW9uZSB3YXN0aW5nIHRpbWUg YW5kIGVuZXJneSBvbiBvdXQgb2Ygc2NvcGUgbWF0dGVycyDigJMgYWx0aG91Z2ggb2YgY291cnNl IHRoYXQgaXMgYSBjaG9pY2UgYXZhaWxhYmxlIHRvIGFueW9uZSBzaG91bGQgdGhleSB3aXNoIHRv IGRvY3VtZW50IHN1Y2ggaXRlbXMuDQoNCkFuZHJldw0KDQo= --_000_LO2P265MB0573B911DB3DE99895B392FCC24C0LO2P265MB0573GBRP_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2lu ZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJ bWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjI5NzQ5NTk0ODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTgxODQ4MDUyMCA4NDE2NjQ3ODIgMTM0ODA3NTU1IDEzNDgwNzU1NyAx MzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1 Nzt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9u dC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseTpDYWxpYnJpO30NCkBsaXN0 IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJv dHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gTW9uLCBO b3YgMTksIDIwMTkgYXQgMjM6MDQgPHNwYW4gbGFuZz0iRU4tVVMiPlJvYiBTYXlyZSAmbHQ7c2F5 cmVyQGdtYWlsLmNvbSZndDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPg0KPC9zcGFuPndyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBj bSI+Jmd0OyBJIGRvbid0IHRoaW5rIHRoYXQncyB0aGUgaW50ZW50LiBJIGJlbGlldmUgdGhlIGFp bSBpcyB0byBwcmV2ZW50IHByb3RvY29sIGRpc2N1c3Npb25zDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Jmd0Ow0KPC9zcGFuPmZyb20gYmVpbmcgZGVyYWlsZWQg YnkgcG9saWN5IGludGVyamVjdGlvbnMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBUaGF0IHdheSwgV0cgcGFydGljaXBhbnRzIHdpbGwg dW5kZXJzdGFuZCB0aGF0IGNvbmNlcm5zIGFyb3VuZCBpdGVtcyBmcm9tIHRoZQ0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IHNlY29uZCBsaXN0IGluIHRoZSBjaGFy dGVyIHdpbGwgbm90IGRlbGF5IHByb2dyZXNzIG9uIGl0ZW1zIGZyb20gdGhlIGZpcnN0IGxpc3Qu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0Ij5JdCB3b3VsZCBxdWl0ZSBhIGxvdCBvZiB3b3JrIHRvIGRldGFpbCBldmVy eXRoaW5nIHRoYXQgYSBnaXZlbiBXRyB3b27igJl0IGNvdmVyISBJIHRoaW5rIGl0IG1vcmUgZWZm aWNpZW50IGZvciB0aGUgY2hhcnRlciB0byBkZXRhaWwgd2hhdCBpcyBpbiBzY29wZSBmb3IgdGhl IFdHIHRvIGF2b2lkIGFueW9uZSB3YXN0aW5nIHRpbWUgYW5kIGVuZXJneSBvbiBvdXQNCiBvZiBz Y29wZSBtYXR0ZXJzIOKAkyBhbHRob3VnaCBvZiBjb3Vyc2UgdGhhdCBpcyBhIGNob2ljZSBhdmFp bGFibGUgdG8gYW55b25lIHNob3VsZCB0aGV5IHdpc2ggdG8gZG9jdW1lbnQgc3VjaCBpdGVtcy4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QW5kcmV3IDxv OnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_LO2P265MB0573B911DB3DE99895B392FCC24C0LO2P265MB0573GBRP_-- From nobody Mon Nov 18 19:03:19 2019 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 CADF4120255 for ; Mon, 18 Nov 2019 19:03:17 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=nomountain-net.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 hMVr0gH9cY1t for ; Mon, 18 Nov 2019 19:03:13 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 2E0D3120236 for ; Mon, 18 Nov 2019 19:03:13 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id q17so10596425pgt.9 for ; Mon, 18 Nov 2019 19:03:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=cClqziun4SXuWDe3lzviyirqIyHJzLhlbLRLjprNe/A=; b=FyvcJNtE14qCM/2WH1jxismXosZN0WGolJHNCnHy+HBa8iw6Mz6XZ2w0YeIDqqQ4hK xkNW+4LuBPq9O2QUBWXKBXnFjAxyrXjsjQML/nWSQ4xZWbzrr1fNTGIdvbKiUcP5GZ1S nF0gi3mJp/bcHFjsG23vs9rfTR4ts6vnIhB10+x3Gbprx3vcLu7Q3hLpTbiAZ3o5Ztmw +RQA4jx0mRC3NxUelQDftI/o3wK0awy4p1AmFTFzh+kIVyx3V09ois8XF3ZMae1YZUd6 1ZUJy6jTNFWYO9mKXBJ+ObHacBjAeW+NfnOzvq9t3xi7/kSuuCpSxnTIa7OoROGmRQ8/ vNSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=cClqziun4SXuWDe3lzviyirqIyHJzLhlbLRLjprNe/A=; b=KwMhmXVVa7k0G5c9PtAER3Wzw8vf/f6kyQjx4qJWB46fUab1CKR/tqokUA942YjO2o oZHtj9tz7GOUKBeQx87gQGg+ycioA3jLf/WkR2ttNMJK6YNCK14HBVwPDe2ssIhLUxql XffDp80QAQlGdp96yFRvZqGT8+B9lFkV81JBhXof1+xYgZh5YrDNV3KlhMIasR3oMLn0 Q112wsSibYiOiFthZ6xfciSyum6p+BYrPGa5362nKvEGxpuqIz98A9blZWZI9cqRyGv0 kh2FQvwYdcepCfVsE5p72T4ZLSbaTxMDWeMQViVYETt78lusqJdm0QKPD59fbfjv052l +mOA== X-Gm-Message-State: APjAAAXM4mvRfloi+KBnfHR79RlSxmDVVeGgMCF8vzFX9lK+dVPWXWGO s0EB2Y3UO1kfzIKyUGpIWFibefeHZHXL X-Google-Smtp-Source: APXvYqwxJOa3fC1E4a+6vUIVgh6gdLIcyHNzjzeYZloRn9c27bAX6DNE/dYEG70tMTnDtcIhPd2gbw== X-Received: by 2002:a63:684a:: with SMTP id d71mr2837530pgc.27.1574132590937; Mon, 18 Nov 2019 19:03:10 -0800 (PST) Received: from dhcp-934f.meeting.ietf.org (dhcp-934f.meeting.ietf.org. [31.133.147.79]) by smtp.gmail.com with ESMTPSA id w138sm24505626pfc.68.2019.11.18.19.03.08 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 19:03:09 -0800 (PST) To: add@ietf.org References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> From: Melinda Shore Openpgp: preference=signencrypt Autocrypt: addr=melinda.shore@nomountain.net; prefer-encrypt=mutual; keydata= mQINBFppZ0gBEADFwxAi5szDOsM/6+CH4pbYTX7D+2gjLY4xEE7ydQcAF1WVLvcWXrpZM0GO /eA4N1PJ+OT5o8o9zVr7izMJkiLwcnQmxHdlYgZ9E+Cm8hDtMyEPBQwsYTkE5kpbGCmBAZ+W rHNHjvDg366uZQHzJejenB1/V4+rxMZs1Ak34Az2MVOz9Doecaiadpw3NpH3+1VXY/qilqnM lznINSANqD0ktxB/CVKjxl3/K5JnVnLp0h2kiUqt19hQPX2JmLcgaHzu+Ceb34/HZWhs0CiF c4auhQ3A9PcccOprQh6IGW1xo6RP3OEbeRFqeovgBWS+DIWzMIM0a3G2LDid0889QYwEv0zZ RPDCcF3g15mlkeUUmwKQ6eAagPyTqLtTiOKULqy9bQahyX2eqlySrF+HqlwGeNoG+A4l1Z2Y S7NCBLPIzUk2RuSKMBaKw86ORzvg2Advrw4bdv7kbDkArGzywky61SEB/q+GqR466mekXx2F O+m8RuoSnWrBsKvD/bhELHcneorIBleGz+VL7i5adU0rIydG3jPTfUeXoCZIeNx1LannxnAR ihKdh5+FE26WiiK6VmZWkvFjaPFwWGjvAsi82Pd9QgHhnG/XzINpXw/3HF4wtBTU5nIExMzC +FbJxCPq1kXpqSxJqg7hgUFvD5jUD9lpN5Br/S2dUgJj95bbPQARAQABtCxNZWxpbmRhIFNo b3JlIDxtZWxpbmRhLnNob3JlQG5vbW91bnRhaW4ubmV0PokCVAQTAQoAPgIbAwUJCWdTAAUL CQgHAwUVCgkICwUWAgMBAAIeAQIXgBYhBE9oLZMqF5b4IPI0wN+4kXKadtuPBQJaaXRaAAoJ EN+4kXKadtuPVioP/3nVzx33yjiEtqLKTEHwofnLT15CV5wAcGa0DTbqgiomVKzSRkkhbF3Z KIHYrnjVpTcYJuW+PmFSIjNizNVr+vvjNP6ptRqx5orWmK4EBe/B9mrpmIshxUwkYr46uwN4 h06xJS3KCzhfhSsnesH5vlGBkUod0+nQhbSLyLRpxmaKaeAl4dxFSBLU0vUJMLH8PXTZVNof 5Yo+ThqCzu1pwOkBQ8gST2J6zdy4PjU9ENQ9RLAamlAG/6rGHEKLFcnUpEg7Tcu1hSzAsqR8 kjX2Prpu4A9DyLCjTOvfOPQa8WjZy18ZdYOxuPxdrTazeCRVJIvYRflhBCZb744jhMyfAiSW eckwRBVSCnBuvWBJl9Ua1wp8SOUXXhgGI8WGvSkvul6kKSkHQKDggd4cojAhxWLfvmjxn5pz 0BNbvrEBGqgWwO1ZMuJpmv3P8YK5Aytsl85NZoMMUJIDxEQhBUgYz5QTQANBKPi8RsfOntho rhzXLqnPPQcE4Xf9O9XIyy077F0JoyiPx74Zsl1dTxmT73pezpfhKUQR7/QlmJ/FAADpb6SO V0tlgBtR6FAZToBYPDiss57AcKM1zzyJ7sHIZkxQelykYSet6hp2WGcwMXQveWqFMQ4fiGQx XNEPO+KZKNj+0sfINzSLP88O5TniM/l/JrjZZNT/lVAQDTdkCBGyuQINBFppZ0gBEACgZuM1 8ghzSuhuv+n0kWyWCeEWrx9Ey03EgFj5alBt55+OLv3dOsdyBHJxjtd0cZS1XaKZlgr1YZ0O pQNv/Wyy8uSW2BZ6hyG1SKN9/1MmfJLNnjjxaBQP4yaMwDdS3wX7hoWY19IpVPZHYDR35FAg SnG/s6we+IOITM1TJoOJs4+ygeK5dC7LfRoj+lkEHYrTcglYVuwsyK2FNz/sF8kJW1fEZHM6 6phSbhCvwbECWbb4eDGXbKZY92W1RTQ5U5td8DMLXyYipQphrcoeRXpb18DbOnE0WwIQV0yB gc/rTiUt/wVjasd1RrsCPBQC/uJ+ZHknvr2MoxIWBBsRtKYHG66aOL+nDV8X1miuF6j4cztv gmdqrwPHpAKVxhfwd/G4suNBunYw4/kAV9b2+eidX5em3NtPPNl/qNjsmEHQGn/5JKRHRvQs 0yuigXDhN2N0keoHrbGCE8kyA/d83L7E9d95hsf3JxpRzmeaTze+NpcIaX5uXdKOaCBjLtx1 tOrDA4XX7Y3nY+waKZYa3RvC7yulFJiKfYWDSriWeQXcXj06p8H6vF6sy9LeX9xRRjTI7qDH FxwuMQIKGqgufXtxu0pxxcMqXTEUPZnxUWUvuFjjYvEmtO92+Ot/NuotV8JvRPwg2OnYjMJo dU1X7hzEs8djtgZG+t3FEGK3i1EJUQARAQABiQI8BBgBCgAmFiEET2gtkyoXlvgg8jTA37iR cpp2248FAlppZ0gCGwwFCQlnUwAACgkQ37iRcpp2248krg/9H896KtAQCAV0RcV3QqZ75iY5 pCxpRyxAaR0PjE5jiYV5gUHPCKtr9UPZt4Bi+bzNLQ2KJK6Rx4XNf5lQWopEo1IxtOiFPjkr QIpNkYmFWyOGpKpSIDhgsJpswZqxPDLpo+59GNlSUG6v3sMAnx+Gvtvqczkvg6UPDN/JYK75 BIGoCGZMyor1B0EmRYj98LdwjT95dQZXjZvWBDeIx+NxUZKoA7AlR/xgsN3PHGq4SApMLL0R /qbiLIzUPnTPt5sBs0peflVvMrtgIMiZ9FdYPE+VWy5+X2AmeFg6Zl5W76HQUP6eYZQV5abZ +iiW9lY1TmqsqpTIDu/ZMy7pLknxV5E1vQy+wsihluDYydaQ4HWoNaY7QFb+x7TsvjJRi+cH 7By4jxohTWUuaukuMmT0eEaesWJSraAmxsffqJwDpsi0chZskuXjEm9gX6rY7MhzOZl7Vz9F +6MYTtTmT1mpkLAMWf1/JuKUCfnSAHRlDxUOAG6QSJoHWAGqYy3XiF9bN63yQ6xllloSbbMv P9VW0e/iFKMKEIvfIvAg0IrlPcfKAGuuT1axwIU7da/N7LOcXyDDSEUuSzvXL/BkWyjxuLzd LY6eTvC6ZT/fA5iS/PAUj0WbrWNrHQtQ5OY2+al2v6JdLu/w6IZJCBpTosOAOzzmre+31fk1 HKwqd9xRxC8= Message-ID: <64ebf0b1-a26c-d2e2-938c-65a34cf92b4a@nomountain.net> Date: Tue, 19 Nov 2019 11:03:05 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="aPNvu21Wa7ELmqdP4HIXsQHKm3wN5tZGV" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 03:03:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aPNvu21Wa7ELmqdP4HIXsQHKm3wN5tZGV Content-Type: multipart/mixed; boundary="vXLnpZn7geuZiITzKECnRgoEmoiBhuqH2"; protected-headers="v1" From: Melinda Shore To: add@ietf.org Message-ID: <64ebf0b1-a26c-d2e2-938c-65a34cf92b4a@nomountain.net> Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> In-Reply-To: --vXLnpZn7geuZiITzKECnRgoEmoiBhuqH2 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 11/18/19 9:55 PM, Andrew Campling wrote: > It would quite a lot of work to detail everything that a given WG won=E2= =80=99t > cover!=20 It's not uncommon to include charter text describing things that are out-of-scope, when it's ambiguous, unclear, or (as in this case) tempting (see, for example, https://datatracker.ietf.org/wg/ccamp/charter/). I think it's necessary to be clear that, should a working group in this space be chartered, that working group would not work on those policy-related questions. I would go as far as to say that I would oppose chartering a working group if the charter did not clearly identify those things as being out-of-scope. Melinda --=20 Software longa, hardware brevis PGP key fingerprint 4F68 2D93 2A17 96F8 20F2 34C0 DFB8 9172 9A76 DB8F --vXLnpZn7geuZiITzKECnRgoEmoiBhuqH2-- --aPNvu21Wa7ELmqdP4HIXsQHKm3wN5tZGV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEET2gtkyoXlvgg8jTA37iRcpp2248FAl3TW2kACgkQ37iRcpp2 248/6RAAhs2ACxRkIhXFvdG2WVT6jM7hXhzxKPxhtLjazvpikrvrzmkJB9C7kdpH Ju7lsSDbhKFmzfGY5k6yrLaz0k7pywdDgVVysEXQJwrf2ydbq7qdWhRJM2EQKOaV wqXDp88fa6Q+MvvZQMXKv07BWarvloHO8FjONPiZq4evl7nwjov0O8L+SdBpD5yD 6+u5twyFd+0zvw9GO1GJNFZq6dM11SK4ZM3xxjtM9QpzcND/bIUJBla4tBvAFNer qwmqYA4J8jyEJhmD+PA7hOcaxgp38JsemFteRvx6SvV/1PfoX0SMChmP0o8Uv334 lSn3kFtQet3iByQnDHCkC+rObi66hymTKESQcv8LeeSn/n0RKMl2TYupqPKFHElX UAMVgKXs8wfTmQp6YaZhk4lMFXlgB0883+fu34kpo2dSiD6039Oa6PfqiRo/VA31 m7O9W1g812yDqXWjFmm+JThN5H8WCaGsSSQcE50EmYm8FUEEkAqSu9llKYO+JL4L iJbpRDVcB5AzjeoPLEG88u3dDvWrVOmnctgOLBaJI8EJ4H9a65P3A9nezJIbD2vl HGAOC0meJdocMxIGbwRC3h5jj9WYf0NpSrGv2W2gcfS9IPtGgwzby49JVAe23/df 9/VRpPDefdAyFPbq9yJuVGlK0xmkfqkxVsAqYYqxD9RTo/N8qt8= =RFeq -----END PGP SIGNATURE----- --aPNvu21Wa7ELmqdP4HIXsQHKm3wN5tZGV-- From nobody Mon Nov 18 19:04:57 2019 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 EE13B1207FD for ; Mon, 18 Nov 2019 19:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 tu5wGexQjRtl for ; Mon, 18 Nov 2019 19:04:53 -0800 (PST) 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 9A997120255 for ; Mon, 18 Nov 2019 19:04:53 -0800 (PST) Received: from Orochi.local ([196.52.19.216]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id xAJ34mrI017017 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Mon, 18 Nov 2019 21:04:52 -0600 (CST) (envelope-from adam@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1574132693; bh=6kLwXKNfFWIXlvHS0pSBa1nQ4BsLRTR8tPrwtEnRbHg=; h=Subject:To:References:From:Date:In-Reply-To; b=WnuFhM6jkt+6mZcK1+qjjXNqXEOgX5LrAgnFJR0+6GxBf6RHnlPrCKrIbIEGRhyQw BaCl1bfIwAWXmATioCDV7E4L8aYxsRUFCN+Im4uXQRSbOordalFGZ1p5ScqKBcbcDV Yuy/ycKqC/hDj/X/PlyDIUvXmfERVWF+gU3OKb6o= X-Authentication-Warning: raven.nostrum.com: Host [196.52.19.216] claimed to be Orochi.local To: add@ietf.org References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> From: Adam Roach Message-ID: Date: Tue, 19 Nov 2019 11:04:48 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 03:04:55 -0000 [as an individual] On 11/19/19 10:55, Andrew Campling wrote: > > On Mon, Nov 19, 2019 at 23:04 Rob Sayre wrote: > > > I don't think that's the intent. I believe the aim is to prevent > protocol discussions > > > from being derailed by policy interjections. > > > > > > That way, WG participants will understand that concerns around items > from the > > > second list in the charter will not delay progress on items from the > first list. > > It would quite a lot of work to detail everything that a given WG > won’t cover! > I don't read the proposal as suggesting that we list, for exclusion, every topic in the universe save those that are in scope. There is a very small set of topics that have historically been proposed to be covered by DOH/ADD/ABCD conversations, and about which it is increasingly clear consensus is unlikely to emerge from an IETF working group. For avoidance of doubt, charters explicitly rule a small, discrete set items out of scope fairly regularly. This is a reasonable request with good precedent. /a From nobody Mon Nov 18 19:30:30 2019 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 DC8E712084C for ; Mon, 18 Nov 2019 19:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=nIETvL1Y; dkim=pass (2048-bit key) header.d=comcast.com header.b=ehLV+rz0; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=h5rTxSOY 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 aeJaZ9PMPcHf for ; Mon, 18 Nov 2019 19:30:23 -0800 (PST) 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 4191812083A for ; Mon, 18 Nov 2019 19:30:23 -0800 (PST) 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 xAJ3CYP7013736 for ; Mon, 18 Nov 2019 22:30:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=gzD2h+LSsgfcJBP961FNcbmKQYFaihDo0SDBJzyolms=; b=nIETvL1YjKo6WqjQtDFZdDX5yxH5J7n0O+ICFJHoU4cG/39aTu16WSUMS4fDIIG/313D IOsZP4JSzWmlC9MxZiBLPdOcrReuEET3vhtSCmGFY48I6fB7lgjCH9811FLZyglX90oJ u3wuRE/366yNpY+CzL8D7CtoRXfURdDfaQhLXKHa9tNcUIyQKZ4YlmxaNnd6gUrWjoRT WPigvtXgZlG3np88Wpv/N/aVqzLoUrMwWZr9GB+YrPE7srARVSQl31pEt5TdjDcjOFaR D/3Ik4pldJ5N1iQ4Rr6SLfoizTPNsw4IzDXgdlwUwS5BoGVH8LS2mYmZI0jpERRLzcwT Ig== Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) by mx0b-00143702.pphosted.com with ESMTP id 2wc3gp9kjf-24 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 18 Nov 2019 22:30:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1574134195; x=2438047795; 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=gzD2h+LSsgfcJBP961FNcbmKQYFaihDo0SDBJzyolms=; b=ehLV+rz0rCU7k5VGtuzG2Nf4OiDJUwuSKwewKaNPfPeh1znUenRyCyDH0lZZtX2X jts78D0e999AX9yxSWJ4TPxKF7UmzaOBb59MYHXpK/C5lTFd73Sn5dTggcwBcujv bRj4Hqh9cdhu5xVRUFGHAYg2WKJ7iZaBU+rYIjJ+elFPhAHCw/zkFFay8aNx5GS5 RTOW2sRe4lMfC4CPCV9+Yd7mVxDXWJQ23VhE6qxeGuxgfN4hUQzOmEftslUVs+ts /emsLZirkTR4kNa0Bod1ishEB+R1znkb5fR1g+Liw+1t9vRsFvH4XUVtYG2lc5av vH6AGcovUBt8MCJ+Z9Zc7g==; X-AuditID: a2962c47-53bff700000112ce-cf-5dd361b330bd Received: from COPDCEX16.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 5E.01.04814.3B163DD5; Mon, 18 Nov 2019 20:29:55 -0700 (MST) Received: from COPDCEX10.cable.comcast.com (147.191.124.141) by COPDCEX16.cable.comcast.com (147.191.124.147) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 20:30:19 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX10.cable.comcast.com (147.191.124.141) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 18 Nov 2019 20:30:19 -0700 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (104.47.45.54) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 18 Nov 2019 22:30:19 -0500 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB4054.namprd11.prod.outlook.com (10.255.161.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.27; Tue, 19 Nov 2019 03:30:14 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a%7]) with mapi id 15.20.2451.029; Tue, 19 Nov 2019 03:30:15 +0000 From: "Livingood, Jason" To: Dave Lawrence , ADD Mailing list Thread-Topic: [Add] Agenda and Revised Charter for the ABCD BoF Thread-Index: AQHVnTvcw5Xi8KlSJ0qQiU8WuHP22aePdZWAgACgMICAABGBAIAARsEAgAACQoD//88SAIAAvK4AgAAFQACAAAcWgIAAgRoAgAAkTgD//9K6AA== Date: Tue, 19 Nov 2019 03:30:14 +0000 Message-ID: <46410E79-B010-4901-9D86-B024D1DC52ED@cable.comcast.com> References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> <24019.15782.928519.38360@gro.dd.org> In-Reply-To: <24019.15782.928519.38360@gro.dd.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-originating-ip: [31.133.149.55] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 03f951b4-a4f1-445b-8f10-08d76ca0cad9 x-ms-traffictypediagnostic: BY5PR11MB4054: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(1496009)(4636009)(39860400002)(376002)(346002)(396003)(136003)(366004)(51444003)(199004)(189003)(26005)(6306002)(6512007)(76116006)(229853002)(99286004)(6436002)(8936002)(25786009)(81156014)(6246003)(76176011)(81166006)(6486002)(8676002)(86362001)(5660300002)(6116002)(3846002)(476003)(186003)(256004)(14444005)(102836004)(71200400001)(66066001)(71190400001)(91956017)(6506007)(316002)(14454004)(110136005)(11346002)(66476007)(66446008)(64756008)(66556008)(478600001)(66946007)(58126008)(305945005)(2616005)(2906002)(446003)(966005)(33656002)(7736002)(486006)(80792005); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB4054; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BTeohE41CbfPXTpb9hMzByEkEz4S09I4fPIuLp38+oKjAZ09Dzx9CgcZRreTZ0Z2eCupJy3NVooCnrCNwDiOP26eRCQk/v3CNDaf6lXNxIB0j8FLbT7E0shGkTDVNXe83Pu0gBwiq0NM8uxwSLCJo9uAiCVJJsSQ481fvz0JMAsvVaXFX4Z0IBy9FO5ihE0kkL6vg/nxaeRFgvMkxPFdDrCkWNWsrFz8KSLU2yUmZbl9pS6+lHU9EBEYZVKSyhRVigoj2vFbmITwRMVxNHqWY2qrQtOkqhk6YiG7ffUAXCFmFHuUzsP7VRdnk3SLLf3b8T/VvxlKhh7saymHQDJI1ww3L0sTCPqDdRvITvZlKPrGBV8XbqMG/KcncznKCF481jY2fFHdkwVhMZ3Nbyc4xf/UhH3jomP2K3wuPxqykaTZ1UHerFwvQ2c9FhdWhKy7 x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UUAy+F4NgyI8htG5pQloJFIwPQmwbE+r22w/04VMmoYLjx6z8U2/R27qes3d7drHsM3qGHz4MzezpeTA8jxuoJPAGebye1E/S/F0MWhU3hKR5rdJPU89/5HVdaMg7sXgd+lisqHRxsL2nm3P9fQud/L5uuRUZx/p4VKG/Dl+l9J0d78uOmQaV3DQKiwvnoatPjkl47HYqjyIvFQR7JtSsXbEGXY9dNCiHwHG0RoEOn6vMpKVhKJ1B+kjpki4pKpZe7Ae67tvVtUbDOqtx1bZ0Mfx+x8DIavHISSQfP3iqkY0otS5m3ljf/Yd1qm5jFUKua3k5vd30N2ExbA33MlEMw== 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=f+bcRVebu5xp489Z4+Evbk1/qyqGfMCh6ITkLYFMlZc=; b=YPg0N/+cab9veOJyjBSuEM1J7GSqE8676RhXfrEzgOEGUwsqiXfAR0LcnUDpJvsRZyK/3bE0ht5rw7BX9H6RDGpiTtQUOfQSxxqPhH4WwLyweXRqbuqrDuM6WDAiInRTE6zpenSXqAV4iciO5sBRIlaYtGftbneNa0gnOd3qkA78Vzi6SBzAcaDvGBALJt9+NeNmROMkCc/ZHzzpJO5Fhy0B5tY408pgsH+oVa3WI/bAgG3rba1OU2IqMUqhNyVM2EfpkuWuLM73qa/JW/3YNTyQG62kbmoIEwKMP1+zTp7rZj4x/qBdKIqmAELOJlzOsJGaKGDjORmAziXuHmpe0w== 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=f+bcRVebu5xp489Z4+Evbk1/qyqGfMCh6ITkLYFMlZc=; b=h5rTxSOYmsw9YEFbfTlqefl1zBIutTv3iwWVAIikntRwbsJbZTZoWr/Xs2gi+yFuapzfRzBMIjm5QO9SivKazsojQVAgmfAoJFetVT6eT8s7nW8W/HSfJ59Xpv3Q5QczFXlJQ3YMAWNsUKMh8NuPIypKxBKKHXGLLWvFoye1vIo= x-ms-exchange-crosstenant-network-message-id: 03f951b4-a4f1-445b-8f10-08d76ca0cad9 x-ms-exchange-crosstenant-originalarrivaltime: 19 Nov 2019 03:30:14.8618 (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: kmp2uZmWKpT46u2F0FudrpkRj7nB8Ujl0oHSAtKB+e/Ty3BxtqeLb2iaL6GDVkQziVxZFGHk76MuXKfmgei2tr/1Iyk10Se08AlU4ptfuSk= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4054 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <9E0CEA22EB47B2468318F1C05CDE548E@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLKsWRmVeSWpSXmKPExsWSUDRnsu7mxMuxBlevKVj8P72OzWL1o+ss DkweHz9FeSxZ8pMpgCmqgdGmJKMoNbHEJTUtNa841Y5LAQPYJKWm5ReluiYW5VQGpeakJmJX BlKZkpqTWZZapI/VGH2s5iR0MWV0n+lgLVijUPH63E6WBsYD8l2MHBwSAiYSN9uluxi5OIQE DjNJ3L+2gRnCOcQo0bHuPiOEc4dR4nPvfDYI5wSjxJY3m6GcyUwS3d9PsUA4jxgl3p+dzdTF yMnBJmAmcXfhFWYQW0TAQWLz0V9gtrCAncT7Gc/ZIOL2Eo9fr2WCsOskms88YASxWQRUJXbM b2MBsXkFXCR2n+yGOuoFo8TMl7/BijgFjCQ2vT/NCmIzCohJfD+1BmwQs4C4xK0n88FsCQEB iSV7zjND2KISLx//YwX5WlRAX+LgX1+I1hSJxV2LoMoVJS53HWWBsGUlLs3vZoSwfSU2zv8I NUZLYvHvT6wQdrbEzVOboOJqElc/wfTKSLTvmwUOIQmBL6wSrdu2sIHsFRLIknh71Q6iRk5i Ve9DlgmMJrOQXD0LqIpZQFNi/S59CNNDYuuvYIgKRYkp3Q/ZZ4EDRVDi5MwnLAsYWVcx8hqa GekZmhromZjomRtuYgQmykXTdNx3MH44H3uIUYCDUYmHd5fP5Vgh1sSy4spcYLxyMCuJ8Po9 uhArxJuSWFmVWpQfX1Sak1p8iFGag0VJnLf+/vxYIYH0xJLU7NTUgtQimCwTB6dUA+P8d882 n5Jk3pfVtCjMwd1GO8Hw8MzcIrW9rg8mixT+Vd+fVOnBMvVAwfYPfozW2fUfYnunh17cdX2J ypV1i0QbM1JTWgKeSK00vFr2PKNhF+t/qw3p+mkh/7Km8P3aspqDfa2jgfQSTu/dFx5z3w+P 0qrgYHoVfG1rwSmPZE6ZNXPU1ucemajEUpyRaKjFXFScCABPa8lRkAMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-18_08:2019-11-15,2019-11-18 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 03:30:29 -0000 SSBjb3VsZCBzZWUgc29tZSBsb2dpYyBpbiB0aGF0LCBpbiBkb2N1bWVudGluZyB3aGF0IHZhcmlv dXMgaXNzdWVzICYgcG9pbnRzIG9mIHZpZXcgb24gYW4gaXNzdWUgbWF5IGJlLg0KDQrvu79PbiAx MS8xOS8xOSwgODo1NiBBTSwgIkFkZCBvbiBiZWhhbGYgb2YgRGF2ZSBMYXdyZW5jZSIgPGFkZC1i b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiB0YWxlQGRkLm9yZz4gd3JvdGU6DQoNCiAgICBH bGVubiBEZWVuIHdyaXRlczoNCiAgICA+IElmIEnigJltIHVuZGVyc3RhbmRpbmcgdGhhdCB0aGUg c3VnZ2VzdGlvbiBpcyB0byBoYXZlIHBlb3BsZSB3cml0ZQ0KICAgID4gZHJhZnRzIG9uIHdoaWNo IGNvbnNlbnN1cyB3b27igJl0IGV2ZXIgYmUgcmVhY2hlZD8gIFsuLi5dIFRoaXMgd291bGQNCiAg ICA+IGJlIGEgbG90IG9mIHdvcmsgYnkgdGhlIFdHIHdpdGggbm8gd29yayBwcm9kdWN0ICB0byBz aG93IGZvciBpdC4NCg0KICAgICAgICJJZiB5b3UgY2hvb3NlIG5vdCB0byBkZWNpZGUgLyBZb3Ug c3RpbGwgaGF2ZSBtYWRlIGEgY2hvaWNlIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAtLSBOZWlsIFBlYXJ0DQoNCiAgICBUaGVyZSB3b3VsZCBiZSB3b3JrIHByb2R1Y3Qu ICBQdWJsaXNoZWQgZG9jdW1lbnRzIHRoYXQgZXhwbGFpbiB3aHkNCiAgICB0aGUgaXNzdWVzIGFy ZSBzdWZmaWNpZW50bHkgZGlmZmljdWx0IHRoYXQgdGhlIElFVEYgaXMgdGFraW5nIGEgcGFzcy4N Cg0KICAgIE1heWJlIGl0J3MgYmVjYXVzZSB3aGF0IEkgYW0gc2F5aW5nIGlzIGFkbWl0dGVkbHkg dW5jb21tb24gaW4gdGhlIElFVEYNCiAgICB0aGF0IEkndmUgbm90IGJlZW4gc3VjY2Vzc2Z1bCBp biBnZXR0aW5nIHRoZSBpZGVhIGFjcm9zcy4gIEl0J3MNCiAgICBzb21ldGhpbmcgdGhhdCBJJ3Zl IGJlZW4gYWR2b2NhdGluZyBmb3IgYSB3aGlsZSB0aG91Z2gsIHRoYXQgd2UNCiAgICBzaG91bGQg aGF2ZSBhIG1vcmUgZWZmZWN0aXZlIGhpc3Rvcnkgb2Ygbm90IG9ubHkgcHJvcG9zYWxzIHRoYXQN CiAgICBzdWNjZWVkIGJ1dCBhbHNvIHRob3NlIHRoYXQsIGZvciB3aGF0ZXZlciByZWFzb24sIGRp ZCBub3QuDQoNCiAgICBXZSBwdWJsaXNoIHRoZSBSZXF1ZXN0IGZvciBDb21tZW50cyBzZXJpZXMs IHdoaWNoIGlzIHdoYXQgbWFkZSBpdA0KICAgIHRocm91Z2ggdGhlIGdhdW50bGV0IGFscmVhZHks IHdpdGggZGlzY3Vzc2lvbiBsYXJnZWx5IGRvbmUgcmF0aGVyIHRoYW4NCiAgICBiZWdpbm5pbmcu ICBJJ20gbm90IHN1Z2dlc3RpbmcgdGhhdCBiZSBjaGFuZ2VkLCBqdXN0IHRoYXQgd2UgZG8gYmV0 dGVyDQogICAgYWJvdXQgZGVicmllZmluZyB3aHkgZHJhZnRzIGZhaWxlZC4gIFNvbWV0aW1lcyBp dCdzIGZhaXJseSBpbm5vY3VvdXMsDQogICAgc29tZXRpbWVzIGl0IGlzIHZvbGF0aWxlLCBidXQg ZWl0aGVyIHdheSBpdCBpcyBkaWZmaWN1bHQgZm9yIHNvbWVvbmUNCiAgICB3aG8gd2Fzbid0IHBh cnQgb2YgaXQgdG8ga25vdy4NCg0KICAgIFRoZXNlIG5lZWRuJ3QgYmUgbG9uZywgaGVhdnkgZG9j dW1lbnRzIHRoZSByZWxpdGlnYXRlIGV2ZXJ5IGFzcGVjdA0KICAgIHRoYXQgYnJvdWdodCB1cyB0 byB0aGUganVkZ21lbnQgdGhhdCB3ZSBqdXN0IHdvbid0IGJlIGFibGUgdG8gcmVhY2gNCiAgICBj b25zZW5zdXMuICBTb21ldGltZXMgdGhlIGV4cGxhbmF0aW9ucyBhcmUgZmFpcmx5IHNpbXBsZSwg dGhhdA0KICAgIHRhdXRvbG9naWNhbGx5IHRoZSBpbW1vdmFibGUgb2JqZWN0IGlzIGluIGlycmVj b25jaWxhYmxlIGNvbmZsaWN0IHdpdGgNCiAgICB0aGUgdW5zdG9wcGFibGUgZm9yY2UgLS0gb3Ig bW9yZSBhcHRseSwgdGhhdCB0d28gaW1tb3ZhYmxlIG9iamVjdHMgc2l0DQogICAgc2VwYXJhdGVk IGJ5IGFuIGluc3VybW91bnRhYmxlIG1vdW50LiAgU29tZXRpbWVzIHRoZSBleHBsYW5hdGlvbiBp cw0KICAgIGVzc2VudGlhbGx5IGEgcmVmZXJlbmNlIHRvIFJGQyAzOTM1IChBIE1pc3Npb24gU3Rh dGVtZW50IGZvciB0aGUNCiAgICBJRVRGKS4gUkZDIDcyNTggKFBlcnZhc2l2ZSBNb25pdG9yaW5n IElzIEFuIEF0dGFjayksIG9yIHRoZSBsaWtlLiAgSW4NCiAgICBhbnkgZXZlbnQgaXQgc2hvdWxk IGJlIGVhc2llciB0byBhY2hpZXZlIGNvbnNlbnN1cyBvbiB3aHkgY29uc2Vuc3VzDQogICAgaXNu J3QgcG9zc2libGUsIGFuZCBkb2N1bWVudCBpdCBmb3IgZXZlcnlvbmUuDQoNCiAgICBBbmQgYWdh aW4sIG15IHRob3VnaHRzIGhlcmUgYXJlIHByZWRpY2F0ZWQgb24gbXkgYmVsaWVmIHRoYXQgdGhl IElFVEYNCiAgICBub3Qgd29ya2luZyBvbiBzb21ldGhpbmcgZG9lc24ndCBtZWFuIGl0IGlzbid0 IHdvcmtlZCBvbiwgaXQncyBqdXN0DQogICAgd29ya2VkIG9uIGVsc2V3aGVyZSB0byB2YXJpb3Vz IGVmZmVjdHMsIG9uZSBvZiB3aGljaCBpcyBzb21ldGltZXMgdGhhdA0KICAgIGl0J3Mgc3RpbGwg YSByZWxlbnRsZXNzIGlzc3VlIHdpdGhpbiB0aGUgSUVURiBhbnl3YXkuICAoTkFULCBhbnlvbmU/ KQ0KICAgIFRoZSBJRVRGIGhhcyBhbiBvbmdvaW5nIGNoYWxsZW5nZSBpbiBtYWludGFpbmluZyBp dHMgcmVsZXZhbmNlLCBhbmQgSQ0KICAgIHRoaW5rIHRoYXQgcHJvdmlkaW5nIG1vcmUgdHJhbnNw YXJlbmN5IG5vdCBvbmx5IHRocm91Z2ggZGlzY3Vzc2lvbiBidXQNCiAgICBhbHNvIHZpYSBjbGVh ciBzdW1tYXJpZXMgb2YgdG91Z2ggaXNzdWVzIGlzIG9uZSBpbXBvcnRhbnQgYXNwZWN0IG9mDQog ICAgZG9pbmcgdGhhdC4NCg0KICAgIEkgaG9wZSB0aGlzIG1ha2VzIG15IHZpZXcgY2xlYXJlci4N Cg0KICAgIC0tdGFsZQ0KDQogICAgLS0NCiAgICBBZGQgbWFpbGluZyBsaXN0DQogICAgQWRkQGll dGYub3JnDQogICAgaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vYWRkX187IXJ4X0w3NUlUZ09RIVRIckN4MGFrZ2Y0em5uMzRD MTVzM0JYbmY0VXlsMkFxLTR4YkxGNzZsZzRtTGRSRW01LWJfY01qWXNfd3dXSDRfZUkzdGckDQoN Cg0K From nobody Mon Nov 18 20:20:25 2019 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 9F1221200FB for ; Mon, 18 Nov 2019 20:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNy6VUyUvaiw for ; Mon, 18 Nov 2019 20:20:20 -0800 (PST) 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 22AE0120827 for ; Mon, 18 Nov 2019 20:20:20 -0800 (PST) Received: by mail-ua1-x92f.google.com with SMTP id u99so6086284uau.5 for ; Mon, 18 Nov 2019 20:20:20 -0800 (PST) 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=k1ZotGn/vk7azYIFyKxEP0P8OSy2qeaXBd5hG6ACXaM=; b=RJgaWiftfqmQMStJFzVx3GdZucRiQYmvNt+u7Yg8M82eMBkyKOqZ0v2lsKN5ECXUnD ZSm0VShHkdYSWDn4rbfsWYE83I31jicSABJ+oo9hjE1KfpL6jcntptmEDaMJncJj/ogp 8Ccgg0WS+ll18zfeytOReCTTWtjmOiBHjsdKBZnqLDhTlTow8kD5iJDLDPY7ozdq9C/t IH9YdOuVM+D+l2+znUSPvkvsXYipC3uFG54iDQHjI18Cr1h6fnbqNNgYMuzQb8Vx2v1z vP7JOh65dIuAPool4DWf4psERxqwBLVbSXtVaaR3zabxjf8vMSROsxOyem+WiXHYWgup PV0w== 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=k1ZotGn/vk7azYIFyKxEP0P8OSy2qeaXBd5hG6ACXaM=; b=dDMB/3sLU7ZHmtAGh/orzcPJIw6aS8e8QejmcQXESivaUdNZb+2UW4VpiAowOrieb8 rZlgl+N16/694o/IjmElfZrkOa89auwexWMW9oHk4TCFNm0gs4u2DwtpCLL4TzqSPFX/ n7DHRrckjfVWqd9Cbvv5iAkkV4e6Fkbb0iN57igpxgALOZaYrxsdSFmKvNfFxtiN21ti 5aFlD1xr232YbxQFqoraR8DxrMh5O2OYCjiOh/LqY/7wf7C2uoegIeYXIeM2p5jWmg7e MHXx2cyBpmCgcraSj83cP5qi95jtWuGdTvXIa3QJEXfEsTwuNUOhcc5Izcwi5e/7Kfuh u4rw== X-Gm-Message-State: APjAAAXNoI/FkWjfk5QD29+YqhZ4UWAWsu20Db4gC9/4jQNX6tt2igqR MXAUFsNr98P8oeMZCFhyUCCjDlP6uR5FGMszTdl3HE/z X-Google-Smtp-Source: APXvYqyQjUoHuv3iyEMSulBViT2Gvlbq73+NglMLouE/Dh2bZ4mHX0Pv8ktU0+d+fclHwd2g2kkl97ml2NWyixnmxhU= X-Received: by 2002:a9f:376b:: with SMTP id a40mr20090110uae.48.1574137218788; Mon, 18 Nov 2019 20:20:18 -0800 (PST) MIME-Version: 1.0 References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> <24019.15782.928519.38360@gro.dd.org> <46410E79-B010-4901-9D86-B024D1DC52ED@cable.comcast.com> In-Reply-To: <46410E79-B010-4901-9D86-B024D1DC52ED@cable.comcast.com> From: Brian Dickson Date: Tue, 19 Nov 2019 12:20:01 +0800 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000c0f18d0597ab61b2" Archived-At: Subject: [Add] DNS service at scale vs IP addresses and port(s) 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, 19 Nov 2019 04:20:23 -0000 --000000000000c0f18d0597ab61b2 Content-Type: text/plain; charset="UTF-8" This is intended as a background article to provide information for participants who may not have first-hand experience operating DNS services at scale, Apologies to anyone who already knows this stuff; the target audience is everyone else. TL;DR: It is probably not reasonable to expect any operators of DNS services-at-scale to offer other (non-DNS) services on the exact same IP address and port number, ever. Caveats and personal background: I've worked at a number of companies whose product offerings include some flavor of at-scale DNS services, and have participated in industry organizations and become familiar with a number of other operators' offerings. There is generally no "secret sauce" involved; everyone doing this generally relies on some combinations of COTS hardware, open source or home grown software, and substantial integration with networking infrastructure. These observations and analyses are pretty uniform, regardless of whether the "service" being offered is recursive DNS (public or otherwise), delegation-only (root or TLD), or authoritative (generically "second level domain" aka SLD). In order to provide high availability and performance, doing DNS at scale generally involves the use of "anycast". This means announcing the same IP prefix(es) in multiple locations, typically with BGP towards transit providers and peer ISPs and enterprise networks. The first rule of anycast is, only announce externally that which is responding to queries internally. If the server(s) providing the service fail, continuing to announce the prefix will result in service degradation or failure, to at least the relevant "watershed" of clients that prefer that specific anycast instance. This first rule has a number of corollaries, which may or may not apply for a given type of service or particular architecture. Generally, the preference is to minimize the number of services running within any given prefix, even going so far as to minimize the number of host addresses used on the prefix. Many operators do this by limiting each prefix to having only a single address in use. The reason for minimizing addresses and services is that the total failure of a single service on a single address may be sufficiently problematic as to require the prefix to be withdrawn from that location. This can impact global performance and availability statistics, which in some operators' cases, is a big deal. The primary ingress path for a BGP anycast node is generally a router, although this may either a hardware device or sorftware-based router. Routers do their work strictly using the destination IP address, and nothing else, when forwarding packets. This rules out any kind of port-based or source-address based routing. Routers may do stateless ACLs (access control lists) to white-list or black-list ports, protocols, and addresses, on source and/or destination basis. The next element in a BGP anycast node may optionally be some kind of hardware load balancer. Alternatively, the router at the previous step may perform a load-balancing style hashing function. Either way, that function is generally going to be based on a hash of the 5-tuple (source IP, destination IP, source port, destination port, protocol). The intent is to ensure "sticky" connections, which is particularly important for TCP-based transport flows, including TLS. In the case of TLS, there may be a TLS termination point above the actual servers, typically for hardware acceleration. For the most part, this can be ignored for purposes of the address/port issue, as the termination point will typically need to be configured for a specific service exclusively for a given IP address and port combination. Finally, at the host level, there will typically be a horizontally scaled set of servers, all serving identical content for any given IP and port combination, including what service is handled on which port. Multiplexing services is only feasible if those services have some additional differentiator, such as host name as signaled by SNI for TLS, and then only if the performance characteristics and requirements of those differentiated services are roughly equivalent. Web pages and DNS service generally do not share delay tolerance and performance requirement characteristics. DNS volumes are typically high transaction rates with high throughput, and require not just low latency, but low upper bounds on latency. Web servers may be designed towards lowish latency towards individual pages or components, but do not generally have the ability to place upper bounds on transmitted data or outbound queueing. In short, there is no place in the BGP anycast architecture above the server itself where it is even possible to demux DoH and regular HTTPS traffic, and the server itself is extremely unlikely to meet performance requirements for both kinds of traffic simultaneously. The general practice for web hosting is to have individual servers internally anycast for availability and with a 1:1 mapping between a set of domains and a single IP address, scaled as necessary. And very similarly, DNS services will also be anycast on their own dedicated IP addresses (and generally speaking entire prefixes), serving only DNS traffic. The infrastructure above them may be identical, but the IP addresses of web services and DNS services do not overlap (if both kinds of service are present). This is driven by performance, scalability, the foundational technologies (BGP, IP address aggregation, routing/switching, hashing 5-tuples), and applies to at-scale DNS services across the board. The gist of this is: even if infrastructure operated by a given entity provides a common front-end to both DNS and web services, the IP addresses used for those services should always be expected to be totally distinct, and is not anticipated to change in the foreseeable future. Brian --000000000000c0f18d0597ab61b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is intended as a background article to provide inform= ation for participants who may not have first-hand experience operating DNS= services at scale,

Apologies to anyone who already know= s this stuff; the target audience is everyone else.

= TL;DR: It is probably not reasonable to expect any operators of DNS service= s-at-scale to offer other (non-DNS) services on the exact same IP address a= nd port number, ever.

Caveats and personal backgro= und:
I've worked at a number of companies whose product offer= ings include some flavor of at-scale DNS services, and have participated in= industry organizations and become familiar with a number of other operator= s' offerings.
There is generally no "secret sauce" = involved; everyone doing this generally relies on some combinations of COTS= hardware, open source or home grown software, and substantial integration = with networking infrastructure.

These observations= =C2=A0and analyses are pretty uniform, regardless of whether the "serv= ice" being offered is recursive DNS (public or otherwise), delegation-= only (root or TLD), or authoritative (generically "second level domain= " aka SLD).

In order to provide high availabi= lity and performance, doing DNS at scale generally involves the use of &quo= t;anycast". This means announcing the same IP prefix(es) in multiple l= ocations, typically with BGP towards transit providers and peer ISPs and en= terprise networks.

The first rule of anycast is, o= nly announce externally that which is responding to queries internally. If = the server(s) providing the service fail, continuing to announce the prefix= will result in service degradation or failure, to at least the relevant &q= uot;watershed" of clients that prefer that specific anycast instance.<= /div>

This first rule has a number of corollaries, which= may or may not apply for a given type of service or particular architectur= e. Generally,=C2=A0 the preference is to minimize the number of services ru= nning within any given prefix, even going so far as to minimize the number = of host addresses used on the prefix. Many operators do this by limiting ea= ch prefix to having only a single address in use. The reason for minimizing= addresses and services is that the total failure of a single service on a = single address may be sufficiently problematic as to require the prefix to = be withdrawn from that location. This can impact global performance and ava= ilability statistics, which in some operators' cases, is a big deal.

The primary ingress path for a BGP anycast node is g= enerally a router, although this may either a hardware device or sorftware-= based router. Routers do their work strictly using the destination IP addre= ss, and nothing else, when forwarding packets. This rules out any kind of p= ort-based or source-address based routing. Routers may do stateless ACLs (a= ccess control lists) to white-list or black-list ports, protocols, and addr= esses, on source and/or destination basis.

The nex= t element in a BGP anycast node may optionally be some kind of hardware loa= d balancer. Alternatively, the router at the previous step may perform a lo= ad-balancing style hashing function. Either way, that function is generally= going to be based on a hash of the 5-tuple (source IP, destination IP, sou= rce port, destination port, protocol). The intent is to ensure "sticky= " connections, which is particularly important for TCP-based transport= flows, including TLS.

In the case of TLS, the= re may be a TLS termination point above the actual servers, typically for h= ardware acceleration. For the most part, this can be ignored for purposes o= f the address/port issue, as the termination point will typically need to b= e configured for a specific service exclusively for a given IP address and = port combination.

Finally, at the host level, ther= e will typically be a horizontally scaled set of servers, all serving ident= ical content for any given IP and port combination, including what service = is handled on which port.

Multiplexing services is= only feasible if those services have some additional differentiator, such = as host name as signaled by SNI for TLS, and then only if the performance c= haracteristics and requirements of those differentiated services are roughl= y equivalent.

Web pages and DNS service generally = do not share delay tolerance and performance requirement characteristics. D= NS volumes are typically high transaction rates with high throughput, and r= equire not just low latency, but low upper bounds on latency. Web servers m= ay be designed towards lowish latency towards individual pages or component= s, but do not generally have the ability to place upper bounds on transmitt= ed data or outbound queueing.

In short, there is n= o place in the BGP anycast architecture above the server itself where it is= even possible to demux DoH and regular HTTPS traffic, and the server itsel= f is extremely unlikely to meet performance requirements for both kinds of = traffic simultaneously.

The general practice for w= eb hosting is to have individual servers internally anycast for availabilit= y and with a 1:1 mapping between a set of domains and a single IP address, = scaled as necessary. And very similarly, DNS services will also be anycast = on their own dedicated IP addresses (and generally speaking entire prefixes= ), serving only DNS traffic. The infrastructure above them may be identical= ,=C2=A0 but the IP addresses of web services and DNS services do not overla= p (if both kinds of service are present).=C2=A0

Th= is is driven by performance, scalability, the foundational technologies (BG= P, IP address aggregation, routing/switching, hashing 5-tuples), and applie= s to at-scale DNS services across the board.

The g= ist of this is: even if infrastructure operated by a given entity provides = a common front-end to both DNS and web services, the IP addresses used for = those services should always be expected to be totally distinct, and is not= anticipated to change in the foreseeable future.

= Brian=C2=A0
--000000000000c0f18d0597ab61b2-- From nobody Mon Nov 18 21:23:27 2019 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 547E2120804 for ; Mon, 18 Nov 2019 21:23:26 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 zD3zXpeeSR-y for ; Mon, 18 Nov 2019 21:23:23 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [193.234.218.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1471207FB for ; Mon, 18 Nov 2019 21:23:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id D932E660144 for ; Tue, 19 Nov 2019 07:23:21 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6UHinnUVbzGH for ; Tue, 19 Nov 2019 07:23:20 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id 4997B660135 for ; Tue, 19 Nov 2019 07:23:20 +0200 (EET) From: Jari Arkko Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 19 Nov 2019 13:23:16 +0800 References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> <24019.15782.928519.38360@gro.dd.org> <46410E79-B010-4901-9D86-B024D1DC52ED@cable.comcast.com> To: ADD Mailing list In-Reply-To: <46410E79-B010-4901-9D86-B024D1DC52ED@cable.comcast.com> Message-Id: <999534B6-41F6-49E8-8988-D5C6AF05013A@piuha.net> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 05:23:26 -0000 As I said earlier on another thread, my crystal ball sees two areas of = development: 1. Rapid and widespread deployment of DNS encryption via DOH. This is a = good thing. 2. Changes in deployment models for DNS. But the crystal ball is cloudy, = we could either end up with a different distributed model than we have = today (e.g., along the lines of Adaptive DNS) or with a centralised = deployment model where large parts of Internet DNS queries go to few = places. The latter outcome would be very unfortunate, in my opinion it = is one of the biggest privacy dangers for the current Internet. I believe anything we can do to affect the direction of #2 for the less = centralised way is essential work for the IETF, and should be taken up = by the proposed working group. This needs to include both technical work = (e.g., discovery, use of multiple resolvers, distributed architectures a = la Oblivious or Adaptive DNS) as well as discussion and analysis of = deployment models and their implications. I don=E2=80=99t believe this = is work that should be feared by people who want to improve the privacy = of the DNS system. In fact, it seems essential for our understanding of = the issues, and in my view also in line with the requirement that we = understand pervasive surveillance implications of our work. Jari From nobody Mon Nov 18 21:30:30 2019 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 A5A75120013 for ; Mon, 18 Nov 2019 21:30:28 -0800 (PST) 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_DNSWL_NONE=-0.0001, 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 2Of4gdo_xIeW for ; Mon, 18 Nov 2019 21:30:23 -0800 (PST) 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 2CBAD12020A for ; Mon, 18 Nov 2019 21:30:23 -0800 (PST) Received: by mail-lf1-x133.google.com with SMTP id v8so15864948lfa.12 for ; Mon, 18 Nov 2019 21:30:23 -0800 (PST) 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=ZhvihLqbp8m+stx1+9j0YpqH6/s0ZdA5omMmjyUIwCU=; b=SxlysV9koGvO3N9RQAFw2XyyIKyu7YjfbYPZ7Zr6ruw5V/hQqPsi2Gzb98cPTqCk2z Zbdg6w8VDoGPqpxGmVoptj4ZWHOPeLNjpsm/To6y1IalmZd+Jfm7METZ+5xX3HiTB/5E kE7sxWGQ+8maHhISd9oSq4Jma1bvcvkIpKd0asOpdOSr7ct+spuIVsdL1ixp0dhRGbsW akwRA6n2LvmHEUEdOnw+/nYbBs4kkKU9alxkia6DJ5AxTXArF0eV6Cxud9cE7IPGNx/N 9OWHjtFwMg8+rrVw+INyhSyDf1bn20YgoyYC1JoDRqRg834PraFrw7dKAMTyXfPlf5fk 7qDQ== 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=ZhvihLqbp8m+stx1+9j0YpqH6/s0ZdA5omMmjyUIwCU=; b=WBAkGv3nIgeGivdgRgBPXo3+qgkca3QYoxTX1gaNNO+DRV1gIPmhv/wCQ+HVNY8O4h mA8vQVqmxdRgppp1aatkIl/YHQAQ9RwC31jYd6AL5wOpkcPYmsPL67Ail2uOqptSJZOg cdXsxJZKPI9d3LqAd3l7gJsKFUtK5c6WtPlndy/po86+QsywTG0a4SfuGUT7weQ3gBLG LFQzLTyEHslIaFGMhp4jG0XECf2eO6Q6/dzL6qqHbheCAzubfD0/iFw5g1FQ8Hylba5w uxPnbGg8XgCBHvKjb+j7wGYf045bOSIxLqu9bWyWqAFFhuFmo+HlrEUaXTc+pdpvJJyZ SR4A== X-Gm-Message-State: APjAAAVwyVfdvR2FNDS3xKhA3z2j2wz/BzsB2fB8+UgfOeY0IimlFT8T uYvqYV7iheLLuvTl7yAUDMKyUN479FjTnYD3mZbPLw== X-Google-Smtp-Source: APXvYqxx5YXO+79IU4kWbo9PolLA3dOgbx4+AWS5HthtwxVN+4Zuv6MvTFZHuF6ypkDCBdIKzvdJuqbmg11o06dade4= X-Received: by 2002:a19:6a16:: with SMTP id u22mr2148163lfu.94.1574141421176; Mon, 18 Nov 2019 21:30:21 -0800 (PST) MIME-Version: 1.0 References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> <24019.15782.928519.38360@gro.dd.org> <46410E79-B010-4901-9D86-B024D1DC52ED@cable.comcast.com> <999534B6-41F6-49E8-8988-D5C6AF05013A@piuha.net> In-Reply-To: <999534B6-41F6-49E8-8988-D5C6AF05013A@piuha.net> From: Eric Rescorla Date: Mon, 18 Nov 2019 21:29:44 -0800 Message-ID: To: Jari Arkko Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000003c5f8b0597ac5c23" Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 05:30:29 -0000 --0000000000003c5f8b0597ac5c23 Content-Type: text/plain; charset="UTF-8" On Mon, Nov 18, 2019 at 9:23 PM Jari Arkko wrote: > As I said earlier on another thread, my crystal ball sees two areas of > development: > > 1. Rapid and widespread deployment of DNS encryption via DOH. This is a > good thing. > > 2. Changes in deployment models for DNS. But the crystal ball is cloudy, > we could either end up with a different distributed model than we have > today (e.g., along the lines of Adaptive DNS) or with a centralised > deployment model where large parts of Internet DNS queries go to few > places. The latter outcome would be very unfortunate, in my opinion it is > one of the biggest privacy dangers for the current Internet. > I feel like I'm repeating myself, but we are already in that world to a great extent. Roughly 10% of DNS queries go to 8,8.8.8 right now and in many markets (e.g., the US, but not just in the US) Internet service provision is dominated by a few large providers. -Ekr --0000000000003c5f8b0597ac5c23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Mon, Nov 18, 2019 at 9:23 PM Jari = Arkko <jari.arkko@piuha.net&= gt; wrote:
As I = said earlier on another thread, my crystal ball sees two areas of developme= nt:

1. Rapid and widespread deployment of DNS encryption via DOH. This is a goo= d thing.

2. Changes in deployment models for DNS. But the crystal ball is cloudy, we= could either end up with a different distributed model than we have today = (e.g., along the lines of Adaptive DNS) or with a centralised deployment mo= del where large parts of Internet DNS queries go to few places. The latter = outcome would be very unfortunate, in my opinion it is one of the biggest p= rivacy dangers for the current Internet.

I feel like I'm repeating myself, but we are already in that world to= a great extent. Roughly 10% of DNS queries go to 8,8.8.8 right now and in = many markets (e.g., the US, but not just in the US) Internet service provis= ion is dominated by a few large providers.

-E= kr
--0000000000003c5f8b0597ac5c23-- From nobody Mon Nov 18 22:09:18 2019 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 87F11120829 for ; Mon, 18 Nov 2019 22:09:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PHi-DMuIuEEe for ; Mon, 18 Nov 2019 22:09:16 -0800 (PST) Received: from mail.dragon.net (mail.dragon.net [IPv6:2001:4f8:3:36::235]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0FCA12082E for ; Mon, 18 Nov 2019 22:09:15 -0800 (PST) Received: from fafnir.remote.dragon.net (localhost [IPv6:::1]) by mail.dragon.net (Postfix) with ESMTP id 7E83B37401FA; Mon, 18 Nov 2019 22:09:15 -0800 (PST) Received: by fafnir.remote.dragon.net (Postfix, from userid 501) id C67ED197521B; Tue, 19 Nov 2019 14:09:14 +0800 (+08) Received: from dhcp-984c.meeting.ietf.org (localhost [127.0.0.1]) by fafnir.remote.dragon.net (Postfix) with ESMTP id BF916197521A; Tue, 19 Nov 2019 14:09:14 +0800 (+08) From: Paul Ebersman To: Joe Abley cc: "add@ietf.org" In-reply-to: References: <20191118020806.AD1D51969BB0@fafnir.remote.dragon.net> Comments: In-reply-to Joe Abley message dated "Mon, 18 Nov 2019 16:22:36 -0500." X-Mailer: MH-E 7.4.2; nmh 1.7.1; XEmacs 21.4 (patch 22) MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <27397.1574143754.1@dhcp-984c.meeting.ietf.org> Date: Tue, 19 Nov 2019 14:09:14 +0800 Message-Id: <20191119060914.C67ED197521B@fafnir.remote.dragon.net> Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 19 Nov 2019 06:09:18 -0000 acampling> I agree that the use case is indeed very narrow. I'd add acampling> that better tools are already available to aid dissidents and acampling> others that do not impair the use of the web by other large acampling> groups (eg children, enterprise users etc) and in any case acampling> question the validity of the dissident use case for DoH, do acampling> not believe that it stands up to examination. ebersman> Agreed. Tor/VPN and similar solve the dissident case; DoH is ebersman> an insufficient protection against state actors or folks with ebersman> similar resources. jabley> The problem with VPNs in general is that naive users (most jabley> users) have no good way to trust their tunnel termination jabley> points. There are also fewer termination points than there are jabley> potential users, so this is another example of centralisation jabley> which in general I think is reasonable to be considered at odds jabley> with privacy. jabley> In some sense, tor is a dynamic VPN with source identity jabley> protection. The concentration problem remains. Tor and VPN certainly have issues also, but DoH (and any other DNS query/response encryption) is insufficient protection, since the following web/email/app traffic isn't necessarily encrypted. Other tech that encrypts everything is still needed. From nobody Mon Nov 18 22:16:47 2019 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 0EF73120848 for ; Mon, 18 Nov 2019 22:16:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 uRtvbZDtb7Cx for ; Mon, 18 Nov 2019 22:16:40 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0: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 E5F30120843 for ; Mon, 18 Nov 2019 22:16:39 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id d83so18502412ilk.7 for ; Mon, 18 Nov 2019 22:16:39 -0800 (PST) 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=tYL9U6g88mdZV1J0nIX2f9vXf3oZ1nkLV6IIT86vFHE=; b=DdJrOJqJCnI725PZKCqKHAdhLiO5OBFlP6wTCmV5OLWpFGxnX0LnnPm6W3aAQMqrKO zw/21wCZQHk6H2pWS8DiIzmzE/Y/rgeQjZ4JgbGFXMHIORA1OWBV0YFD7OxFiVCbVtYw TlpaAVYWKsZOvmh2Af4lu1MYsJAFbzRghpaXeOZfEFt99ocTDPnZ4qxqS1ZzN+n0pV8Y M/Ea1q8Fs8SoTET67P/naztwizoF/8CR+QfKo5S+0szh6vJH+zN6MvytKmWpG3RhCnPZ 4shyZroP/+iMN6Mgxc72rxSqfNKxb2ZPKkmHd7m+lPWMtt8tqxisGLqYXf7xTqqnCi4P GTLA== 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=tYL9U6g88mdZV1J0nIX2f9vXf3oZ1nkLV6IIT86vFHE=; b=Jc5E/b1TipjrBOXSdP9sJo3Dy8Ecqt4MSfa9H2r0T8hDFwDiyMxPWgpOoUl+dHvxdW hjRCjtM/Zn0NAPg9RAclSq8dAwv+ap8ORm+ZCGCmsLvAxzWjcqU2qDePMG0sA7xc9dWx Mab7ljaZKPTczw9ux+moPNjYWUPWCc5kJE4Z3KwU/itVUOWvvM0qiLx0Kgv+1PaIJuID BSf8kF9L2X589g9p9rPv0xM968u2zZtxL9eCA7b40ize7O7jA2Mc0GKO4B/e1nKtZOKl 4FZFLgI2cSATuhhEZ39OFuxd6RPDh8usyCzl6873LirOVv4Wn2M+YfsA35WIZDcm3NCz WKZQ== X-Gm-Message-State: APjAAAWBlIHiLFFXg1q5SdpVR1FESAWhHgZ+sxg6MK1XSCJ1xF+crfhn XayG266U1APlt0LxNMAD/7mv0A/E/E7IsL/pv09IvohdOj0= X-Google-Smtp-Source: APXvYqwbaeC3tYB6QZbWV0mMi+Z2wWkOR2QRmK62ctlNzBKILGXfdwIMLAke4mNjCuVmkqb/qCU7/DSRJSFNUXW+Pck= X-Received: by 2002:a92:b656:: with SMTP id s83mr19589104ili.282.1574144198634; Mon, 18 Nov 2019 22:16:38 -0800 (PST) MIME-Version: 1.0 From: Manu Bretelle Date: Tue, 19 Nov 2019 14:16:27 +0800 Message-ID: To: add@ietf.org Content-Type: multipart/alternative; boundary="000000000000c8f3630597ad012d" Archived-At: Subject: [Add] canary domain and recursion 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, 19 Nov 2019 06:16:44 -0000 --000000000000c8f3630597ad012d Content-Type: text/plain; charset="UTF-8" Hi all, One of the potential issue with a standard domain, is that the local network will perform recursion to learn its records. This basically allow anyone upstream/on-path from the resolver to intercept and change the result to their liking. If the intent is to detect local network policy, parental control, is it safe to assume that we want the policy to be performed by the recursive resolver? How about signaling this through .test domain [0] or similar? The resolver is not supposed to query/lookup authoritative servers for it. Someone wanting to disable DoH, would be able to return answers for A/AAAA, NXDOMAIN would mean that there is no intent to disable it. Administrator can set the policy at the host level (adding entries to /etc/hosts and the likes). Parental control for home users could do that at the CPE level, parental control for mobile phone that often rely on VPN to send DNS requests to their servers could handle those requests from the same endpoint. Enterprises, if not relying on MDM or such could do the same by configuring their resolvers to return answers for those names. Hopefully, this could isolate the policy decision to the first DNS server on path and limit anyone upstream to be able to influence the canary domain. Thoughts? Manu [0] https://tools.ietf.org/html/rfc6761#section-6.2 --000000000000c8f3630597ad012d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi all,

One of the potential issue with= a standard domain, is that the local network will perform recursion to lea= rn its records.

This basically allow anyone upstre= am/on-path from the resolver to intercept and change the result to their li= king.

If the intent is to detect local network pol= icy, parental control, is it safe to assume that we want the policy to be p= erformed by the recursive resolver?

How about sign= aling this through .test domain [0] or similar? The resolver is not suppose= d to query/lookup authoritative servers for it.
Someone wanting to disab= le DoH, would be able to return answers for A/AAAA, NXDOMAIN would mean tha= t there is no intent to disable it.

Administrator can set the policy= at the host level (adding entries to /etc/hosts and the likes). Parental c= ontrol for home users could do that at the CPE level, parental control for = mobile phone that often rely on VPN to send DNS requests to their servers c= ould handle those requests from the same endpoint.
Enterprises, if not r= elying on MDM or such could do the same by configuring their resolvers to r= eturn answers for those names.

Hopefully, this could isolate the pol= icy decision to the first DNS server on path and limit anyone upstream to b= e able to influence the canary domain.

--000000000000c8f3630597ad012d-- From nobody Mon Nov 18 23:01:11 2019 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 F1EC2120086 for ; Mon, 18 Nov 2019 23:00:54 -0800 (PST) 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 YrYpatEhmutE for ; Mon, 18 Nov 2019 23:00:50 -0800 (PST) Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id 3A61812082F for ; Mon, 18 Nov 2019 23:00:50 -0800 (PST) Received: by nyx.guxx.net (Postfix, from userid 107) id 073BF5F40B66; Tue, 19 Nov 2019 08:00:48 +0100 (CET) Received: from [172.19.219.54] (dhcp-8ca6.meeting.ietf.org [31.133.140.166]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id A66315F4059A; Tue, 19 Nov 2019 08:00:46 +0100 (CET) From: "Ralf Weber" To: "Manu Bretelle" Cc: add@ietf.org Date: Tue, 19 Nov 2019 15:00:43 +0800 X-Mailer: MailMate (1.13r5655) Message-ID: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 07:00:55 -0000 Moin! On 19 Nov 2019, at 14:16, Manu Bretelle wrote: > One of the potential issue with a standard domain, is that the local > network will perform recursion to learn its records. > > This basically allow anyone upstream/on-path from the resolver to intercept > and change the result to their liking. Not if you DNSSEC sign it. Then the last resolver still can NXD it, but nobody in the way can as it would not validate. > How about signaling this through .test domain [0] or similar? The resolver > is not supposed to query/lookup authoritative servers for it. > Someone wanting to disable DoH, would be able to return answers for A/AAAA, > NXDOMAIN would mean that there is no intent to disable it. We can do this, but it would require changes in the software as nothing is defined for these. .arpa might be better, but the problem with the software is the same. And you can certainly not sign .test, but you might be able to sign something in .arpa. So long -Ralf —-- Ralf Weber From nobody Mon Nov 18 23:10:44 2019 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 5F802120839 for ; Mon, 18 Nov 2019 23:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.998 X-Spam-Level: X-Spam-Status: No, score=-6.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz 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 P2ArlHQiUWFW for ; Mon, 18 Nov 2019 23:10:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 67F08120106 for ; Mon, 18 Nov 2019 23:10:39 -0800 (PST) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2a02:8308:a13e:40f0:4812:72ae:d39e:e874]) by mail.nic.cz (Postfix) with ESMTPSA id BDE45140DCC for ; Tue, 19 Nov 2019 08:10:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1574147437; bh=hb4Q5OSbfBMNOlxcL+vsQv6w99LseI76IHvAz+6mbmg=; h=To:From:Date; b=aLLdq16+1Orinvp30/10uPW/2Bot9RHhnV2nL1S+ZYyaUk4FfRjwtilHYMEYc0jre pOdAQezuBZRBmat/r4pWmIbVROLhOzqZ/5EfCSMK/5QypTFPP0Sm366Dw5JDnDLT/S 1OWA/cYTDiWl0wY9TwqPa2Hf0LwFT9Xi0/t+bMDA= To: add@ietf.org References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAlwQ5d0FCQWnguAACgkQzo3WoaUKIeR/ wQ//c16RhWSNICjuHhdQjJADBdzivZepVBRGsDo1Bau4A+p05iznv8REWIGVfCAAShsH/02h cT2dIoxPzJ/avK4WiDoYLzycLs5nw/eodsUIYxvNcerDNLiBbBP/stSCfPy3oX055mHxTP8P d9rhiHfgWq0dmY58r9tEz00DeP9u/UIMMpY3EXih+wsHSW2l6sXgUMDAPly8MeH0vqmrcp7Y 2/zcOJGH5gGv+KTsXVV4p6Q3h2HgJfRA+q7KCu5P32XswRJZVAiHzwsC+w+jmrtaU+gTQR2B 72m7lfkmct/5I5xAG/QcaoM3pnY/x+eNL4vJ99uK3axdm8b02y+zYqgxVlqDpwXT8cI7B0k4 V9XISZyRn4024YS9ljO2ytV45n4nedzImpqnjBVDura59m9l70aPqyF5O6Sk8IhhW1vhue4M NJnmwmZaY+p9AcB6J9PjEKTZdlpBYoaFbca+r/X0uJtN6P1s/ZJstptji3M84p/g0BnHsGXM vuvpFN3lJUIQXWvf6eZGuvWLVVeAE/vYoz380B7eIbVaNhlbZ8wnSq77atiwjttyCf4LqTBk 4nV+RsJzbS3IUz6MOg5gaet6dJHQ6tMwUOcne74HofWaoXdH0HkmaTh83mKdWjRJlwBnelzT 0ogYWv8CRr7G/I6LQ/WUx0VOmaae9oBdTVCozM+0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAlwQ5eEFCQWnguAACgkQzo3WoaUKIeTE3BAAsXJDtGuCF/Ssz0Y3 b6SA/3ZC+i3bWHz8l7dtFO+gvKFhRdwAxGY4NlD/QSyMTEVz6lHCf4TQYPZOmKisOdEyklgS Yep6dgYitnlMTSUfDC7R+L9fd68NjiPrw4WWKblDr7ukc6VlZpGxKblPpuVLAho0MVi0GEjR fVldMaptchQEW4bGiWj/ESBSR4PL7oPhHzJPXsJMeS4Zhit9RiegFOuPfExWKX+U0yJ69qSU AvyRE1WXQi3gzxXMdPIR0yrukbQInQJ9TwI6LMKy7j7PLx2zExUTRK6GO7TktKwKVn1fVyzF Ir0eMqr5MbUfHapyIUdEHWoLaY0i9ZObXQaSPi0tNZwmneTZbK/7UrawsXGt4Y7BvHS5Hte0 ggFOKJkCJWyMEfQPf2obZkvP5smRC+VMNlC5fOwxLnXBE69NXE9hxdenTr2E43b79Colqyak 4eE7J0aQHe6iQDRyuq8w6cr4Ry54pBCym90saIUt58k+4zxVXJH18VliOdfa98ZlsT4zFjzA biYNuGDGxQ5EAS01Qf8bR29O/rp/MqmXmr0Yhmzt6X7UhTfXDsqK+BLt+xZw6x3OrgrNnM0F Em0QOjFfhv2VDw/q20yU+Ls+dD6I3Q5TEpKcCcpCKoowVE7XMfba+fuKIXgkw7fb//QdymzJ XygR2MORImwVGcN8tba5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXBDl9wUJBaeC+gAKCRDO jdahpQoh5OD7D/0bKnkRwHgChHe8pXE/RICHXMGF6vduH24ZopMBa3T7S/x/JlgYQ+pmv//2 uSh0+ddtCev2iDOMmZmmw+8Y/JFmKRaNgjCR8zZVvgELKvnBD3770oGShvnMJCZTDajuz+Ah KkWwILkHR5i6wCtUOesLKuujJrFs3oylRvmXNUwQ4LNiWO12s9EBc8sUpGbeKMtXRFxg/Mkl U49XkTNR8K0awZNddEj1j07/uUVon6JafDKCj9eiLQiAEe84CP0andDQFj6wjpGDOb11t12b yBgnj4WN9mK8jt9t19K5tNa+u0WYV0ei8g8lgu9cruFQbbbDDgKd4gUPihlJXL3FSiol/SpA 2u7MSpOvvLuVtkjPGA8JJWYfSOmAnWmjpEtomWU0D5mSU5Dvp8IyJoPnJC4mW7APnD5pw9ZN uZlfoOKMYc9lKPN5SSIwpy1hJGpVSjomYrR2DDCbeXX86tvgPdiwtU9ANrhmsJ9KV2sYLfOQ QnyIJVJhDCVzQl8jHKfwLcsvFOg9h4W/9tBN4NgGNpXtrRJD/EpR2mBEXOsavGPsIzZYdynE ItUrRqChu5Q7thei58dEzrLSt8zBPXRtoOOH6EsoyyHFOqw/nmVa+0xKV5IaOF5VOJkKFveM rStQ8ILhGDeANMRCym0LdOA3jw+0umaGw1zgk+brjOWut4idlA== Organization: CZ.NIC Message-ID: <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> Date: Tue, 19 Nov 2019 08:10:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> Content-Type: text/plain; charset=utf-8 Content-Language: en-PH Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz X-Virus-Status: Clean Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 07:10:42 -0000 On 19. 11. 19 8:00, Ralf Weber wrote: > Moin! > > On 19 Nov 2019, at 14:16, Manu Bretelle wrote: >> One of the potential issue with a standard domain, is that the local >> network will perform recursion to learn its records. >> >> This basically allow anyone upstream/on-path from the resolver to intercept >> and change the result to their liking. > Not if you DNSSEC sign it. Then the last resolver still can NXD it, but > nobody in the way can as it would not validate. I agree with Ralf. > >> How about signaling this through .test domain [0] or similar? The resolver >> is not supposed to query/lookup authoritative servers for it. >> Someone wanting to disable DoH, would be able to return answers for A/AAAA, >> NXDOMAIN would mean that there is no intent to disable it. Asking for a new special-use name is usually asking for trouble for two reasons: Getting special-name reservation involves too much politics, and getting it deployed requires changes in all DNS stacks. Please let's use a normal DNS delegation. Petr Špaček @ CZ.NIC > We can do this, but it would require changes in the software as nothing is > defined for these. .arpa might be better, but the problem with the > software is the same. And you can certainly not sign .test, but you might > be able to sign something in .arpa. > > So long > -Ralf From nobody Mon Nov 18 23:11:26 2019 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 F22F8120878 for ; Mon, 18 Nov 2019 23:11:21 -0800 (PST) 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, SPF_HELO_NONE=0.001, SPF_NONE=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 kQD1N_f8sl_C for ; Mon, 18 Nov 2019 23:11:18 -0800 (PST) Received: from p130.piuha.net (p130.piuha.net [IPv6:2001:14b8:1829::130]) by ietfa.amsl.com (Postfix) with ESMTP id 82E02120869 for ; Mon, 18 Nov 2019 23:11:18 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 6EC47660144 for ; Tue, 19 Nov 2019 09:11:17 +0200 (EET) Received: from p130.piuha.net ([127.0.0.1]) by localhost (p130.piuha.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m4MX7CwmtVEf for ; Tue, 19 Nov 2019 09:11:16 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [IPv6:2001:14b8:1829::130]) by p130.piuha.net (Postfix) with ESMTPS id A09406600DF for ; Tue, 19 Nov 2019 09:11:15 +0200 (EET) From: Jari Arkko Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> Date: Tue, 19 Nov 2019 15:11:11 +0800 To: ADD Mailing list X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [Add] Narrowed-down proposal 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, 19 Nov 2019 07:11:22 -0000 Since most people on the mic line commented on the proposed scope being = too wide, I=E2=80=99d like to offer one initial thought on a more narrow = proposal: * write a specification that allows the discovery of and the use of DNS = servers, with something like adaptive DNS as a starting point - including general security analysis, privacy impacts analysis, and = resistance to pervasive surveillance analysis regarding this proposal * use standard IETF WG process This is one topic from the long list of proposals. If there are more = that are feasible to be pursued, another working group(s), or sequential = working groups.=20 Jari From nobody Mon Nov 18 23:23:30 2019 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 11099120B9E for ; Mon, 18 Nov 2019 23:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, 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=telefonica.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 163G0MR8wUsM for ; Mon, 18 Nov 2019 23:23:17 -0800 (PST) Received: from EUR04-HE1-obe.outbound.protection.outlook.com (mail-eopbgr70093.outbound.protection.outlook.com [40.107.7.93]) (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 08190120106 for ; Mon, 18 Nov 2019 23:23:16 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fzfL/+pmsEFK0smIOufneqXDdgDQ826ljG7vRa7dgqYa+eX5I3ZaN3/OaOeviFjgKkwktUUEl6V7cCjIX4IAdLzuIB3Jiz6YCYnjJZLAwKN9e0eTBRCEv5Ci7UwZhfZ32Mzo/1neUONG33LOMsgmSKI2WzMrjxOJ0FeVNOBBcdkKuY/5qBbny6GUbMgyOohKX/aLqWidPW9wYX8AT9lWZHPyAhIGHhO6VnE8c55SiPVmcaY0d6mkT5yWgXCoe6e4r7Ne3gDxoqBEqdcaICHPqYTlapPfOjAUxwwM8nKNTK0Kwgd8D458b6k2stJrb0zHJ7I4aj9jCtwuQx3FIEr++w== 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=9HTre2+1idwhspeB8JweLZcD7jy816XQYSKmVrc43bY=; b=Etr9yMoQ93twh9boK1D5C+NmTZ/GhVGR0E59D1zSOCGC/Gs9EmzCEzTi2uix24SyRcZPOQzHwoGLeG8TvKV0oaHKS/a3iSVktmR/vvFLo2/vgu82Aggx3demfE3MQmkkWIuEKO8Y5J5R/ku8guAhn2L6K0IQ/KXVoQQaH548OGWc/6QoxwcGC8ieAnFtlxxuARJ3GI73nCud4WAGjk0Yi87y3qpboX8qBbDc/4SLqIWrD353EbALMsKG4stjcf3HIln9fYHEP2KIt/4ZmCltvTQiLHyfiMXd2yMFG/vAGZB7Yr4nost7OCjOvtDcxN/v7nC1mL/bHVE2T6lnsCI1LA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=telefonica.com; dmarc=pass action=none header.from=telefonica.com; dkim=pass header.d=telefonica.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telefonica.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9HTre2+1idwhspeB8JweLZcD7jy816XQYSKmVrc43bY=; b=JW7fKr8fPg+CdDWRpuo6+vvGzo496RvDyfdz8qLOYKSGthVS0eWM0VJjlxjqIgqlMb0SUj94DVNBXGtk2mww8Hod0EQJsKSgFrk440BM9Ze1fzGjd4tc2MnBM9HvZbupMg3mXhJZmV1W4EzXEDdox3NweylOdQpUOQuyPj9uEzw= Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com (52.134.70.148) by DB3PR0602MB3769.eurprd06.prod.outlook.com (52.134.70.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.23; Tue, 19 Nov 2019 07:23:14 +0000 Received: from DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::110f:5653:9dc2:14ee]) by DB3PR0602MB3788.eurprd06.prod.outlook.com ([fe80::110f:5653:9dc2:14ee%7]) with mapi id 15.20.2451.031; Tue, 19 Nov 2019 07:23:14 +0000 From: "Diego R. Lopez" To: Jari Arkko , ADD Mailing list Thread-Topic: [Add] Narrowed-down proposal Thread-Index: AQHVnqiSOpoFMDlQYE2m4xqUYBArfaeSJ9qA Date: Tue, 19 Nov 2019 07:23:14 +0000 Message-ID: <65704CF7-CF02-432D-A302-A66BFF99452E@telefonica.com> References: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> In-Reply-To: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.10.10.191111 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [2001:67c:370:128:3808:683a:5781:a374] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 326dba9b-ff46-46cd-32de-08d76cc1573a x-ms-traffictypediagnostic: DB3PR0602MB3769: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(136003)(376002)(39860400002)(396003)(346002)(366004)(40134004)(189003)(199004)(11346002)(2616005)(76176011)(446003)(6246003)(66946007)(6512007)(476003)(66556008)(66446008)(14444005)(46003)(486006)(6306002)(66476007)(64756008)(5660300002)(14454004)(6506007)(8936002)(186003)(478600001)(6436002)(25786009)(45080400002)(8676002)(102836004)(99286004)(2906002)(81166006)(81156014)(6486002)(229853002)(256004)(7736002)(305945005)(36756003)(58126008)(561944003)(966005)(786003)(86362001)(33656002)(316002)(110136005)(66574012)(71200400001)(71190400001)(6116002)(76116006)(91956017); DIR:OUT; SFP:1102; SCL:1; SRVR:DB3PR0602MB3769; H:DB3PR0602MB3788.eurprd06.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2qRSr+uWZGy8yhgaCsQROOo0c0kRIuas6sdjtGonv50Kx0eXPSfAwC0lqTMWkEMWaq22Ptvuab8/QXod8rXWnpHPiTwXxd2WVrj53e8ERM6XqlkZU5N/WZZfSKAl1OScceX35/OAKANfY6v14ysrCaXyWysjlTil0Gr/54OU4waWLZs1D22OuDELkA2xYKGQgFZNBBbRlOjB4IsqZGyJ6jRY2pzVjYYvG/escyQUGiSml14sWkNTn0JqMsVAGCVbgFLB5Hgev2JD5DcnqTXVC6L+vqFMY388BXwqYZobxq4VJwvFbSX9yPzBAGOHE6FyDS4nk9OH+Af779DYsg2hBXmksxau7s8OWad3Bt1V/9Iy/Ty6fo5gOz8ZKuyM1XtjOpUl/Z3Jg9OVHNnrpSQVOYcT2LZd7r3EHrHhZIQaDKMx8gZqidmo0ZWNMuNtqvoLykWQhjXB2nuVhiNBKKpZRQ5Rsa/+Csa/KC+Q24s724g= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: 326dba9b-ff46-46cd-32de-08d76cc1573a X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 07:23:14.2445 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: jATdV8ECnyu0BSffyxVERUfcFPgXUkx4moL0utK+9bMC2webNOKzQBO3Yu3Hpgaq6gOQe832Q7p8pT4uMl/X2t+E4cAqstCfP6R1UITigIs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB3PR0602MB3769 Archived-At: Subject: Re: [Add] Narrowed-down proposal 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, 19 Nov 2019 07:23:26 -0000 SSBzdHJvbmdseSBzdXBwb3J0IEphcmkncyB2aWV3IGFuZCBwcm9wb3NhbA0KDQooYWN0dWFsbHks IHNvbWV0aGluZyBsaWtlIHRoaXMgaXMgd2hhdCBJIHB1dCBvbiBteSBub3RlcyBhcyBhIHBvc3Np YmxlIHdheSBmb3J3YXJkKQ0KDQotLQ0KIkVzdGEgdmV6IG5vIGZhbGxhcmVtb3MsIERvY3RvciBJ bmZpZXJubyINCg0KRHIgRGllZ28gUi4gTG9wZXoNClRlbGVmb25pY2EgSStEDQpodHRwczovL3d3 dy5saW5rZWRpbi5jb20vaW4vZHIybG9wZXovDQoNCmUtbWFpbDogZGllZ28uci5sb3BlekB0ZWxl Zm9uaWNhLmNvbQ0KVGVsOiAgICAgICAgICszNCA5MTMgMTI5IDA0MQ0KTW9iaWxlOiAgKzM0IDY4 MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCu+7v09uIDE5 LzExLzIwMTksIDE1OjExLCAiQWRkIG9uIGJlaGFsZiBvZiBKYXJpIEFya2tvIiA8YWRkLWJvdW5j ZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGphcmkuYXJra29AcGl1aGEubmV0PiB3cm90ZToNCg0K ICAgIFNpbmNlIG1vc3QgcGVvcGxlIG9uIHRoZSBtaWMgbGluZSBjb21tZW50ZWQgb24gdGhlIHBy b3Bvc2VkIHNjb3BlIGJlaW5nIHRvbyB3aWRlLCBJ4oCZZCBsaWtlIHRvIG9mZmVyIG9uZSBpbml0 aWFsIHRob3VnaHQgb24gYSBtb3JlIG5hcnJvdyBwcm9wb3NhbDoNCg0KICAgICogd3JpdGUgYSBz cGVjaWZpY2F0aW9uIHRoYXQgYWxsb3dzIHRoZSBkaXNjb3Zlcnkgb2YgYW5kIHRoZSB1c2Ugb2Yg RE5TIHNlcnZlcnMsIHdpdGggc29tZXRoaW5nIGxpa2UgYWRhcHRpdmUgRE5TIGFzIGEgc3RhcnRp bmcgcG9pbnQNCiAgICAgIC0gaW5jbHVkaW5nIGdlbmVyYWwgc2VjdXJpdHkgYW5hbHlzaXMsIHBy aXZhY3kgaW1wYWN0cyBhbmFseXNpcywgYW5kIHJlc2lzdGFuY2UgdG8gcGVydmFzaXZlIHN1cnZl aWxsYW5jZSBhbmFseXNpcyByZWdhcmRpbmcgdGhpcyBwcm9wb3NhbA0KICAgICogdXNlIHN0YW5k YXJkIElFVEYgV0cgcHJvY2Vzcw0KDQogICAgVGhpcyBpcyBvbmUgdG9waWMgZnJvbSB0aGUgbG9u ZyBsaXN0IG9mIHByb3Bvc2Fscy4gSWYgdGhlcmUgYXJlIG1vcmUgdGhhdCBhcmUgZmVhc2libGUg dG8gYmUgcHVyc3VlZCwgYW5vdGhlciB3b3JraW5nIGdyb3VwKHMpLCBvciBzZXF1ZW50aWFsIHdv cmtpbmcgZ3JvdXBzLg0KDQogICAgSmFyaQ0KDQogICAgLS0NCiAgICBBZGQgbWFpbGluZyBsaXN0 DQogICAgQWRkQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9hZGQNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkVzdGUg bWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1c2l2YW1lbnRlIGEgc3UgZGVz dGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24gcHJpdmlsZWdpYWRhIG8gY29u ZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxhIHBlcnNvbmEgbyBlbnRpZGFk IGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5hdGFyaW8gaW5kaWNhZG8sIHF1 ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxlY3R1cmEsIHV0aWxpemFjacOzbiwgZGl2dWxnYWNp w7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBlc3RhciBwcm9oaWJpZGEgZW4g dmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBoYSByZWNpYmlkbyBlc3RlIG1l bnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8gY29tdW5pcXVlIGlubWVkaWF0 YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEgc3UgZGVzdHJ1Y2Npw7NuLg0K DQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZp bGVnZWQgYW5kIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUg dXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRl ciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUg aGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiBvciBj b3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3RseSBwcm9oaWJpdGVkLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgZG8gbm90IHJlYWQg aXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIHRoYXQgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFuZCB0aGVuIGRlbGV0ZSBpdC4N Cg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmlnZW0gZXhjbHVzaXZhbWVudGUg YW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9ybWHDp8OjbyBwcml2aWxlZ2lh ZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhjbHVzaXZvIGRhIHBlc3NvYSBvdSBl bnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNlbmhvcmlhIG8gZGVzdGluYXTD oXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBhIGxlaXR1cmEsIHV0aWxpemHD p8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0 YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJl dSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVl IGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVp w6fDo28NCg== From nobody Mon Nov 18 23:23:34 2019 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 7D59A120106 for ; Mon, 18 Nov 2019 23:23:26 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 qWAq5vlluJoW for ; Mon, 18 Nov 2019 23:23:21 -0800 (PST) Received: from mail-qt1-x829.google.com (mail-qt1-x829.google.com [IPv6:2607:f8b0:4864:20::829]) (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 3381A12087C for ; Mon, 18 Nov 2019 23:23:21 -0800 (PST) Received: by mail-qt1-x829.google.com with SMTP id p20so23523223qtq.5 for ; Mon, 18 Nov 2019 23:23:21 -0800 (PST) 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=J+ayAvxps0RW+nqwO3Ea2zX4NFydvJfRAdbLnuJF3U0=; b=wVHh4OFWxPbQ6uwCufX48dI3PXQVcZrsQbBZO6PO4aESDwXlg9muXg4gVuz7ca/beS NkYIj+RBY9loNbIJ9aZPaQ5Enn200fzYU8aXT7MgfXyNqJc8UQKP5FtQFcwbj220ZFzs UeZFrhy4RMaiU3XjbWGZ62NG78J1RYyzpbj2Eqr4zw6Jte9uXk7YJQ7rDugtzrIYy8Ug r21YDfbaQFShc4cR4LqVn1sUDXsR2xl5aMjCHsiHu5lItYbXfrlecrzqM+Kl7OhE6cDc m5zPqXr6Y9Cm8Hc1Iie+G8u5E31/dC9DR5otz6T2NyHyhWaRXSZ29vZjx1/V9Sc/tYzL Hxyw== 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=J+ayAvxps0RW+nqwO3Ea2zX4NFydvJfRAdbLnuJF3U0=; b=YO9X0aY0/5NZXL7x/y8IecZl8FEY9iEsSksXNJaM401n53Gv2zFn7YijD8+C5dWcYn rjm5CFZuk6Gg/hOI73O+xsTlrrJdX+pVFux0yqbbIBWJfEXUZHEZTsB4u5Q1zujc+5oZ u1zhGLqDFhcZbB1DgvC8H4a/rzEn2+2MDN8tj+uCQicBG2fWIzDWHbC0MFBJZneHfyyq AIrrAEcfHQkfwNWQAyb1x3E3+AJfU3HNL/vA/v/k47A0wydeN/w7y8lQQUvwBUK16liT Ol9DfNabJfsLT1BXaGDFMHZUATNn8f4h3hBGB4K+qM2fgs14o3ZeT73xcLuH+6ekronu YZoA== X-Gm-Message-State: APjAAAWemZr3beXnn2svg27XljY4+K+DQRZX2+mIGcbMalOfA59mofPJ Uop6dJS0+mm3fkJC257+pYyTNQ== X-Google-Smtp-Source: APXvYqzfAFDeoCMpjUtMMQ1D2ace5uRoKo3yUHcpPAU9Klc2OFWVWsFIRQJlM2OvPd/AYvvN/TkeXw== X-Received: by 2002:ac8:670a:: with SMTP id e10mr24940651qtp.193.1574148200129; Mon, 18 Nov 2019 23:23:20 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:6101:8b1:d9fd:1e9a? ([2601:18b:300:36ee:6101:8b1:d9fd:1e9a]) by smtp.gmail.com with ESMTPSA id b54sm12333162qta.38.2019.11.18.23.23.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Nov 2019 23:23:19 -0800 (PST) From: Ted Lemon Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_63711D3E-0FFD-47F8-953B-87D1CE41A4A8" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.1\)) Date: Tue, 19 Nov 2019 02:23:17 -0500 In-Reply-To: Cc: Rob Sayre , Glenn Deen , ADD Mailing list , Dave Lawrence To: Andrew Campling References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> X-Mailer: Apple Mail (2.3608.40.2.2.1) Archived-At: Subject: Re: [Add] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 07:23:29 -0000 --Apple-Mail=_63711D3E-0FFD-47F8-953B-87D1CE41A4A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 18, 2019, at 9:55 PM, Andrew Campling = wrote: > It would quite a lot of work to detail everything that a given WG = won=E2=80=99t cover! I think it more efficient for the charter to detail = what is in scope for the WG to avoid anyone wasting time and energy on = out of scope matters =E2=80=93 although of course that is a choice = available to anyone should they wish to document such items. It might be worth noting here that if an item is chartered and adopted, = in some sense it presumptively has consensus. At that point, =E2=80=9Cno = consensus=E2=80=9D means that there are objections that have been raised = that have not been addressed. So it actually _is_ important that we get any charter right. As Adam = mentioned, we don=E2=80=99t have to exclude everything, but we should = exclude things that might, on an off day, get adopted. It=E2=80=99s = important to be clear about what is not in charter when it=E2=80=99s = something that we already know some participants would like to be in = charter. To Dave=E2=80=99s point, that it is worth documenting why we didn=E2=80=99= t do something, I agree with that point in principle, but that=E2=80=99s = _not_ a reason to put the thing in charter. If you want to document why = there isn=E2=80=99t consensus to do X, putting X in charter is the wrong = thing to do. What you should put in charter is =E2=80=9Cdocument why = there is no consensus to do X.=E2=80=9D If you don=E2=80=99t feel that = you know for sure that there is no consensus to do X, or if you don=E2=80=99= t want to put it in the charter that way, then explicitly declare it out = of scope. --Apple-Mail=_63711D3E-0FFD-47F8-953B-87D1CE41A4A8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 18, 2019, at 9:55 PM, Andrew Campling <andrew.campling@419.consulting> wrote:
It would quite a lot of work to = detail everything that a given WG won=E2=80=99t cover! I think it more = efficient for the charter to detail what is in scope for the WG to avoid = anyone wasting time and energy on out of scope matters =E2=80=93 = although of course that is a choice available to anyone should they wish = to document such items.

It might be worth noting here that if an item is chartered = and adopted, in some sense it presumptively has consensus.  At that = point, =E2=80=9Cno consensus=E2=80=9D means that there are objections = that have been raised that have not been addressed.

So it actually _is_ = important that we get any charter right.   As Adam mentioned, we = don=E2=80=99t have to exclude everything, but we should exclude things = that might, on an off day, get adopted.  It=E2=80=99s important to = be clear about what is not in charter when it=E2=80=99s something that = we already know some participants would like to be in charter.

To Dave=E2=80=99s point, = that it is worth documenting why we didn=E2=80=99t do something, I agree = with that point in principle, but that=E2=80=99s _not_ a reason to put = the thing in charter.  If you want to document why there isn=E2=80=99= t consensus to do X, putting X in charter is the wrong thing to do. =  What you should put in charter is =E2=80=9Cdocument why there is = no consensus to do X.=E2=80=9D   If you don=E2=80=99t feel that you = know for sure that there is no consensus to do X, or if you don=E2=80=99t = want to put it in the charter that way, then explicitly declare it out = of scope.

= --Apple-Mail=_63711D3E-0FFD-47F8-953B-87D1CE41A4A8-- From nobody Mon Nov 18 23:24:49 2019 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 4F4B11201AA for ; Mon, 18 Nov 2019 23:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=microsoft.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 eFaub9Lu1Zvi for ; Mon, 18 Nov 2019 23:24:43 -0800 (PST) Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640113.outbound.protection.outlook.com [40.107.64.113]) (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 D0AF6120106 for ; Mon, 18 Nov 2019 23:24:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ae26ZwWtTbDvwtYiIBX6mww7iNJTNB2IRCxThpVDuoNdYsV7r6P8pAaRjwr0fU+DicI84DEqJX4SURVRj19x4wOC5GCWpBs3/ybEPTzEsCsyqeES40Qa6M/bQ7zUAmdAxbkllBwdEuPBjenOy1ZTGN701PgRUAHaoN4f9FJHNj2Qb+oc/lG8yw/96Bcp9LQN0XAL7Y9k48CXc+6mNp1mrONRDF/x67QYIi/pEnbNvu/nJ8a0c8SrRtO43rYzqm3YSGW44ztvIJG2R0lzXX5MRvfotqErDrQ5Hy8F7V7UEXmx34tSBkWuNYe4/F3XyMHaN238xxIISDxMOYWw6nQccw== 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=vwmRy00QcHW//CgrtY+DZIsGBxXtspwKhniBIrbV/gs=; b=DRRcBh7USnqxjGHKjxEo7rlGp+yBiRq97UQ1ZbZN8MQ+Ddvlw54e7O/Q2nn/Na4OkxynkykcOqNvBdtI/tONhAicaqNSnrg0pWrQYAP6Q6uOEwqdVAo6rjW7s7phbBi2Fw8gw8w5DcsuN7gpa5fszLFd5Hc0nwov0OsXFPxrokGJx/F9IIJORqTvW1aT2cdyuXnJBrJj5FCoH+NakimqR4v2ljt5dcNBtc3idh70JSBfSJd2CMk5oA+Ef3U8bjsSk2ljm/sedDPHQieIC8GQ1O2Pz5lVTwJkVG3H2w3J954jd8fwko93VPaLXJBKow54JyOz5b4DuC3F5L5aWALYrw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vwmRy00QcHW//CgrtY+DZIsGBxXtspwKhniBIrbV/gs=; b=hAff+g0x7Zg0rnOFQWy3EjYbtB0zOqURdtpgySyKvgDfq3xh8IbaGa5qu2GixXeftNOzWOdZijeJ/YQZbSYXYFD87EPmf/lkiwkT9WKZ/DywJtgJyWcfz/CUAPyDRXb4oZ/fsaAHgwjtJ4CWFEIJkNnG18TZ3xLJeOW6PB8oBXE= Received: from CY1PR00MB0076.namprd00.prod.outlook.com (10.167.9.145) by CY1PR00MB0121.namprd00.prod.outlook.com (10.167.9.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2504.0; Tue, 19 Nov 2019 07:23:34 +0000 Received: from CY1PR00MB0076.namprd00.prod.outlook.com ([fe80::1b9:fef3:f076:b726]) by CY1PR00MB0076.namprd00.prod.outlook.com ([fe80::1b9:fef3:f076:b726%6]) with mapi id 15.20.2508.000; Tue, 19 Nov 2019 07:23:34 +0000 From: Tommy Jensen To: Jari Arkko , ADD Mailing list Thread-Topic: [Add] Narrowed-down proposal Thread-Index: AQHVnqiTyPLHP+R/D0OR49e117mY26eSFKOs Date: Tue, 19 Nov 2019 07:23:34 +0000 Message-ID: References: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> In-Reply-To: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2019-11-19T07:23:33.387Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; authentication-results: spf=none (sender IP is ) smtp.mailfrom=Jensen.Thomas@microsoft.com; x-originating-ip: [2601:600:a080:aff0:a5fa:b5ba:aef0:f1b] x-ms-publictraffictype: Email x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 608af1f0-6722-44ef-15b4-08d76cc162fa x-ms-traffictypediagnostic: CY1PR00MB0121: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(366004)(39860400002)(346002)(396003)(189003)(199004)(256004)(14444005)(966005)(478600001)(6246003)(486006)(76176011)(99286004)(10290500003)(236005)(9686003)(54896002)(6306002)(476003)(55016002)(11346002)(105004)(229853002)(86362001)(6436002)(446003)(606006)(46003)(66556008)(66476007)(66446008)(52536014)(64756008)(91956017)(76116006)(66946007)(110136005)(5660300002)(74316002)(81166006)(6506007)(81156014)(71200400001)(71190400001)(53546011)(8676002)(7736002)(316002)(8936002)(102836004)(14454004)(19627405001)(33656002)(186003)(6116002)(8990500004)(7696005)(25786009)(10090500001)(22452003)(2906002)(561944003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR00MB0121; H:CY1PR00MB0076.namprd00.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zIiJSm1l42D9CTRLdj61aS8foOuDcfpCmOlQ1VUC+eEEg1fK2lFGViohha56qOT3Y8M4PgII2Gt7LeLUNZuz4neNRNPOM3IA7KoxlGTh3QjghD32byQu2whPguA4j0+RS9k7Qs8F8f33k2eiJdpch3wvKiOYqy4gFPow6Zc8UHAS6Vvvf2ybREQ45xtrBa4A2tK6CeFe/OmKZvKVzM4TG62kJmLyOUljepXC4OIXaP9XRw0mKyL2eGpQEarN41rfPrcsMyd65W4Kq5RGiAZLeTFYHR2jGiCLYhifK3PjUMRTsaO3i0hhFMLaNdZRIG8aGE5eiC/YUz7QHPxnBpk8XWBKsATDrreeQy/8EFWtZthKLexYu19qhzLrHl0H4M5/9o7HxfVaL+YvsWtwdXxvol3B8LgjGmU2glH78rpapUgT5s4roqBKlyZnhk6I3dvVtuqTRjOAzWxjpCIRNfMTgcomOVH7evz4iIzjKSJzlmY= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CY1PR00MB0076994F7D21234BE8F978AAFA4C0CY1PR00MB0076namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 608af1f0-6722-44ef-15b4-08d76cc162fa X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 07:23:34.0549 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: zsF+hb30EtyUN1H5WLkM/y1uFJFrXvoZhPE0ojqsozdvOtWqhFbPibrmqJT3kD+pduuGW4oG/WaTRj7x2c+S4Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR00MB0121 Archived-At: Subject: Re: [Add] Narrowed-down proposal 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, 19 Nov 2019 07:24:48 -0000 --_000_CY1PR00MB0076994F7D21234BE8F978AAFA4C0CY1PR00MB0076namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable I agree with this. Common concerns seem to be too wide of a scope and too n= on-standard a WG process. Using (the other) Tommy's proposal as a framework= also seems like a great way to keep us all focused on concrete discussion = as opposed to philosophical discussions regarding DNS. I would support a WG chartered with exploring Adaptive DNS for 1) security = impact, 2) privacy impact, 3) resistance to pervasive surveillance, and 4) = maintenance and debug-ability (that was a great point, Melanie! (sp?)) usin= g standard IETF mechanisms for consensus and the like. Either we find Tommy's proposal works well with tweaks, and that's great, o= r we find fundamental flaws and those flaws inform our concrete requirement= s for another solution. Either way we get concrete results with some establ= ished text already in place from which to get to working code sooner rather= than later. Thanks, The Microsoft Tommy ________________________________ From: Add on behalf of Jari Arkko Sent: Monday, November 18, 2019 11:11 PM To: ADD Mailing list Subject: [Add] Narrowed-down proposal Since most people on the mic line commented on the proposed scope being too= wide, I=92d like to offer one initial thought on a more narrow proposal: * write a specification that allows the discovery of and the use of DNS ser= vers, with something like adaptive DNS as a starting point - including general security analysis, privacy impacts analysis, and resi= stance to pervasive surveillance analysis regarding this proposal * use standard IETF WG process This is one topic from the long list of proposals. If there are more that a= re feasible to be pursued, another working group(s), or sequential working = groups. Jari -- Add mailing list Add@ietf.org https://nam06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.iet= f.org%2Fmailman%2Flistinfo%2Fadd&data=3D02%7C01%7CJensen.Thomas%40micro= soft.com%7C29ef0eabc57843f8585e08d76cbfb3c9%7C72f988bf86f141af91ab2d7cd011d= b47%7C1%7C0%7C637097442926214777&sdata=3D6K8P%2FAvJps7nrDnlAwh9%2Bq4MXh= lJtcPRBqXnC%2FidZzs%3D&reserved=3D0 --_000_CY1PR00MB0076994F7D21234BE8F978AAFA4C0CY1PR00MB0076namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
I agree with this. Common concerns seem to be too wide of a scope and too n= on-standard a WG process. Using (the other) Tommy's proposal as a framework= also seems like a great way to keep us all focused on concrete discussion = as opposed to philosophical discussions regarding DNS.

I would support a WG chartered with exploring Adaptive DNS for 1) security = impact, 2) privacy impact, 3) resistance to pervasive surveillance, and 4) = maintenance and debug-ability (that was a great point, Melanie! (sp?)) usin= g standard IETF mechanisms for consensus and the like.

Either we find Tommy's proposal works well with tweaks, and that's great, o= r we find fundamental flaws and those flaws inform our concrete requirement= s for another solution. Either way we get concrete results with some establ= ished text already in place from which to get to working code sooner rather than later.

Thanks,
The Microsoft Tommy
From: Add <add-bounces@i= etf.org> on behalf of Jari Arkko <jari.arkko@piuha.net>
Sent: Monday, November 18, 2019 11:11 PM
To: ADD Mailing list <add@ietf.org>
Subject: [Add] Narrowed-down proposal
 
Since most people on the mic line commented on the= proposed scope being too wide, I=92d like to offer one initial thought on = a more narrow proposal:

* write a specification that allows the discovery of and the use of DNS ser= vers, with something like adaptive DNS as a starting point
  - including general security analysis, privacy impacts analysis, and= resistance to pervasive surveillance analysis regarding this proposal
* use standard IETF WG process

This is one topic from the long list of proposals. If there are more that a= re feasible to be pursued, another working group(s), or sequential working = groups.

Jari

--
Add mailing list
Add@ietf.org
https://nam= 06.safelinks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwww.ietf.org%2Fmai= lman%2Flistinfo%2Fadd&amp;data=3D02%7C01%7CJensen.Thomas%40microsoft.co= m%7C29ef0eabc57843f8585e08d76cbfb3c9%7C72f988bf86f141af91ab2d7cd011db47%7C1= %7C0%7C637097442926214777&amp;sdata=3D6K8P%2FAvJps7nrDnlAwh9%2Bq4MXhlJt= cPRBqXnC%2FidZzs%3D&amp;reserved=3D0
--_000_CY1PR00MB0076994F7D21234BE8F978AAFA4C0CY1PR00MB0076namp_-- From nobody Tue Nov 19 00:14:48 2019 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 662E912080B for ; Tue, 19 Nov 2019 00:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id olSbZONdqoNN for ; Tue, 19 Nov 2019 00:14:40 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F39120B84 for ; Tue, 19 Nov 2019 00:14:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 6D84DBE2F; Tue, 19 Nov 2019 08:14:38 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzOg376Lj88j; Tue, 19 Nov 2019 08:14:33 +0000 (GMT) Received: from [31.133.134.154] (dhcp-869a.meeting.ietf.org [31.133.134.154]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5A97ABE2E; Tue, 19 Nov 2019 08:14:32 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1574151273; bh=q5K/V+g6i/WIy65oJv0tLSADe01ReK2sRhsCCueP0oM=; h=Subject:To:References:From:Date:In-Reply-To:From; b=ryPXGtZjdSkkiPur/yIOm7wIZy9VTcxOC+kPKtTGmbQ3UBtop7YaNgbUjCjRJuhGP 7kuMowWRJCdKL+FCI+dIgxDzLEHpQSvv3mAMJQ9koLA/1LJegQTgVB6IWcFPBCSYGK IFPDyPkP9k1bkbWLnrRljBnqUSWaxXitTp5WIx8o= To: Jari Arkko , ADD Mailing list References: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Tue, 19 Nov 2019 08:14:24 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.1.2 MIME-Version: 1.0 In-Reply-To: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="jRbIti7D2UcEODTsJTc9EM1BqrCkfDSxA" Archived-At: Subject: Re: [Add] Narrowed-down proposal 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, 19 Nov 2019 08:14:46 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --jRbIti7D2UcEODTsJTc9EM1BqrCkfDSxA Content-Type: multipart/mixed; boundary="V8Es2Ztc8Mqtq0qCS73MOYX4xakgJUrOp"; protected-headers="v1" From: Stephen Farrell To: Jari Arkko , ADD Mailing list Message-ID: Subject: Re: [Add] Narrowed-down proposal References: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> In-Reply-To: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> --V8Es2Ztc8Mqtq0qCS73MOYX4xakgJUrOp Content-Type: multipart/mixed; boundary="------------6E05878CA7C27F0B4ACB229D" Content-Language: en-US This is a multi-part message in MIME format. --------------6E05878CA7C27F0B4ACB229D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hiya, On 19/11/2019 07:11, Jari Arkko wrote: > Since most people on the mic line commented on the proposed scope > being too wide, I=E2=80=99d like to offer one initial thought on a more= > narrow proposal: >=20 > * write a specification that allows the discovery of and the use of > DNS servers, with something like adaptive DNS as a starting point - If there were sufficient interest in the above from multiple implementers and operators, then I'd be in agreement with Jari. I don't think we know if that is or is not the case. (Well, I don't know anyway.) That said, I'm not clear if the "designated resolver" idea would actually work out, but maybe it could. (I don't see how it works without co-ordination of complex DNSSEC-signed content in multiple zones, which seems a bit of a stretch.) > including general security analysis, privacy impacts analysis, and > resistance to pervasive surveillance analysis regarding this > proposal * use standard IETF WG process Strong +1 to that. A non-standard process or treating security or privacy as somehow out of scope are both, for me, showstoppers. Cheers, S. >=20 > This is one topic from the long list of proposals. If there are more > that are feasible to be pursued, another working group(s), or > sequential working groups. >=20 > Jari >=20 --------------6E05878CA7C27F0B4ACB229D Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------6E05878CA7C27F0B4ACB229D-- --V8Es2Ztc8Mqtq0qCS73MOYX4xakgJUrOp-- --jRbIti7D2UcEODTsJTc9EM1BqrCkfDSxA Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl3TpGAACgkQWrL68XsX K+qBgw/8CGBJy8A37FdiEj+qLwVjT8cyKxJZufzv+TldkgC8eXX9QcB5PvM2yJTy DCC0FumrUybCSm/esKgzX9MSHog6DHcLuHdUex7YJAZASFkO2Fu8D6zCV6QUsTrK KP78uz50Fa5HjjJ1OhJDJmUOAYkBtSv7ie/rjBcaXjIvwk4oXJY9LTuoNpYlZ0AK n1AGJqzPWvjfZ31QIXFi02uSp9a/CC+K5KIH05TgCA90uc7zFtcjyY0uLrOq72Xi lS/OjvpQDtjh9wfA9cVcfJuWL3sKzH6YBM0e71gfkUinDLCRg5D9VUAqpRtpWcqf Y52ICjk8JkV26Kd2m3M/RD4AsuY9OFmxNdmx9sTltjK8xLKmAqHDqdcR99E5CQ8M 3jCw//qdX5fR4zAEbekXBe2+92V4iRePvJ+T4fyVmDQRtN9tXAWNjyaMJmty1SlI 7Vhawc6RCfEotq/IoaaWI8cn76I+mC7y5gGowt91QxjLYUO3zfM0fuPndzmAD23/ l7K9I5+XK0SZfwl7JXIjcUlvzkEpQY7OuKM7ryx18tViTyr/Dzhfog+CZsnuwoJL DK1zATdV1X4dtkpZpMH7ODg33AxSOgISrEiuLOK6kVkY5BoS3r8bdKPQBHSXpluF dXTTyJ+0DZnVfHfGS3e89Al2sy3QOMjf8Zw+CbL2BUWWaQF+qss= =bPnI -----END PGP SIGNATURE----- --jRbIti7D2UcEODTsJTc9EM1BqrCkfDSxA-- From nobody Tue Nov 19 00:15:33 2019 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 24BFC12080B for ; Tue, 19 Nov 2019 00:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.747 X-Spam-Level: X-Spam-Status: No, score=-1.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 YPiikYeCZvDz for ; Tue, 19 Nov 2019 00:15:27 -0800 (PST) Received: from mail-il1-x136.google.com (mail-il1-x136.google.com [IPv6:2607:f8b0: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 C1EEA1200B3 for ; Tue, 19 Nov 2019 00:15:27 -0800 (PST) Received: by mail-il1-x136.google.com with SMTP id a7so18786171ild.6 for ; Tue, 19 Nov 2019 00:15:27 -0800 (PST) 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=DzqJ0dad5LP54QsaADrtquyQ93rsL8NDyuWeOL9umMY=; b=QoVhF7JSQnxG8rBEjGH9kGaQajNfEn0it/kffzTAT2cIN+EeVrVghVuU+wAxWxPGtt mpLs4a2lIrpfseRbrjNwkHIFrvvUJISCzArkblFCz0q6TR2tw4+R9OdIcZ4TNyBYU9bv f2OVNIMOeQjgZZjrLM3y2HP3RHghxna2CmhC3wM+t9vLdadAnQM+4yYSJVGXYOeldK3E yfA58gHByt52AYFyOgdFqk1MkkT+EBkmLikfRDCpKT3fhnOJJ373yGjZLFWnm+T+eDG8 DJelyscG73ABFSRE4NmJPRX4aJJ04H/Dj+2DF868sa4nNriqlBX+65uC1NsOpidAu/VG XiOg== 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=DzqJ0dad5LP54QsaADrtquyQ93rsL8NDyuWeOL9umMY=; b=Vk6dxKeZMZglAeCNgY2NqlQg5Ni0wewX4UZnFGU9fLgM7E7WT5PYypDhWpR2N1uZvK bU8T9QFpJnTa1FPFuViiElJSDTEJzGpZhwUBb22WGSAi3CZS6lgTgktB+sqV7zMhJKGz XFju8Q7a9dBevTd5qPVfBKXZbLOPG+m3qQVStV+y7KnRWEUL/Yt/K4WeGmLSQtHw4CAg B1GUSh4YJ82xBdRAJ8Y9p9DV2UuRhlwCj2mEwDTac8B+3Dmaa+Bz1N58jr9HhtMVKgau 0jRsHi5auGCAb6PF8fvm1qnN+CpS+n6t5Owm0wxNOy1pNoeS4/b4KXCzxfeWiFBgiXdq lbew== X-Gm-Message-State: APjAAAXKK9fKCu/4P0HXPei0c3EVlNE+yoDMpgfBTv9YkY3UgpvAfqj0 7ll9ymaKVesisSyMFiin0HDSDDS7HRw+iC+PTKS84BOO X-Google-Smtp-Source: APXvYqxnKZ7RB79FNySEfSaueOC3wDDeV2AYNHy3roioUnLCvSyvNsY8DLpRrO3QJXndeJOW9WChlW/xt+dQrSszOxY= X-Received: by 2002:a92:470b:: with SMTP id u11mr19676519ila.59.1574151326837; Tue, 19 Nov 2019 00:15:26 -0800 (PST) MIME-Version: 1.0 References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> In-Reply-To: <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> From: Manu Bretelle Date: Tue, 19 Nov 2019 16:15:16 +0800 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: add@ietf.org Content-Type: multipart/alternative; boundary="000000000000a8b2950597aeaa89" Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 08:15:32 -0000 --000000000000a8b2950597aeaa89 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 19, 2019 at 3:10 PM Petr =C5=A0pa=C4=8Dek = wrote: > > > > > >> How about signaling this through .test domain [0] or similar? The > resolver > >> is not supposed to query/lookup authoritative servers for it. > >> Someone wanting to disable DoH, would be able to return answers for > A/AAAA, > >> NXDOMAIN would mean that there is no intent to disable it. > > Asking for a new special-use name is usually asking for trouble for two > reasons: Getting special-name reservation involves too much politics, and > getting it deployed requires changes in all DNS stacks. Please let's use = a > normal DNS delegation. I am not saying a new special domain should be assigned, but leveraging something like .test, which, to my understanding, is already assigned as a special domain that a resolver should not query authoritative servers for. > We can do this, but it would require changes in the software as nothing i= s > > defined for these. .arpa might be better, but the problem with the > > software is the same. And you can certainly not sign .test, but you mig= ht > > be able to sign something in .arpa. > > > > So long > > -Ralf > Point taken. Mainly if the handling of .test is not already widely adopted. Manu > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000a8b2950597aeaa89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Nov 19, 2019 at 3:10 PM Petr =C5=A0pa=C4=8Dek <<= a href=3D"mailto:petr.spacek@nic.cz">petr.spacek@nic.cz> wrote:
<= /div>


>
>> How about signaling this through .test domain [0] or similar? The = resolver
>> is not supposed to query/lookup authoritative servers for it.
>> Someone wanting to disable DoH, would be able to return answers fo= r A/AAAA,
>> NXDOMAIN would mean that there is no intent to disable it.

Asking for a new special-use name is usually asking for trouble for two rea= sons: Getting special-name reservation involves too much politics, and gett= ing it deployed requires changes in all DNS stacks. Please let's use a = normal DNS delegation.

I am not saying a new special domain should be assigned, but leveragi= ng something like .test, which, to my understanding, is already assigned as= a special domain that a resolver should not query authoritative servers fo= r.

> We = can do this, but it would require changes in the software as nothing is
> defined for these. .arpa might be better, but the problem with the
> software is the same. And you can certainly not sign .test, but you mi= ght
> be able to sign something in .arpa.
>
> So long
> -Ralf

Point taken. Mai= nly if the handling of .test is not already widely adopted.

Manu

--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000a8b2950597aeaa89-- From nobody Tue Nov 19 00:23:26 2019 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 A7FEE1200B3 for ; Tue, 19 Nov 2019 00:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bt.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 p9UJw_vfjPIq for ; Tue, 19 Nov 2019 00:23:19 -0800 (PST) Received: from smtpe1.intersmtp.com (smtpe1.intersmtp.com [213.121.35.75]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1331C1208C6 for ; Tue, 19 Nov 2019 00:23:19 -0800 (PST) Received: from tpw09926dag03e.domain1.systemhost.net (10.9.202.18) by BWP09926080.bt.com (10.36.82.111) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.1.1713.5; Tue, 19 Nov 2019 08:23:15 +0000 Received: from tpw09926dag05e.domain1.systemhost.net (10.9.202.20) by tpw09926dag03e.domain1.systemhost.net (10.9.202.18) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 19 Nov 2019 08:23:15 +0000 Received: from RDW083A009ED65.bt.com (10.187.98.35) by tpw09926dag05e.domain1.systemhost.net (10.9.202.20) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Tue, 19 Nov 2019 08:23:15 +0000 Received: from GBR01-CWL-obe.outbound.protection.outlook.com (104.47.20.56) by smtpe1.intersmtp.com (62.239.224.236) with Microsoft SMTP Server (TLS) id 14.3.439.0; Tue, 19 Nov 2019 08:18:02 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bM6c+q++lbQAiKYQxcVtCNvi/gHNFhiYPbnA0D+JCD4Yr3ulgG2jeLPtgd/1fxrDnF4dSJ8u8sHPA0hwq8PUlciQt8IoAGdl/zMu1MuumE3mqJLnMauJz5nREtKIJXHMAq2AA7/22l5WhFUf2LsqKyqtSwbSzKEVE1JlcnAG99UGQnI1rJplZvlhbBvdTp0U+58HypbXYaeoy4eonDJbYQSbM181/8L7eCbxfepOkB7OqZfK0wyeFx3QfjQBPcy6kGyMzlXtBH/5u1mDpUHwhZKVB8Ldv+jpwhAMjr9KEjjDol3xrLM4xf6aGDg6I66xj3bMpsvfPJEeqBFtvll0cQ== 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=kBzlBcZ4wMraf+w38bDuFTqYDP6azgDbrZzsT8XmWUQ=; b=bi69kyAskA9+ahY44mrZpEp2Pz7FeAbBLbWyUxIB2S/6ZUHKLSWni6dLsoMhOG0DXaHJt0PlVxjDHkPK4f3OEHxgoGGPOF3VcaVn4rqfCUcuiRixnk7NSaZkQp53FcUSatcXXJt1OpAgB3R/FaJVvbFGt/hxj/XG7A7+Cyu8+0wzJo7onT2K5Z2aMgCpXjDzLt1d2310XnOm4GfdOUC0bHYrHCFShMSPblNGClyieRp7Z4o5UmVnS8BKP4YuZwjgRypfvb0IeZO61j0vvjeifU9lhW3eXEE0nFHw7v58hcGuBGvjwoNA1n8vyjJr1f1LrSViS3QbMct/uAvw3NryHQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=bt.com; dmarc=pass action=none header.from=bt.com; dkim=pass header.d=bt.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bt.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kBzlBcZ4wMraf+w38bDuFTqYDP6azgDbrZzsT8XmWUQ=; b=xOcEu9kh2HauWkN90YnkX4tMf+QwDSxpCE1sUwrl2rPBiYKJMilsYibGDDTQIjPipNpCEREdMFW3rNHflrPTpCAwiRdI/qwFDfkCPugJxxiJBRgUCOY3MIhVOClpYZdOCubAcs8dHjSkZ1ck0yhysvsgaydCHNO2vTfYZ2HLveA= Received: from LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM (20.176.158.15) by LO2P123MB1853.GBRP123.PROD.OUTLOOK.COM (20.176.154.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.28; Tue, 19 Nov 2019 08:23:14 +0000 Received: from LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM ([fe80::5483:5ab2:24cf:aa2f]) by LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM ([fe80::5483:5ab2:24cf:aa2f%7]) with mapi id 15.20.2474.015; Tue, 19 Nov 2019 08:23:14 +0000 From: To: , , Thread-Topic: [Add] Narrowed-down proposal Thread-Index: AQHVnqiTVdGCQyLuNki9Cyf2AeJRD6eSJWMAgAABs9A= Date: Tue, 19 Nov 2019 08:23:14 +0000 Message-ID: References: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=chris.box@bt.com; x-originating-ip: [2001:67c:370:128:7583:e672:2ad1:2a8e] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b7f67c95-55e6-4b02-9e52-08d76cc9b8e5 x-ms-traffictypediagnostic: LO2P123MB1853: x-microsoft-antispam-prvs: x-antispam-2: 1 x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 022649CC2C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(39860400002)(136003)(376002)(366004)(396003)(189003)(199004)(256004)(110136005)(296002)(86362001)(316002)(52536014)(66556008)(66446008)(64756008)(66946007)(66476007)(305945005)(229853002)(46003)(446003)(102836004)(7736002)(4744005)(186003)(6116002)(5660300002)(76176011)(7696005)(2906002)(99286004)(11346002)(476003)(6506007)(486006)(33656002)(25786009)(8936002)(71200400001)(81156014)(81166006)(71190400001)(74316002)(6436002)(8676002)(14454004)(76116006)(478600001)(55016002)(9686003)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P123MB1853; H:LO2P123MB2256.GBRP123.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: bt.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 21bRQCLr+ST7PHMAsBgvKcBAwpXcQwEyov62hxc1uYSSntJnksPyCvBss+qh9HWBQtrtEubr7+7RyLPOONFJqvQSYFTPV9r97nDrbO5hka6xTKaYI+o0pe0znBlBU1+IMt9en18cxXG2RVZQ+ijvSsYTxw5HLhGfhUPzJXgqmoFC4GIi1i/ewwLhrdZhU3vC7Y44EeGMS8Ho9fgNCqa2mGSBBhJ4e3DleISeh6htgFQmwipygokYCm0VUUz+d0sN7wnTT/u2lO3xRs+LGlVlR5O0lmMfJIbT7X9bhoaCSi4u6nCdYT0cbSuoac2Dy4BkuFq1z+uMNplaYsS0WTK4fAyhEAMHY1o+vDjqxsBQPgkYJLSuyHtc3s3zv8/d6lU3x8jw0/fWnHXTjcVK3ubeYV8ggZgvHPBO59PO0zDThHUG2W7WmGQz1mRTntNWj6/u x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b7f67c95-55e6-4b02-9e52-08d76cc9b8e5 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Nov 2019 08:23:14.1887 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a7f35688-9c00-4d5e-ba41-29f146377ab0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: yvagYELJ/2itDVpc7u7snVl16yH/qbeRYZzZNABc3k0FUUphtBsO7hfX/OFl899gAl6PHb/n+7mRTNwIzOXs+w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P123MB1853 X-OriginatorOrg: bt.com Archived-At: Subject: Re: [Add] Narrowed-down proposal 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, 19 Nov 2019 08:23:25 -0000 PiBGcm9tOiBBZGQgPGFkZC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgU3RlcGhlbiBG YXJyZWxsDQo+IA0KPiBJZiB0aGVyZSB3ZXJlIHN1ZmZpY2llbnQgaW50ZXJlc3QgaW4gdGhlIGFi b3ZlIGZyb20gbXVsdGlwbGUgaW1wbGVtZW50ZXJzIGFuZA0KPiBvcGVyYXRvcnMsIHRoZW4gSSdk IGJlIGluIGFncmVlbWVudCB3aXRoIEphcmkuIEkgZG9uJ3QgdGhpbmsgd2Uga25vdyBpZiB0aGF0 IGlzIG9yIGlzDQo+IG5vdCB0aGUgY2FzZS4gKFdlbGwsIEkgZG9uJ3Qga25vdyBhbnl3YXkuKQ0K DQpJJ20gaGFwcHkgdG8gd29yayBvbiBBZGFwdGl2ZSBETlMsIGFuZCBpbiBmYWN0IGFscmVhZHkg aGF2ZS4NCg0KPiBUaGF0IHNhaWQsIEknbSBub3QgY2xlYXIgaWYgdGhlICJkZXNpZ25hdGVkIHJl c29sdmVyIg0KPiBpZGVhIHdvdWxkIGFjdHVhbGx5IHdvcmsgb3V0LCBidXQgbWF5YmUgaXQgY291 bGQuIChJIGRvbid0IHNlZSBob3cgaXQgd29ya3MNCj4gd2l0aG91dCBjby1vcmRpbmF0aW9uIG9m IGNvbXBsZXggRE5TU0VDLXNpZ25lZCBjb250ZW50IGluIG11bHRpcGxlIHpvbmVzLA0KPiB3aGlj aCBzZWVtcyBhIGJpdCBvZiBhIHN0cmV0Y2guKQ0KDQpJdCBmZWVscyBmZWFzaWJsZSB0byBtZSwg YW5kIGhhcyB0aGUgYmVuZWZpdCBvZiBlbmNvdXJhZ2luZyBtb3JlIGRlcGxveW1lbnQgb2YgRE5T U0VDIHNpZ25pbmcuDQoNCkNocmlzDQoNCg== From nobody Tue Nov 19 00:37:43 2019 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 D25DB1208B7 for ; Tue, 19 Nov 2019 00:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 isNvsNCeSye4 for ; Tue, 19 Nov 2019 00:37:37 -0800 (PST) Received: from mail-io1-xd43.google.com (mail-io1-xd43.google.com [IPv6:2607:f8b0:4864:20::d43]) (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 17DE1120041 for ; Tue, 19 Nov 2019 00:37:37 -0800 (PST) Received: by mail-io1-xd43.google.com with SMTP id k13so22207466ioa.9 for ; Tue, 19 Nov 2019 00:37:37 -0800 (PST) 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=+3KRyJTnEjgoIX+IYAip8hZaO15+luCXYoKNXbXajnA=; b=YW8ldZxSudP8/kQeVH/VE1VXZiM7UXuvwyO2Ncz8UnCV65/KSYmHMLL0nHvKl42Q6w m3jIbyhnAQUy7q0LkpNUXwktv4rhI7HFgWow2p7Zu/99UEu1FXLXGVuNLf+PtljpOX9r LuO/dBVWDhLj6q8TDZFmh5W0330MTyN7Cnfs9oo9Rs3s3gGcNXEO7uexRMtfNuNEzQc/ CgfuVYgrAmJlWTbXIiiQdRoWzpPYrpbsc4dvv6gvHUssypqDRnPxekOmzyKIWzDzEO/U aC96sZ5/TS8AMkVWvPQkozrOrhpjP4LoaBhVG13ipDU5omeIVgl5EN0fdT5DorMhdw8j flEQ== 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=+3KRyJTnEjgoIX+IYAip8hZaO15+luCXYoKNXbXajnA=; b=Sl5Wb6KrTfzmV/Q1SlJmHqrbmrXCtsUnqPeQQWLbPHCtEdB9fBkpavdwmVaY3IM2ZZ qMQww7ql9axE0vn/PpKFbzXQIRfarjDlEQolFIsKRL5h37EA1pXhLd3jZwNR/6UU+s9M +7cQpiu6/bodohvEBVjulu+V3N8gie6Gka7uNsFcXdqgEuEItZ2Ercg8ibtnXdRbLZA7 xht8M9IPWDA5mpiw8I7U9ldwow+qYiSNFNw+6r4eg1Uhb2EPDh4cFHMf3vRfLtauG1bT vIRp6IJPnmEHyy66f28EXd/gbffn6NQe0yCELXQu4Uf08vZVm6NQLcRtHJrIBBIbWwHS lGOg== X-Gm-Message-State: APjAAAUKxWDYsyTnS7J8asmZpHqKZ0kZSsuvy35H4CvOP9L4gtXTyJi7 4eoDPMKx3QFOoV+gOG4RTIdw2RFL7fnzQnZLWN8= X-Google-Smtp-Source: APXvYqyYtGmBxt4Anr+2tW7484pDmmshTUg4ksjVQXBCm4OofDNikmzrWyFTmejYqgg6sWogC3xv0aDo0HCobwjTdqY= X-Received: by 2002:a02:9307:: with SMTP id d7mr16204385jah.103.1574152656095; Tue, 19 Nov 2019 00:37:36 -0800 (PST) MIME-Version: 1.0 References: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> In-Reply-To: From: Rob Sayre Date: Tue, 19 Nov 2019 00:37:25 -0800 Message-ID: To: chris.box@bt.com Cc: Stephen Farrell , Jari Arkko , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000e393060597aef9b6" Archived-At: Subject: Re: [Add] Narrowed-down proposal 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, 19 Nov 2019 08:37:42 -0000 --000000000000e393060597aef9b6 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 19, 2019 at 12:23 AM wrote: > > It feels feasible to me, and has the benefit of encouraging more > deployment of DNSSEC signing. > That's been encouraged for about 20 years, right? "Though Domain Name System Security Extensions (DNSSEC) offers a means of ensuring that results are accurate, the protocol is not thoroughly implemented and deployed. Even where DNSSEC is deployed, many Internet users rely on their DNS resolver to perform validation." https://www.iab.org/documents/correspondence-reports-documents/2019-2/avoiding-unintended-harm-to-internet-infrastructure/ thanks, Rob --000000000000e393060597aef9b6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Nov 19, 2019 at 12:23 AM <chris.box@bt.com> wrote:

It feels feasible to me, and has the benefit of encouraging more deployment= of DNSSEC signing.

That's been enc= ouraged for about 20 years, right?

"Though Do= main Name System Security Extensions (DNSSEC) offers a means of ensuring th= at results are accurate, the protocol is not thoroughly implemented and dep= loyed. Even where DNSSEC is deployed, many Internet users rely on their DNS= resolver to perform validation."


thanks,
= Rob
--000000000000e393060597aef9b6-- From nobody Tue Nov 19 00:39:03 2019 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 DBFFB1208B5 for ; Tue, 19 Nov 2019 00:39:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ni15kAQs8SM3 for ; Tue, 19 Nov 2019 00:38:57 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AB0D1208B9 for ; Tue, 19 Nov 2019 00:38:57 -0800 (PST) Received: from dhcp-8a04.meeting.ietf.org (dhcp-8a04.meeting.ietf.org [31.133.138.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 4C3AA2421173; Tue, 19 Nov 2019 08:38:55 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> Date: Tue, 19 Nov 2019 08:38:56 +0000 Cc: add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 08:39:02 -0000 > On 19 Nov 2019, at 07:10, Petr =C5=A0pa=C4=8Dek = wrote: >=20 > Asking for a new special-use name is usually asking for trouble for = two reasons: Getting special-name reservation involves too much = politics, and getting it deployed requires changes in all DNS stacks. = Please let's use a normal DNS delegation. It was pointed out at the ABCD BoF -- don't know if you followed that = Petr -- that it would be a lot easier to put a canary domain under = .arpa. From nobody Tue Nov 19 00:46:17 2019 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 E2655120BC3 for ; Tue, 19 Nov 2019 00:46:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.997 X-Spam-Level: X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=nic.cz 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 G8TLrhQu3lbX for ; Tue, 19 Nov 2019 00:46:10 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 DF9B7120B78 for ; Tue, 19 Nov 2019 00:46:09 -0800 (PST) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2a02:8308:a13e:40f0:4812:72ae:d39e:e874]) by mail.nic.cz (Postfix) with ESMTPSA id 725341408AC; Tue, 19 Nov 2019 09:46:08 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1574153168; bh=6qduMWE35yiV7WSBBLBjM8ju0GpJjDgD+fV84Uxsp2M=; h=To:From:Date; b=TZNghW4rxEp64vo2uXiRQY7Rvr3nCVCoagvjOxceAMo5jcUligkSwMxlpTrQj1dWy RSln2bUR/hV3/9kxjk7+2/jeEU3VZ1ut4VpA6q0D+z7w8Q2DljH6yaQo6sB7r6xVhe mmonmIda6mUqUsCKwxQNowEXukmn5Kl0kA/1xn+U= To: Manu Bretelle Cc: add@ietf.org References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAlwQ5d0FCQWnguAACgkQzo3WoaUKIeR/ wQ//c16RhWSNICjuHhdQjJADBdzivZepVBRGsDo1Bau4A+p05iznv8REWIGVfCAAShsH/02h cT2dIoxPzJ/avK4WiDoYLzycLs5nw/eodsUIYxvNcerDNLiBbBP/stSCfPy3oX055mHxTP8P d9rhiHfgWq0dmY58r9tEz00DeP9u/UIMMpY3EXih+wsHSW2l6sXgUMDAPly8MeH0vqmrcp7Y 2/zcOJGH5gGv+KTsXVV4p6Q3h2HgJfRA+q7KCu5P32XswRJZVAiHzwsC+w+jmrtaU+gTQR2B 72m7lfkmct/5I5xAG/QcaoM3pnY/x+eNL4vJ99uK3axdm8b02y+zYqgxVlqDpwXT8cI7B0k4 V9XISZyRn4024YS9ljO2ytV45n4nedzImpqnjBVDura59m9l70aPqyF5O6Sk8IhhW1vhue4M NJnmwmZaY+p9AcB6J9PjEKTZdlpBYoaFbca+r/X0uJtN6P1s/ZJstptji3M84p/g0BnHsGXM vuvpFN3lJUIQXWvf6eZGuvWLVVeAE/vYoz380B7eIbVaNhlbZ8wnSq77atiwjttyCf4LqTBk 4nV+RsJzbS3IUz6MOg5gaet6dJHQ6tMwUOcne74HofWaoXdH0HkmaTh83mKdWjRJlwBnelzT 0ogYWv8CRr7G/I6LQ/WUx0VOmaae9oBdTVCozM+0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAlwQ5eEFCQWnguAACgkQzo3WoaUKIeTE3BAAsXJDtGuCF/Ssz0Y3 b6SA/3ZC+i3bWHz8l7dtFO+gvKFhRdwAxGY4NlD/QSyMTEVz6lHCf4TQYPZOmKisOdEyklgS Yep6dgYitnlMTSUfDC7R+L9fd68NjiPrw4WWKblDr7ukc6VlZpGxKblPpuVLAho0MVi0GEjR fVldMaptchQEW4bGiWj/ESBSR4PL7oPhHzJPXsJMeS4Zhit9RiegFOuPfExWKX+U0yJ69qSU AvyRE1WXQi3gzxXMdPIR0yrukbQInQJ9TwI6LMKy7j7PLx2zExUTRK6GO7TktKwKVn1fVyzF Ir0eMqr5MbUfHapyIUdEHWoLaY0i9ZObXQaSPi0tNZwmneTZbK/7UrawsXGt4Y7BvHS5Hte0 ggFOKJkCJWyMEfQPf2obZkvP5smRC+VMNlC5fOwxLnXBE69NXE9hxdenTr2E43b79Colqyak 4eE7J0aQHe6iQDRyuq8w6cr4Ry54pBCym90saIUt58k+4zxVXJH18VliOdfa98ZlsT4zFjzA biYNuGDGxQ5EAS01Qf8bR29O/rp/MqmXmr0Yhmzt6X7UhTfXDsqK+BLt+xZw6x3OrgrNnM0F Em0QOjFfhv2VDw/q20yU+Ls+dD6I3Q5TEpKcCcpCKoowVE7XMfba+fuKIXgkw7fb//QdymzJ XygR2MORImwVGcN8tba5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXBDl9wUJBaeC+gAKCRDO jdahpQoh5OD7D/0bKnkRwHgChHe8pXE/RICHXMGF6vduH24ZopMBa3T7S/x/JlgYQ+pmv//2 uSh0+ddtCev2iDOMmZmmw+8Y/JFmKRaNgjCR8zZVvgELKvnBD3770oGShvnMJCZTDajuz+Ah KkWwILkHR5i6wCtUOesLKuujJrFs3oylRvmXNUwQ4LNiWO12s9EBc8sUpGbeKMtXRFxg/Mkl U49XkTNR8K0awZNddEj1j07/uUVon6JafDKCj9eiLQiAEe84CP0andDQFj6wjpGDOb11t12b yBgnj4WN9mK8jt9t19K5tNa+u0WYV0ei8g8lgu9cruFQbbbDDgKd4gUPihlJXL3FSiol/SpA 2u7MSpOvvLuVtkjPGA8JJWYfSOmAnWmjpEtomWU0D5mSU5Dvp8IyJoPnJC4mW7APnD5pw9ZN uZlfoOKMYc9lKPN5SSIwpy1hJGpVSjomYrR2DDCbeXX86tvgPdiwtU9ANrhmsJ9KV2sYLfOQ QnyIJVJhDCVzQl8jHKfwLcsvFOg9h4W/9tBN4NgGNpXtrRJD/EpR2mBEXOsavGPsIzZYdynE ItUrRqChu5Q7thei58dEzrLSt8zBPXRtoOOH6EsoyyHFOqw/nmVa+0xKV5IaOF5VOJkKFveM rStQ8ILhGDeANMRCym0LdOA3jw+0umaGw1zgk+brjOWut4idlA== Organization: CZ.NIC Message-ID: <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> Date: Tue, 19 Nov 2019 09:46:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-PH Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz X-Virus-Status: Clean Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 08:46:16 -0000 On 19. 11. 19 9:15, Manu Bretelle wrote: > > > On Tue, Nov 19, 2019 at 3:10 PM Petr Špaček > wrote: > > > > > > >> How about signaling this through .test domain [0] or similar? The resolver > >> is not supposed to query/lookup authoritative servers for it. > >> Someone wanting to disable DoH, would be able to return answers for A/AAAA, > >> NXDOMAIN would mean that there is no intent to disable it. > > Asking for a new special-use name is usually asking for trouble for two reasons: Getting special-name reservation involves too much politics, and getting it deployed requires changes in all DNS stacks. Please let's use a normal DNS delegation. > > > I am not saying a new special domain should be assigned, but leveraging something like .test, which, to my understanding, is already assigned as a special domain that a resolver should not query authoritative servers for. The problem with special domains is that ... their are special/for a specific purpose :-) Most importantly RFC 6761 does not mention forwarding which makes it difficult to rely on "test." domain behavior. I would expect that "test." domain would not work on organization level because the "first hop" resolver would generate NXDOMAIN, without forwarding the query to the central resolver, which would make centrally-configured answer unavailable and so on. Simply I do not see sufficient benefit in exploring this special-domain rat hole, normal domain should work for this purpose just fine. Petr Špaček @ CZ.NIC P.S. This probably boils down to non-standard nature of forwarding, which practically means that half of DNS resolver behavior is not explicitly specified anywhere. > > > We can do this, but it would require changes in the software as nothing is > > defined for these. .arpa might be better, but the problem with the > > software is the same. And you can certainly not sign .test, but you might > > be able to sign something in .arpa. > > > > So long > > -Ralf > > > Point taken. Mainly if the handling of .test is not already widely adopted. > > Manu From nobody Tue Nov 19 01:10:14 2019 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 327B1120096 for ; Tue, 19 Nov 2019 01:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.379 X-Spam-Level: X-Spam-Status: No, score=0.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=1.355, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, 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 iER9_K97ZlSu for ; Tue, 19 Nov 2019 01:10:04 -0800 (PST) Received: from mail-vs1-xe42.google.com (mail-vs1-xe42.google.com [IPv6:2607:f8b0:4864:20::e42]) (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 AFFC01200A3 for ; Tue, 19 Nov 2019 01:10:04 -0800 (PST) Received: by mail-vs1-xe42.google.com with SMTP id y23so13703393vso.1 for ; Tue, 19 Nov 2019 01:10:04 -0800 (PST) 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:cc; bh=UT4TXzJv1bNGbSjaWZi6gfYk9MbuLAHa3b4pWaP/xAY=; b=JETaGNdIqU4aVDkjd7Vaj4Y30BIIi4Z7QoSFQVhIqA0+7799vIQ8ar3ygmWqFmCpOM +MvfrT556J99XKG2adofYCQTmHc6FYG7gDpmoVGhviRVXIN8qOxnMWud9Blp7O8AcwUj P58uH6PW6LWYjZbgVcnKJvcAQBos6HnIlw7wLK5j6NpV55lGxGCFacflc1DSH1n3E4tY hYXEZa4EBAFTvk25X9+UrGlPyYUylreR7kw4DsGW83HZiVnWhYMX9NvHujmbKcnRqd6s esdsHWYxONCvK26jsIVhVIgpJoD0rDmlvdizWsO76NKfhHC11ydJIp9zUzJ5EnbK61Bb 5Zzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=UT4TXzJv1bNGbSjaWZi6gfYk9MbuLAHa3b4pWaP/xAY=; b=OHNklGkSnCSYNyG6iRCb0UsOURQrQBrjnMZfLDlAHwM9cfkUCGyopxi0thvpfkSQyN tn36H7kjRcWKAo1KI4/zLpRkF38x48v7xCqz9KF9J1C55tLXTVkrh/M8sQuT8LX2k1FM ADhnfctGY/N5WRXHMghIM5xbdoLmGSLgYDZMm6+rO6fJVgZufOtcCz7SSbFN//wJ7/Lk rjX9mt65qw7NbnfHTxNDn9ZSmZyVbuTiXT3xLGU+xrqE1F403V5S2nJ5ZweAPqBZ6rxc +aF+s1duwg4C20WcBDLMGxRXk8O0SIlQKcr6b1F0TTUxPFcHGw6kZEIolV8lElI1UpoH ZZkg== X-Gm-Message-State: APjAAAU6lkaUP7juaMvvdAecdPKzEaQWw9aXOXdKkq3yRkeiYJElEjjW JqOI0w926skNAfteFrpV5g5mYVUTDwCI724k2xc= X-Received: by 2002:a67:db10:: with SMTP id z16mt18849897vsj.5.1574154603642; Tue, 19 Nov 2019 01:10:03 -0800 (PST) MIME-Version: 1.0 References: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> In-Reply-To: From: Brian Dickson Date: Tue, 19 Nov 2019 17:09:47 +0800 Message-ID: Cc: Jari Arkko , ADD Mailing list , dns-privacy@ietf.org Content-Type: multipart/alternative; boundary="000000000000fb26fc0597af6d64" Archived-At: Subject: Re: [Add] Narrowed-down proposal 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, 19 Nov 2019 09:10:09 -0000 --000000000000fb26fc0597af6d64 Content-Type: text/plain; charset="UTF-8" On Tue, Nov 19, 2019 at 4:23 PM wrote: > > From: Add On Behalf Of Stephen Farrell > > > > If there were sufficient interest in the above from multiple > implementers and > > operators, then I'd be in agreement with Jari. I don't think we know if > that is or is > > not the case. (Well, I don't know anyway.) > I'm very much interested in working on the "Discovery of resolvers and their capabilities and behaviors" item and the "Support for debugging and analysis". I have some ideas that might combine those two through mechanisms that support both use cases, so it might be possible to reduce the list of items by one. (This may lead to an actual "DNS traceroute", BTW.) I'd prefer to work with 2-3 co-authors to ensure progress and good collaboration, not more and not fewer. Please contact me off-list if you are interested, presuming (a) WG formation, and (b) WG chair approval. I'm willing to contribute ideas and review the item "Local DNS caches (e.g. partitioning, use of stale records)". (I think that one is particularly important, and important to get right.) Brian --000000000000fb26fc0597af6d64 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Nov 19, 2019 at 4:23 PM <<= a href=3D"mailto:chris.box@bt.com">chris.box@bt.com> wrote:
> From: Add <add-bounces@ietf.org> On Behalf Of Stephen Farrell
>
> If there were sufficient interest in the above from multiple implement= ers and
> operators, then I'd be in agreement with Jari. I don't think w= e know if that is or is
> not the case. (Well, I don't know anyway.)



I'm willing to contribute ideas and review the item "Local DNS caches (e.g. partition= ing, use of stale records)". (I think that one is particularly importa= nt, and important to get right.)

--000000000000fb26fc0597af6d64-- From nobody Tue Nov 19 01:12:54 2019 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 2C3B1120096 for ; Tue, 19 Nov 2019 01:12:53 -0800 (PST) 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 HU1Z0LA_3HyZ for ; Tue, 19 Nov 2019 01:12:48 -0800 (PST) Received: from mail-qk1-x735.google.com (mail-qk1-x735.google.com [IPv6:2607:f8b0:4864:20::735]) (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 86A4A1200C1 for ; Tue, 19 Nov 2019 01:12:48 -0800 (PST) Received: by mail-qk1-x735.google.com with SMTP id z16so17137738qkg.7 for ; Tue, 19 Nov 2019 01:12:48 -0800 (PST) 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=nVpD7RLXj+SVoazs8VZocntiI1WBFIZgakxo3N7lDoQ=; b=oTmbFmHMZpyl0He72iRN5c54oJoTZNuwufboCJEOzn/l9I7Qj+KguFwWmBDvXFHtoj QULbzyNlnJLfY91HHG3eo6vsnAZGrjgsyS5MpmTGzBD0JWUeBLRiuQdxuIbIbjVQ8jRp +hjAE1B/Ur3NiKyMZ/cwopfaCb2Gnym+4NuLTe5zxiO9cDep4GeCbWY+i+drXNJsWx9A vnmHGhFT0kUjpSOahrs4tRQ8WcALDvOf1i8GYCBzNe8BgSpftZv6XsLlNh/I02alCRNL CvrsA9G+XKRBU2zQaXqYRuAKuopj/YEHWFaTmb1fC7Ca7gMoYdap4Ij2ec6Q/7017082 3YDw== 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=nVpD7RLXj+SVoazs8VZocntiI1WBFIZgakxo3N7lDoQ=; b=NXNnmzESo6iN1797PRWm1Fw70k5CM5pkwER4tcAmJxqsXrHqzWUge6IeNYr+dGoYAv nMsAK0+Mv97EYY3v8aPGyBxxHPNOOMjn8iGSytTli4/iJTvS2mjS1qNmrv2X1N+VNtR+ g3nU3dIUt9fzCAugWVgEK0/GVZarYJJVJXH5R+NyEEIPdalzb/s+U8lqRWR6pMjfGB64 gDL/VZl3hfBgRUPcD6BHuhQfEnJcqNtaAVReuymKw2v4inOSrEr0OANmyW5rNWxdYRhM waArtolO5wkVfXM0HDh9udDEmmWNi+1aZf/X0XLEuk+O/jS9G9eu0unz5j4Ddmw1wuf8 7OBg== X-Gm-Message-State: APjAAAUpUIEeMgZTEfOl11L0P98TSlJnjryFxJHlhNrtL/K9/oqpEGv4 LQMYb9FC/NxzwhFLqmG20eUbTg== X-Google-Smtp-Source: APXvYqzBb0UwbudShxzyVuySQDlYTyntkw0ryTTXZLCqHacilyIYMcf2mEHV5lWK1eD2v37dB3SBDw== X-Received: by 2002:a05:620a:13dc:: with SMTP id g28mr20039793qkl.180.1574154767463; Tue, 19 Nov 2019 01:12:47 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:805d:2d9b:9110:b73e? ([2601:18b:300:36ee:805d:2d9b:9110:b73e]) by smtp.gmail.com with ESMTPSA id r29sm12401508qtb.63.2019.11.19.01.12.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2019 01:12:45 -0800 (PST) From: Ted Lemon Message-Id: <29B6B33A-6099-47AB-8DAD-C6CE94AB5898@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_28812945-E6DE-4E33-ACE3-05EC47A10EC6" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.1\)) Date: Tue, 19 Nov 2019 04:12:40 -0500 In-Reply-To: <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> Cc: Manu Bretelle , add@ietf.org To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> X-Mailer: Apple Mail (2.3608.40.2.2.1) Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 09:12:53 -0000 --Apple-Mail=_28812945-E6DE-4E33-ACE3-05EC47A10EC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 19, 2019, at 3:46 AM, Petr =C5=A0pa=C4=8Dek = wrote: > Simply I do not see sufficient benefit in exploring this = special-domain rat hole, normal domain should work for this purpose just = fine. The problem with normal domains is that their registration is not = permanent. --Apple-Mail=_28812945-E6DE-4E33-ACE3-05EC47A10EC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 19, 2019, at 3:46 AM, Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> = wrote:
Simply I do = not see sufficient benefit in exploring this special-domain rat hole, = normal domain should work for this purpose just fine.

The problem with normal domains is that their registration is = not permanent.

= --Apple-Mail=_28812945-E6DE-4E33-ACE3-05EC47A10EC6-- From nobody Tue Nov 19 01:36:48 2019 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 018B412080A for ; Tue, 19 Nov 2019 01:36:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, 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 ZzKi76HEpKb6 for ; Tue, 19 Nov 2019 01:36:42 -0800 (PST) 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 3B5791200B9 for ; Tue, 19 Nov 2019 01:36:42 -0800 (PST) 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)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 14C5C6A230; Tue, 19 Nov 2019 10:36:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1574156200; bh=DZA4xMAeC7SzVQN/KT7RpKcwcNYf7VxTJydo8PmS0Io=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=pbH2a7rRrTRae5JhzOmilRHAroUKiscpB9x9k3zXMxDYe+NkmoNZahu6fgRG61R18 VvjAMPDL0wSquClB1JMiF4G5AeLOuc7g7ItJbJiqhmvmEsGd4AfHR4oVV+ZIvHUbha lF3/vYM6pv1OdY0AQYcwtKEwpb2IEkyRfPGCFaXb77HaO4VoI6d7aIbT0PRRdGZILb 8pto6sWw2FwbmxN+dyyght8fxRwwBfVZERAzZSAvmzfJp91gZPrei3bXtf52lw17IO josueyw+DrVUValwm3IdGXHIdMceggFU1KL97jThTAVEkh9TXgAqahjsBwxnTFiHjS g9UmbuEI32y2g== 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 08EA73C0269; Tue, 19 Nov 2019 10:36:40 +0100 (CET) Date: Tue, 19 Nov 2019 10:36:39 +0100 (CET) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Eric Rescorla , Jari Arkko Cc: ADD Mailing list Message-ID: <860963384.10682.1574156199943@appsuite-gw1.open-xchange.com> In-Reply-To: References: <24018.43148.463202.630086@gro.dd.org> <71B3E16B-6B70-4B52-B0C4-BB2890CBBAFA@fugue.com> <24018.45797.55312.687430@gro.dd.org> <02F33997-B8D5-4654-A624-842A184A161E@gmail.com> <24019.15782.928519.38360@gro.dd.org> <46410E79-B010-4901-9D86-B024D1DC52ED@cable.comcast.com> <999534B6-41F6-49E8-8988-D5C6AF05013A@piuha.net> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev17 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] Agenda and Revised Charter for the ABCD BoF 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, 19 Nov 2019 09:36:48 -0000

Il 19 novembre 2019 06:29 Eric Rescorla <ekr@rtfm.com> ha scritto:

I feel like I'm repeating myself, but we are already in that world to a great extent. Roughly 10% of DNS queries go to 8,8.8.8 right now and in many markets (e.g., the US, but not just in the US) Internet service provision is dominated by a few large providers.
For those that have not seen them yet, I recommend APNIC's great statistics at https://stats.labs.apnic.net/rvrs . You can use them to get an estimate of how many people use their local resolver ("sameas"), another resolver in their own country ("samecc"), or the various global public services - and you can break the data down to country level.

Now, how much "sameas" is concentrated likely depends on how much the Internet access market is concentrated in the specific country, but still the ISPs generally differ country by country, so seen on a global scale it's way more diverse than the global operators, that are the same in every country.

By the way, this is also useful to measure the potential "jurisdiction shift" effect of some deployment models: e.g. in Europe, today ~90% of the queries (sameas+samecc) are served in-country.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
From nobody Tue Nov 19 02:05:09 2019 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 8CCCF120BA2 for ; Tue, 19 Nov 2019 02:05:00 -0800 (PST) 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 9d8yOoOOh13s for ; Tue, 19 Nov 2019 02:04:55 -0800 (PST) Received: from pigeon.groveronline.com (pigeon.groveronline.com [198.145.19.6]) by ietfa.amsl.com (Postfix) with ESMTP id CBA6A120813 for ; Tue, 19 Nov 2019 02:04:55 -0800 (PST) Received: by pigeon.groveronline.com (Postfix, from userid 501) id 3BF33608E3; Tue, 19 Nov 2019 02:04:55 -0800 (PST) Received: from [31.133.146.41] (dhcp-9229.meeting.ietf.org [31.133.146.41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pigeon.groveronline.com (Postfix) with ESMTPSA id BE53360413 for ; Tue, 19 Nov 2019 02:04:53 -0800 (PST) To: add@ietf.org References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> From: Andy Grover Autocrypt: addr=andy@pmtu.dev; keydata= mQENBFz6mPMBCAClDMGqYBeCSE0Q+rU7v0JibtGh+nSZoNTSdXOHUkk3rN7rmJwdjlWsL0aT 2BGsSYBQjuqlculeJAQq6GG8dj7gjkDX8zVvjNPVqZxNd0bRh9DFE5AZrz3TiTIUwNauKWE9 XvVCMn/ZfzEJhehLa7SUs5vgZ6NHaScq4KZByfNsmiu/n+mPRhJOjgIN7fql5u+ElnNHxOP3 Z9vsoQc5pS9YAMKtEvyWgljm4fbZMs6VBDUGJGaLRmALF5VrJ5AJKzbZWZmaXYNqoxdtakT5 PhJuXkqdnrijZw8TJCglQ/z2wiq2HCU2pzq6/l+19yV0m9iegEuPgtAuwqkh4ecsPAbbABEB AAG0IUFuZHkgR3JvdmVyIDxhZ3JvdmVyQG1vemlsbGEuY29tPokBVAQTAQgAPhYhBKVh7hV4 1gY7lZbAkBVqKb2tr6NBBQJc+pjzAhsDBQkDwmcABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheA AAoJEBVqKb2tr6NB7uwH/RIEtXUCpRGCbVO5LyXmlzTCue9djrb8YrvOOyeVzUxA5kIskguB 5DH7X7RuVa1PlsfsG2F40/5/bPS/fjYIUOGxTQdyiXGeVPotDvg4vaC/3zV16gs8YxOgzKgb P7QhFLHkZoITe6gOv4R0QH1qvRkbg9cyyPr5FoIPaLoXDnw4DWxaNBUSsN+fPRI87yUjPO1v kL+OWBOnBsHxNGaHjd/s9WsIUp8RbLbfMEI+xlM8lM+r5ccECkMS/l9NFX+mCMUlRXqTkd49 mWYJWY5zNnLyqbAZcaRGCrFlX/gjDn8p+pXQEdvtbbqy3KMofxrmf73ECSStM0WnOEgWtSFG ycW5AQ0EXPqY8wEIAMY7xc/W7mIt2nyAe9K/5RiuyGaDItuaEbFzfRmxFvISJm3s5LiyyrGA 82o0HQWqoMjPyLd+pGSSxHL5aWCUsj5vt/rV0FCPvC8W3a0bWxHa+sbb0VeAHna18Ozav1Cx RFLW437tqaD8yF5yh1c0aGolCqv2LjMHetm+UmFoQVbSfcJoxpXepJFVDwvrqqlL+5BoQM15 MzCwux/D8RCgNlTXTnlfm6bRvlD5ttgDoyzN7qYwm+RjA9Izhyps39fKzdk8xkgeu/A55C94 KcPuSs4U9ti7WeU+CubDaLB3bxp7KCyjWpX3oS2CxHFnQsBAbzGx8UeH3dXbdni1AjE71wkA EQEAAYkBPAQYAQgAJhYhBKVh7hV41gY7lZbAkBVqKb2tr6NBBQJc+pjzAhsMBQkDwmcAAAoJ EBVqKb2tr6NBP2MH/0g/e3idsu/ajGzRx6CaRd/ZNxG0/p0aYT4iQWUEt0KZVyHKf17OQK2z u3QSGjSR2V1H419U0m5V3HSMQmy5XrGi3ks4f01Cgq2HiYizhwVwqNVfZERY+WavEIr35w/L eJqEI2Cm4PySxbOOuFig6R7GAknL76iKQBlMH8uX7yV9p0JnrI6tn0lm2n4UjW76CJ3Fk6gD wqoDYDQXfIxYtyMD6QUfiSDZ+8KZoCMDYQQsEcDBz0hRI2mHwL1jHkGNMcVOhBZPtUHinFTc EiQKDXQKkBvschbpbcfJI5g82v6Bl5M995ob7wsXy8VN5+usot+bKqQHGYMsBMbqJf+Ci1I= Message-ID: <250d4aae-a6d3-ea09-fb62-8974418318fa@pmtu.dev> Date: Tue, 19 Nov 2019 18:04:50 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 10:05:04 -0000 On 11/19/19 4:38 PM, Jim Reid wrote: >> On 19 Nov 2019, at 07:10, Petr Špaček wrote: >> Asking for a new special-use name is usually asking for trouble for two reasons: Getting special-name reservation involves too much politics, and getting it deployed requires changes in all DNS stacks. Please let's use a normal DNS delegation. > > It was pointed out at the ABCD BoF -- don't know if you followed that Petr -- that it would be a lot easier to put a canary domain under .arpa. > Agree .arpa could be a good fit. There's already precedent with ipv4only.arpa, in rfc 7050. If the logic is "resolve success means no canary" then should not be required changes to DNS stacks. Only resolvers wishing to indicate local policy would need to be configured to modify the result for the canary domain. -- Andy From nobody Tue Nov 19 02:53:07 2019 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 2FBF0120922 for ; Tue, 19 Nov 2019 02:53:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.997 X-Spam-Level: X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=nic.cz 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 eYLJypkuO9dy for ; Tue, 19 Nov 2019 02:53:04 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 AD2AE120903 for ; Tue, 19 Nov 2019 02:53:03 -0800 (PST) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2a02:8308:a13e:40f0:4812:72ae:d39e:e874]) by mail.nic.cz (Postfix) with ESMTPSA id 38DFE140CE5; Tue, 19 Nov 2019 11:53:02 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1574160782; bh=cIdv4ph0f+wUG7/jFVCUcrfNaVGQZbrONMTJgjCTK5Q=; h=To:From:Date; b=mzjDavAxPLuutM7GjE6WHhDNZtD1kNJEBdfApLq+iM9DTGhQKgLB/4+8YPGYlBhxE 4MeA6gAaWuuNdHLk83UaybHCyxsaqxN1UGB6vb8QWCcnmM+RLm3fmkaYfNwXWLXO0C zkq8fODjrpPjTGXdVGuf+/MGmw1cTcoQyWUVK4bw= To: Ted Lemon Cc: Manu Bretelle , add@ietf.org References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> <29B6B33A-6099-47AB-8DAD-C6CE94AB5898@fugue.com> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAlwQ5d0FCQWnguAACgkQzo3WoaUKIeR/ wQ//c16RhWSNICjuHhdQjJADBdzivZepVBRGsDo1Bau4A+p05iznv8REWIGVfCAAShsH/02h cT2dIoxPzJ/avK4WiDoYLzycLs5nw/eodsUIYxvNcerDNLiBbBP/stSCfPy3oX055mHxTP8P d9rhiHfgWq0dmY58r9tEz00DeP9u/UIMMpY3EXih+wsHSW2l6sXgUMDAPly8MeH0vqmrcp7Y 2/zcOJGH5gGv+KTsXVV4p6Q3h2HgJfRA+q7KCu5P32XswRJZVAiHzwsC+w+jmrtaU+gTQR2B 72m7lfkmct/5I5xAG/QcaoM3pnY/x+eNL4vJ99uK3axdm8b02y+zYqgxVlqDpwXT8cI7B0k4 V9XISZyRn4024YS9ljO2ytV45n4nedzImpqnjBVDura59m9l70aPqyF5O6Sk8IhhW1vhue4M NJnmwmZaY+p9AcB6J9PjEKTZdlpBYoaFbca+r/X0uJtN6P1s/ZJstptji3M84p/g0BnHsGXM vuvpFN3lJUIQXWvf6eZGuvWLVVeAE/vYoz380B7eIbVaNhlbZ8wnSq77atiwjttyCf4LqTBk 4nV+RsJzbS3IUz6MOg5gaet6dJHQ6tMwUOcne74HofWaoXdH0HkmaTh83mKdWjRJlwBnelzT 0ogYWv8CRr7G/I6LQ/WUx0VOmaae9oBdTVCozM+0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAlwQ5eEFCQWnguAACgkQzo3WoaUKIeTE3BAAsXJDtGuCF/Ssz0Y3 b6SA/3ZC+i3bWHz8l7dtFO+gvKFhRdwAxGY4NlD/QSyMTEVz6lHCf4TQYPZOmKisOdEyklgS Yep6dgYitnlMTSUfDC7R+L9fd68NjiPrw4WWKblDr7ukc6VlZpGxKblPpuVLAho0MVi0GEjR fVldMaptchQEW4bGiWj/ESBSR4PL7oPhHzJPXsJMeS4Zhit9RiegFOuPfExWKX+U0yJ69qSU AvyRE1WXQi3gzxXMdPIR0yrukbQInQJ9TwI6LMKy7j7PLx2zExUTRK6GO7TktKwKVn1fVyzF Ir0eMqr5MbUfHapyIUdEHWoLaY0i9ZObXQaSPi0tNZwmneTZbK/7UrawsXGt4Y7BvHS5Hte0 ggFOKJkCJWyMEfQPf2obZkvP5smRC+VMNlC5fOwxLnXBE69NXE9hxdenTr2E43b79Colqyak 4eE7J0aQHe6iQDRyuq8w6cr4Ry54pBCym90saIUt58k+4zxVXJH18VliOdfa98ZlsT4zFjzA biYNuGDGxQ5EAS01Qf8bR29O/rp/MqmXmr0Yhmzt6X7UhTfXDsqK+BLt+xZw6x3OrgrNnM0F Em0QOjFfhv2VDw/q20yU+Ls+dD6I3Q5TEpKcCcpCKoowVE7XMfba+fuKIXgkw7fb//QdymzJ XygR2MORImwVGcN8tba5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXBDl9wUJBaeC+gAKCRDO jdahpQoh5OD7D/0bKnkRwHgChHe8pXE/RICHXMGF6vduH24ZopMBa3T7S/x/JlgYQ+pmv//2 uSh0+ddtCev2iDOMmZmmw+8Y/JFmKRaNgjCR8zZVvgELKvnBD3770oGShvnMJCZTDajuz+Ah KkWwILkHR5i6wCtUOesLKuujJrFs3oylRvmXNUwQ4LNiWO12s9EBc8sUpGbeKMtXRFxg/Mkl U49XkTNR8K0awZNddEj1j07/uUVon6JafDKCj9eiLQiAEe84CP0andDQFj6wjpGDOb11t12b yBgnj4WN9mK8jt9t19K5tNa+u0WYV0ei8g8lgu9cruFQbbbDDgKd4gUPihlJXL3FSiol/SpA 2u7MSpOvvLuVtkjPGA8JJWYfSOmAnWmjpEtomWU0D5mSU5Dvp8IyJoPnJC4mW7APnD5pw9ZN uZlfoOKMYc9lKPN5SSIwpy1hJGpVSjomYrR2DDCbeXX86tvgPdiwtU9ANrhmsJ9KV2sYLfOQ QnyIJVJhDCVzQl8jHKfwLcsvFOg9h4W/9tBN4NgGNpXtrRJD/EpR2mBEXOsavGPsIzZYdynE ItUrRqChu5Q7thei58dEzrLSt8zBPXRtoOOH6EsoyyHFOqw/nmVa+0xKV5IaOF5VOJkKFveM rStQ8ILhGDeANMRCym0LdOA3jw+0umaGw1zgk+brjOWut4idlA== Organization: CZ.NIC Message-ID: <945d3eae-ba3a-765a-0495-ba0db148d913@nic.cz> Date: Tue, 19 Nov 2019 11:53:02 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <29B6B33A-6099-47AB-8DAD-C6CE94AB5898@fugue.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-PH Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz X-Virus-Status: Clean Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 10:53:05 -0000 On 19. 11. 19 10:12, Ted Lemon wrote: > On Nov 19, 2019, at 3:46 AM, Petr Špaček > wrote: >> Simply I do not see sufficient benefit in exploring this special-domain rat hole, normal domain should work for this purpose just fine. > > The problem with normal domains is that their registration is not permanent. In my eyes that's not sufficient to justify overhead of getting yet another special-domain name, especially if we want to see it deployed in this decade. -- Petr Špaček @ CZ.NIC From nobody Tue Nov 19 02:58:56 2019 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 7C0591208DD for ; Tue, 19 Nov 2019 02:58:54 -0800 (PST) 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 3jSZX3JJvC2x for ; Tue, 19 Nov 2019 02:58:52 -0800 (PST) Received: from pigeon.groveronline.com (pigeon.groveronline.com [198.145.19.6]) by ietfa.amsl.com (Postfix) with ESMTP id B0E151208AB for ; Tue, 19 Nov 2019 02:58:52 -0800 (PST) Received: by pigeon.groveronline.com (Postfix, from userid 501) id 61D23608E3; Tue, 19 Nov 2019 02:58:52 -0800 (PST) Received: from [31.133.146.41] (dhcp-9229.meeting.ietf.org [31.133.146.41]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pigeon.groveronline.com (Postfix) with ESMTPSA id 0E8F46041C for ; Tue, 19 Nov 2019 02:58:50 -0800 (PST) To: add@ietf.org References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> <29B6B33A-6099-47AB-8DAD-C6CE94AB5898@fugue.com> <945d3eae-ba3a-765a-0495-ba0db148d913@nic.cz> From: Andy Grover Autocrypt: addr=andy@groveronline.com; keydata= mQENBFz6mPMBCAClDMGqYBeCSE0Q+rU7v0JibtGh+nSZoNTSdXOHUkk3rN7rmJwdjlWsL0aT 2BGsSYBQjuqlculeJAQq6GG8dj7gjkDX8zVvjNPVqZxNd0bRh9DFE5AZrz3TiTIUwNauKWE9 XvVCMn/ZfzEJhehLa7SUs5vgZ6NHaScq4KZByfNsmiu/n+mPRhJOjgIN7fql5u+ElnNHxOP3 Z9vsoQc5pS9YAMKtEvyWgljm4fbZMs6VBDUGJGaLRmALF5VrJ5AJKzbZWZmaXYNqoxdtakT5 PhJuXkqdnrijZw8TJCglQ/z2wiq2HCU2pzq6/l+19yV0m9iegEuPgtAuwqkh4ecsPAbbABEB AAG0IUFuZHkgR3JvdmVyIDxhZ3JvdmVyQG1vemlsbGEuY29tPokBVAQTAQgAPhYhBKVh7hV4 1gY7lZbAkBVqKb2tr6NBBQJc+pjzAhsDBQkDwmcABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheA AAoJEBVqKb2tr6NB7uwH/RIEtXUCpRGCbVO5LyXmlzTCue9djrb8YrvOOyeVzUxA5kIskguB 5DH7X7RuVa1PlsfsG2F40/5/bPS/fjYIUOGxTQdyiXGeVPotDvg4vaC/3zV16gs8YxOgzKgb P7QhFLHkZoITe6gOv4R0QH1qvRkbg9cyyPr5FoIPaLoXDnw4DWxaNBUSsN+fPRI87yUjPO1v kL+OWBOnBsHxNGaHjd/s9WsIUp8RbLbfMEI+xlM8lM+r5ccECkMS/l9NFX+mCMUlRXqTkd49 mWYJWY5zNnLyqbAZcaRGCrFlX/gjDn8p+pXQEdvtbbqy3KMofxrmf73ECSStM0WnOEgWtSFG ycW5AQ0EXPqY8wEIAMY7xc/W7mIt2nyAe9K/5RiuyGaDItuaEbFzfRmxFvISJm3s5LiyyrGA 82o0HQWqoMjPyLd+pGSSxHL5aWCUsj5vt/rV0FCPvC8W3a0bWxHa+sbb0VeAHna18Ozav1Cx RFLW437tqaD8yF5yh1c0aGolCqv2LjMHetm+UmFoQVbSfcJoxpXepJFVDwvrqqlL+5BoQM15 MzCwux/D8RCgNlTXTnlfm6bRvlD5ttgDoyzN7qYwm+RjA9Izhyps39fKzdk8xkgeu/A55C94 KcPuSs4U9ti7WeU+CubDaLB3bxp7KCyjWpX3oS2CxHFnQsBAbzGx8UeH3dXbdni1AjE71wkA EQEAAYkBPAQYAQgAJhYhBKVh7hV41gY7lZbAkBVqKb2tr6NBBQJc+pjzAhsMBQkDwmcAAAoJ EBVqKb2tr6NBP2MH/0g/e3idsu/ajGzRx6CaRd/ZNxG0/p0aYT4iQWUEt0KZVyHKf17OQK2z u3QSGjSR2V1H419U0m5V3HSMQmy5XrGi3ks4f01Cgq2HiYizhwVwqNVfZERY+WavEIr35w/L eJqEI2Cm4PySxbOOuFig6R7GAknL76iKQBlMH8uX7yV9p0JnrI6tn0lm2n4UjW76CJ3Fk6gD wqoDYDQXfIxYtyMD6QUfiSDZ+8KZoCMDYQQsEcDBz0hRI2mHwL1jHkGNMcVOhBZPtUHinFTc EiQKDXQKkBvschbpbcfJI5g82v6Bl5M995ob7wsXy8VN5+usot+bKqQHGYMsBMbqJf+Ci1I= Message-ID: <43055dc3-6a10-2e2e-4b74-28f576d8dab7@groveronline.com> Date: Tue, 19 Nov 2019 18:58:48 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <945d3eae-ba3a-765a-0495-ba0db148d913@nic.cz> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 10:58:54 -0000 On 11/19/19 6:53 PM, Petr Špaček wrote: > On 19. 11. 19 10:12, Ted Lemon wrote: >> On Nov 19, 2019, at 3:46 AM, Petr Špaček > wrote: >>> Simply I do not see sufficient benefit in exploring this special-domain rat hole, normal domain should work for this purpose just fine. >> >> The problem with normal domains is that their registration is not permanent. > > In my eyes that's not sufficient to justify overhead of getting yet another special-domain name, especially if we want to see it deployed in this decade. > Why would allocating a domain under .arpa take so long? IAB manages it. https://tools.ietf.org/html/rfc3172 -- Andy From nobody Tue Nov 19 03:06:34 2019 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 C6923120910 for ; Tue, 19 Nov 2019 03:06:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.4, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNcTv3Qta2_p for ; Tue, 19 Nov 2019 03:06:27 -0800 (PST) Received: from shaun.rfc1035.com (smtp.v6.rfc1035.com [IPv6:2001:4b10:100:7::25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A5321200D7 for ; Tue, 19 Nov 2019 03:06:27 -0800 (PST) Received: from dhcp-8a04.meeting.ietf.org (dhcp-8a04.meeting.ietf.org [31.133.138.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 794922421173; Tue, 19 Nov 2019 11:06:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: <43055dc3-6a10-2e2e-4b74-28f576d8dab7@groveronline.com> Date: Tue, 19 Nov 2019 11:06:18 +0000 Cc: add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> <29B6B33A-6099-47AB-8DAD-C6CE94AB5898@fugue.com> <945d3eae-ba3a-765a-0495-ba0db148d913@nic.cz> <43055dc3-6a10-2e2e-4b74-28f576d8dab7@groveronline.com> To: Andy Grover X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 11:06:30 -0000 > On 19 Nov 2019, at 10:58, Andy Grover wrote: >=20 >> In my eyes that's not sufficient to justify overhead of getting yet = another special-domain name, especially if we want to see it deployed in = this decade. >=20 > Why would allocating a domain under .arpa take so long? It wouldn't. Petr seems to be thinking about a different type of = special-use domain name that *didn't* involve .arpa: ie a label that = goes in the root or on to a magic list of special TLD strings that will = never ever be created.. From nobody Tue Nov 19 03:09:08 2019 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 607E61208F6 for ; Tue, 19 Nov 2019 03:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.997 X-Spam-Level: X-Spam-Status: No, score=-6.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=nic.cz 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 S-XYIJQ1OyBz for ; Tue, 19 Nov 2019 03:09:05 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.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 4E93B1200D7 for ; Tue, 19 Nov 2019 03:09:05 -0800 (PST) Received: from pc-cznic19.fit.vutbr.cz (unknown [IPv6:2a02:8308:a13e:40f0:4812:72ae:d39e:e874]) by mail.nic.cz (Postfix) with ESMTPSA id B86D7140CE7 for ; Tue, 19 Nov 2019 12:09:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1574161743; bh=/GYzERpINCWp9efa+8Qx60p4nnLMCUMc6mvm80sFmm0=; h=To:From:Date; b=KCZcjNgfjmTruh2CftEpCAzjfULYGRKLuUmB2tAlVnLH0rNtVph2GPiasE2JI+Yjg FZ5brVzNIpi8odQS4dWiFWgqGHC6XzeiwLVat2MARMymtCZCXh1006h3v43yaziFJb 3HLiH6Z59CM7PcfE6MDEw+YaSERLymHX4pRO1PCw= To: add@ietf.org References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> <29B6B33A-6099-47AB-8DAD-C6CE94AB5898@fugue.com> <945d3eae-ba3a-765a-0495-ba0db148d913@nic.cz> <43055dc3-6a10-2e2e-4b74-28f576d8dab7@groveronline.com> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= mQINBFhri/0BEADByTMkvpHcvPYwyhy0IDQ1B2+uU6AWP0QJQB3upM/YqxoJBeMQ5SxpO+W6 BsU0hTIF90AKIgiiDtMH1oNhHnzRXqePKORIgL3BbH5OxGcbqCYk1fIKk43DliCN1RcbTyRV REnCRQGWMTUbRS/jQ3uyTAX4rT0NhPWhPy6TMLGEg6WJJz0IzhBEw3TitvAlq6XHbi5EZYwU AHqIcuqr3sS+qkWqlIBlahu1hqhTcmYGz7ihjnWkOFi1rjRfLfudAtgFpUSmsixh2tifdy+C d8OBQbtF2kM7V1X5dUzw/nUBXm1Qex2qohRmCspwqivu7nlDMrLoilmPaeoR5evr5hpIDdfP cJAPTJk4n56q6MTHFJWkGa0yq13AJHLANNjQ/dF+W6Dhw9w2KBpuw0iGZQBBf5G9SQ1xJ+tU 9filaldsTAX1gMkVso//kGEbuRIJnJr7Z8foE/zofFyoAv21VWy2vpgQ3CnEWOZMSmYH7/gZ qcM7nfkjk4zAijpjYA3qlXoWa44/nrkAGvt7sAMsxY1C2H7tr3h3/rwyfbBqQ9nMpNwYLXXa Dil7uzyqlpKDjwWCzYd3sH7ATyT4htrd0BY5+IFimSfHyLwixhakH8E14YYyV9tzkrB7fiWd g7+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABtCJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMB Ah4BAheAFiEEvibrucvgWbORDKNbzo3WoaUKIeQFAlwQ5d0FCQWnguAACgkQzo3WoaUKIeR/ wQ//c16RhWSNICjuHhdQjJADBdzivZepVBRGsDo1Bau4A+p05iznv8REWIGVfCAAShsH/02h cT2dIoxPzJ/avK4WiDoYLzycLs5nw/eodsUIYxvNcerDNLiBbBP/stSCfPy3oX055mHxTP8P d9rhiHfgWq0dmY58r9tEz00DeP9u/UIMMpY3EXih+wsHSW2l6sXgUMDAPly8MeH0vqmrcp7Y 2/zcOJGH5gGv+KTsXVV4p6Q3h2HgJfRA+q7KCu5P32XswRJZVAiHzwsC+w+jmrtaU+gTQR2B 72m7lfkmct/5I5xAG/QcaoM3pnY/x+eNL4vJ99uK3axdm8b02y+zYqgxVlqDpwXT8cI7B0k4 V9XISZyRn4024YS9ljO2ytV45n4nedzImpqnjBVDura59m9l70aPqyF5O6Sk8IhhW1vhue4M NJnmwmZaY+p9AcB6J9PjEKTZdlpBYoaFbca+r/X0uJtN6P1s/ZJstptji3M84p/g0BnHsGXM vuvpFN3lJUIQXWvf6eZGuvWLVVeAE/vYoz380B7eIbVaNhlbZ8wnSq77atiwjttyCf4LqTBk 4nV+RsJzbS3IUz6MOg5gaet6dJHQ6tMwUOcne74HofWaoXdH0HkmaTh83mKdWjRJlwBnelzT 0ogYWv8CRr7G/I6LQ/WUx0VOmaae9oBdTVCozM+0IFBldHIgU3BhY2VrIDxwZXRyLnNwYWNl a0BuaWMuY3o+iQJUBBMBCAA+AhsDBQsJCAcCBhUICQoLAgQWAgMBAh4BAheAFiEEvibrucvg WbORDKNbzo3WoaUKIeQFAlwQ5eEFCQWnguAACgkQzo3WoaUKIeTE3BAAsXJDtGuCF/Ssz0Y3 b6SA/3ZC+i3bWHz8l7dtFO+gvKFhRdwAxGY4NlD/QSyMTEVz6lHCf4TQYPZOmKisOdEyklgS Yep6dgYitnlMTSUfDC7R+L9fd68NjiPrw4WWKblDr7ukc6VlZpGxKblPpuVLAho0MVi0GEjR fVldMaptchQEW4bGiWj/ESBSR4PL7oPhHzJPXsJMeS4Zhit9RiegFOuPfExWKX+U0yJ69qSU AvyRE1WXQi3gzxXMdPIR0yrukbQInQJ9TwI6LMKy7j7PLx2zExUTRK6GO7TktKwKVn1fVyzF Ir0eMqr5MbUfHapyIUdEHWoLaY0i9ZObXQaSPi0tNZwmneTZbK/7UrawsXGt4Y7BvHS5Hte0 ggFOKJkCJWyMEfQPf2obZkvP5smRC+VMNlC5fOwxLnXBE69NXE9hxdenTr2E43b79Colqyak 4eE7J0aQHe6iQDRyuq8w6cr4Ry54pBCym90saIUt58k+4zxVXJH18VliOdfa98ZlsT4zFjzA biYNuGDGxQ5EAS01Qf8bR29O/rp/MqmXmr0Yhmzt6X7UhTfXDsqK+BLt+xZw6x3OrgrNnM0F Em0QOjFfhv2VDw/q20yU+Ls+dD6I3Q5TEpKcCcpCKoowVE7XMfba+fuKIXgkw7fb//QdymzJ XygR2MORImwVGcN8tba5Ag0EWGuL/QEQAMWnhl/FKgpMBp3QiQUr0JWhnpcrLBgsU08+HPD7 6Bu8cvYRftCqESypuxYxikfiNz8qrnk5hhT+UhxQu4PRj2gNHbpcVCi7QV5I2fNEZvrTtTw4 U49D56L3YybVg9DfcY+PwaptCmQCnfmx+MnrhMf8RBjfxE3feOwdGSHC1ZT/rKj5FmztwVG6 KG4uXwW6g/QDm7/H6U014gGTx/bstVisXzU1IMMNiOc5sJqH5AvMYDAYO2NaQFVrCmgdbCrn w5BLHmmLDI4KcUl4U41FxNGA7Pbf2uwQDkt5h+Y4Zyc3AboIegnll1YnDk5X0GgDtRMcb3nF UdXlCISbqrqKAjrApXZG0VLtGh7Ra3wfuALjUl6popNSwaTPq4mtoXyaYrJLwT6ZKHd2Oap0 k0cXWkmorEDE9gD1jSM+dhZ4Qfh8945HZi8GPO2zJ72c6/UC4o27Td27OhzJT3kN8/+XA0mv lIf3XxV/W3tZwmP12Don0lzks7CDXdCvfVO5mKOsx2ozsskoL/S06RJ5c2gyUck4ipuqbs3j XgjQfK1sQ1/sCLIPE0DlPMkqQHR4E8ubYUxAIct9qwkeBsKtC63qdjDd/caff48PMYQcj2x9 C/+Zi87vuhFIbD7cfLVOjEidwiKsDJGlrkp08uSUOkAO+l+ReO4voh9lnQ4hYotJFr8NABEB AAGJAjwEGAEIACYCGwwWIQS+Juu5y+BZs5EMo1vOjdahpQoh5AUCXBDl9wUJBaeC+gAKCRDO jdahpQoh5OD7D/0bKnkRwHgChHe8pXE/RICHXMGF6vduH24ZopMBa3T7S/x/JlgYQ+pmv//2 uSh0+ddtCev2iDOMmZmmw+8Y/JFmKRaNgjCR8zZVvgELKvnBD3770oGShvnMJCZTDajuz+Ah KkWwILkHR5i6wCtUOesLKuujJrFs3oylRvmXNUwQ4LNiWO12s9EBc8sUpGbeKMtXRFxg/Mkl U49XkTNR8K0awZNddEj1j07/uUVon6JafDKCj9eiLQiAEe84CP0andDQFj6wjpGDOb11t12b yBgnj4WN9mK8jt9t19K5tNa+u0WYV0ei8g8lgu9cruFQbbbDDgKd4gUPihlJXL3FSiol/SpA 2u7MSpOvvLuVtkjPGA8JJWYfSOmAnWmjpEtomWU0D5mSU5Dvp8IyJoPnJC4mW7APnD5pw9ZN uZlfoOKMYc9lKPN5SSIwpy1hJGpVSjomYrR2DDCbeXX86tvgPdiwtU9ANrhmsJ9KV2sYLfOQ QnyIJVJhDCVzQl8jHKfwLcsvFOg9h4W/9tBN4NgGNpXtrRJD/EpR2mBEXOsavGPsIzZYdynE ItUrRqChu5Q7thei58dEzrLSt8zBPXRtoOOH6EsoyyHFOqw/nmVa+0xKV5IaOF5VOJkKFveM rStQ8ILhGDeANMRCym0LdOA3jw+0umaGw1zgk+brjOWut4idlA== Organization: CZ.NIC Message-ID: Date: Tue, 19 Nov 2019 12:09:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <43055dc3-6a10-2e2e-4b74-28f576d8dab7@groveronline.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-PH Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.100.3 at mail.nic.cz X-Virus-Status: Clean Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 11:09:07 -0000 On 19. 11. 19 11:58, Andy Grover wrote: > On 11/19/19 6:53 PM, Petr Špaček wrote: >> On 19. 11. 19 10:12, Ted Lemon wrote: >>> On Nov 19, 2019, at 3:46 AM, Petr Špaček > wrote: >>>> Simply I do not see sufficient benefit in exploring this special-domain rat hole, normal domain should work for this purpose just fine. >>> >>> The problem with normal domains is that their registration is not permanent. >> >> In my eyes that's not sufficient to justify overhead of getting yet another special-domain name, especially if we want to see it deployed in this decade. >> > > Why would allocating a domain under .arpa take so long? IAB manages it. > > https://tools.ietf.org/html/rfc3172 Maybe there is a terminological disconnect: I was referring to special-use names as defined in RFC 6761 - these are nightmare. I'm not objecting to getting a normal DNS mechanisms (from protocol and DNS-resolver-code point of view!). If RFC 3172 allows us to get that in near future then go for it but we will have to live couple years or more with use-application-dns.net anyway. -- Petr Špaček @ CZ.NIC From nobody Tue Nov 19 03:10:39 2019 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 258E91208FD for ; Tue, 19 Nov 2019 03:10:38 -0800 (PST) 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 NRVQytC9D6p7 for ; Tue, 19 Nov 2019 03:10:37 -0800 (PST) Received: from shaun.rfc1035.com (shaun.rfc1035.com [93.186.33.42]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20AA01200D7 for ; Tue, 19 Nov 2019 03:10:37 -0800 (PST) Received: from dhcp-8a04.meeting.ietf.org (dhcp-8a04.meeting.ietf.org [31.133.138.4]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by shaun.rfc1035.com (Postfix) with ESMTPSA id 726B22421173; Tue, 19 Nov 2019 11:10:34 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jim Reid In-Reply-To: Date: Tue, 19 Nov 2019 11:10:30 +0000 Cc: add@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <66BC8D4C-71C9-40CD-AF00-CAEEBD288022@rfc1035.com> References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> <29B6B33A-6099-47AB-8DAD-C6CE94AB5898@fugue.com> <945d3eae-ba3a-765a-0495-ba0db148d913@nic.cz> <43055dc3-6a10-2e2e-4b74-28f576d8dab7@groveronline.com> To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 11:10:38 -0000 > On 19 Nov 2019, at 11:09, Petr =C5=A0pa=C4=8Dek = wrote: >=20 > Maybe there is a terminological disconnect: I was referring to = special-use names as defined in RFC 6761 - these are nightmare. Indeed. And the mood of the room in dsnops this evening was *not* to go = down that path. From nobody Tue Nov 19 03:17:29 2019 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 3BB0D120909 for ; Tue, 19 Nov 2019 03:17:28 -0800 (PST) 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 fIelX5eni8M1 for ; Tue, 19 Nov 2019 03:17:26 -0800 (PST) Received: from mail-qv1-xf29.google.com (mail-qv1-xf29.google.com [IPv6:2607:f8b0:4864:20::f29]) (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 2DCAC120905 for ; Tue, 19 Nov 2019 03:17:26 -0800 (PST) Received: by mail-qv1-xf29.google.com with SMTP id s18so7933093qvr.4 for ; Tue, 19 Nov 2019 03:17:26 -0800 (PST) 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=8gu+TrKg+xlSSFPEswElvfxOCvT7tKwuiU71SjAz9w0=; b=MsOzXNo9v5InpUJ42crTZT2WXu1fCluBudsZ1fZjNsGD8rHVRgghj5auGgyvh7zP4i qvcHbwhrIIw5SCebQ8JaxLnKX7Q2mZ18vfsZ/OzvrKu7TYX83Wv5PNOTheoq8lk/WZdM dK/3Gx7Spz2VOkrVYpZ2cht9Zo60iOjB8WotlR7/ScKtBnnEsqjLIS24uzCiwj7c+Hze nHbKQIcvmPBmPqGbuUTEDC/f1m1DrYCGx4TMYjEvGPwRnZRK5svtYzyFZOpcp+Njf8R7 XaJ7TkcDOl/6qFcHuc+F7tIPoiOFNpbBNW6kLMxj+PRIlEBKTgM21t+AkI+U64jfXg4m s4zQ== 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=8gu+TrKg+xlSSFPEswElvfxOCvT7tKwuiU71SjAz9w0=; b=gaH8yrPIdZWJ0g2GdjBnAsfQPKwJ1rSuwsU9Bp/suTjzyKWZ/6kan8/IhXamGLyOOR 9TcaS/AWCnuknZ/mCmtnL+hPoHw3ieMTaM53e/1AI1Uy+wsYRXQN+OuMloo4D54ddxI5 RZc0Lw1GDBZj83ubjcF0wJqkOiuiBeIDnNp7XSvGFDd17ed3ueHLKLfKuUQ9nxTmxCy8 A+Cnob401P5dlnsrZxGsgKCqiD8p9faJ0UFxzLtQGZSKhP5DeA9z1oWWb1bFRQhYBaek KP/Oj5gVbXwtJwO5rw83EtU2tmb5/2wwkpimR0DwR/TBWW8HXadNR5WTUlhyqN+uUtel jzEQ== X-Gm-Message-State: APjAAAWXsEV/1GEXiW+MUDh8pCyrqg3dlNP+dHB9MX/cy7CreVErVtOS ENlMpfs9NYMilpNPohwvnaCtwOWE6fUg9A== X-Google-Smtp-Source: APXvYqwibB8RFIRRl9r+KzGqeOQABSAXM2gUd30zQqGTK6cMoZ0l4wgMv+3ARpApnYIhfyk2B4NJtQ== X-Received: by 2002:a0c:8506:: with SMTP id n6mr20717133qva.87.1574162245094; Tue, 19 Nov 2019 03:17:25 -0800 (PST) Received: from ?IPv6:2601:18b:300:36ee:6101:8b1:d9fd:1e9a? ([2601:18b:300:36ee:6101:8b1:d9fd:1e9a]) by smtp.gmail.com with ESMTPSA id m25sm12779777qtc.0.2019.11.19.03.17.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2019 03:17:24 -0800 (PST) From: Ted Lemon Message-Id: <7B49EFB0-0B30-424F-BA87-BB27EA10FE30@fugue.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_88CA6C8A-F3CB-4E16-8AA3-519ED83DE0B3" Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.1\)) Date: Tue, 19 Nov 2019 06:17:22 -0500 In-Reply-To: Cc: add@ietf.org To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> <29B6B33A-6099-47AB-8DAD-C6CE94AB5898@fugue.com> <945d3eae-ba3a-765a-0495-ba0db148d913@nic.cz> <43055dc3-6a10-2e2e-4b74-28f576d8dab7@groveronline.com> X-Mailer: Apple Mail (2.3608.40.2.2.1) Archived-At: Subject: Re: [Add] canary domain and recursion 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, 19 Nov 2019 11:17:28 -0000 --Apple-Mail=_88CA6C8A-F3CB-4E16-8AA3-519ED83DE0B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On Nov 19, 2019, at 6:09 AM, Petr =C5=A0pa=C4=8Dek = wrote: > Maybe there is a terminological disconnect: I was referring to = special-use names as defined in RFC 6761 - these are nightmare. >=20 > I'm not objecting to getting a normal DNS mechanisms (from protocol = and DNS-resolver-code point of view!). If RFC 3172 allows us to get that = in near future then go for it but we will have to live couple years or = more with use-application-dns.net = anyway. Special-use names are just names that are treated specially. The = controversy was over special-use top-level names, because these had = issues of who has control over the name. canary.arpa would be = controlled by the IAB. Allocating home.arpa was trivial once we = decided to do that instead of home. --Apple-Mail=_88CA6C8A-F3CB-4E16-8AA3-519ED83DE0B3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On = Nov 19, 2019, at 6:09 AM, Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> = wrote:
Maybe there = is a terminological disconnect: I was referring to special-use names as = defined in RFC 6761 - these are nightmare.

I'm not objecting to getting a normal DNS mechanisms (from = protocol and DNS-resolver-code point of view!). If RFC 3172 allows us to = get that in near future then go for it but we will have to live couple = years or more with use-application-dns.net anyway.

Special-use names are just = names that are treated specially.   The controversy was over = special-use top-level names, because these had issues of who has control = over the name.   canary.arpa would be controlled by the IAB.   = Allocating home.arpa was trivial once we decided to do that instead of = home.

= --Apple-Mail=_88CA6C8A-F3CB-4E16-8AA3-519ED83DE0B3-- From nobody Tue Nov 19 20:42:54 2019 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 88E401201E0 for ; Tue, 19 Nov 2019 20:42:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 TqTiNFhj8WEn for ; Tue, 19 Nov 2019 20:42:50 -0800 (PST) Received: from mail-pg1-x544.google.com (mail-pg1-x544.google.com [IPv6:2607:f8b0:4864:20::544]) (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 933F9120143 for ; Tue, 19 Nov 2019 20:42:50 -0800 (PST) Received: by mail-pg1-x544.google.com with SMTP id b126so1324107pga.6 for ; Tue, 19 Nov 2019 20:42:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Vpxd/tymkoJzAepTAuxmjdfCrEflJMrxViw4C757PlQ=; b=uxBMNNnxXHVcF4AO1rlD2mKmhMTJdQXi+Wyd2jrFxreWsCqpMBLqrUc3MXUFGMjrcA rsxEkbwakPC1wgzVwGIpxb5vo9Pwe4oZagMlTxN6lsa7NvT85mHpbUjC/CwMmU3x4wLz r23bNgmTeWzpqHiNQPBc/MMjxQtivu1Yh0+S68k1d2dfr7+7KBl5agGsmjGy3sF5v1GI jXZZ7zQUeTFobC7cc/a6WezMAufvxtpbS/LovUkDc2cAHlj8IV0EvLIu2yUAZMOpSYtu taByrXRqYF8gKYVyDVZL+gN2HZVM0xkMg9iajaf3BcGszz//5G+4UEn/kpKCKpQimpsL vVHg== 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=Vpxd/tymkoJzAepTAuxmjdfCrEflJMrxViw4C757PlQ=; b=jOPTbHoXA9p3Ak9dcbC7+DNFFaJF5ezHH20RW+R/wbj2tFTrD2qXO2GzcG7ArJljZJ tYe2gexSzZTVj4r8juwB679HZabb2zmkWHni1yoevRMc1ynFNyhEjbyQjBPmXxdgkg/R Hxu6V0Y4AZMLF9yAFM+nCwOMSfmQCSnh0kY6oxApcjI1VI+aPfxPWeNXoEX6KcP2i5oB qy8DjHVrOxhMMEkAfRww0xkS+RFYIr9SVrhqjAvDP4tAcDsK7awF7WNpt+/HvibbNF4e 7ZnkJV0/eZzTY/hGpPfuSxTSWpC2awpQwUWPrt09/BkhW/EK1NO/teiYMz1ewAVUgglQ EWqA== X-Gm-Message-State: APjAAAWICbPs+Nn9NfH/2nC1bQSKPGHDf2p+D0YXHZSdjYHXy6jcT3ll VSBqHrA/cNtdLE57qiZHDxYjIbKbufs2+g== X-Google-Smtp-Source: APXvYqz7IaMpXOT93z7g2kMClqfGyx2BwfNSY+4+8sZXgx5Z/lUKkbC4m9/COYTmEOn7QAxPXpUjSg== X-Received: by 2002:a63:5f42:: with SMTP id t63mr829352pgb.99.1574224969998; Tue, 19 Nov 2019 20:42:49 -0800 (PST) Received: from dhcp-9442.meeting.ietf.org (dhcp-9442.meeting.ietf.org. [31.133.148.66]) by smtp.gmail.com with ESMTPSA id x2sm26367156pfn.167.2019.11.19.20.42.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Nov 2019 20:42:49 -0800 (PST) From: Suzanne Woolf Message-Id: <8656991B-2357-4520-A81B-94EFD5606C48@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_228953C7-8095-48FE-8D29-DD7E1EFE4D85" Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Date: Tue, 19 Nov 2019 23:42:46 -0500 In-Reply-To: <7B49EFB0-0B30-424F-BA87-BB27EA10FE30@fugue.com> Cc: =?utf-8?B?UGV0ciDFoHBhxI1law==?= , add@ietf.org To: Ted Lemon References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> <29B6B33A-6099-47AB-8DAD-C6CE94AB5898@fugue.com> <945d3eae-ba3a-765a-0495-ba0db148d913@nic.cz> <43055dc3-6a10-2e2e-4b74-28f576d8dab7@groveronline.com> <7B49EFB0-0B30-424F-BA87-BB27EA10FE30@fugue.com> X-Mailer: Apple Mail (2.3445.104.11) Archived-At: Subject: Re: [Add] canary domain and recursion 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, 20 Nov 2019 04:42:53 -0000 --Apple-Mail=_228953C7-8095-48FE-8D29-DD7E1EFE4D85 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 (DNSOP co-chair hat on) > On Nov 19, 2019, at 6:17 AM, Ted Lemon wrote: >=20 > On Nov 19, 2019, at 6:09 AM, Petr =C5=A0pa=C4=8Dek > wrote: >> Maybe there is a terminological disconnect: I was referring to = special-use names as defined in RFC 6761 - these are nightmare. >>=20 >> I'm not objecting to getting a normal DNS mechanisms (from protocol = and DNS-resolver-code point of view!). If RFC 3172 allows us to get that = in near future then go for it but we will have to live couple years or = more with use-application-dns.net = anyway. >=20 > Special-use names are just names that are treated specially. The = controversy was over special-use top-level names, because these had = issues of who has control over the name. canary.arpa would be = controlled by the IAB. Allocating home.arpa was trivial once we = decided to do that instead of home. +1. The easy case is =E2=80=9Cthere=E2=80=99s a standards-track RFC that = specifies a SLD under .arpa with the following easily-described = behavior=E2=80=9D (signed delegation, unsigned delegation, = non-delegation with commitment not to delegate, etc.). Examples include = ipv4only.arpa and home.arpa.=20 Standards track is required for the IAB and IANA to have the authority = to make the change in .arpa, per RFC 3172. People have a habit of thinking =E2=80=9Cspecial use name=E2=80=9D = implies top-level label (=E2=80=9CTLD=E2=80=9D). Such cases are indeed = challenging, because they involve either a delegation of a name in the = root zone or a commitment not to delegate a name in the root zone, and = the IETF doesn=E2=80=99t control the root zone. However, there=E2=80=99s = no reason to assume a special use name is a top-level name. Suzanne --Apple-Mail=_228953C7-8095-48FE-8D29-DD7E1EFE4D85 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 (DNSOP co-chair hat on)

On Nov = 19, 2019, at 6:17 AM, Ted Lemon <mellon@fugue.com> wrote:

On Nov 19, 2019, at = 6:09 AM, Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> wrote:
Maybe there is a terminological disconnect: I was referring = to special-use names as defined in RFC 6761 - these are = nightmare.

I'm not = objecting to getting a normal DNS mechanisms (from protocol and = DNS-resolver-code point of view!). If RFC 3172 allows us to get that in = near future then go for it but we will have to live couple years or more = with use-application-dns.net anyway.

Special-use names are just = names that are treated specially.   The controversy was over = special-use top-level names, because these had issues of who has control = over the name.   canary.arpa would be controlled by the IAB.   = Allocating home.arpa was trivial once we decided to do that instead of = home.

+1. The = easy case is =E2=80=9Cthere=E2=80=99s a standards-track RFC that = specifies a SLD under .arpa with the following easily-described = behavior=E2=80=9D (signed delegation, unsigned delegation, = non-delegation with commitment not to delegate, etc.). Examples include = ipv4only.arpa and home.arpa. 

Standards track is required for the IAB and IANA = to have the authority to make the change in .arpa, per RFC = 3172.

People have a habit of = thinking =E2=80=9Cspecial use name=E2=80=9D implies top-level label = (=E2=80=9CTLD=E2=80=9D). Such cases are indeed challenging, because they = involve either a delegation of a name in the root zone or a commitment = not to delegate a name in the root zone, and the IETF doesn=E2=80=99t = control the root zone. However, there=E2=80=99s no reason to assume a = special use name is a top-level name.


Suzanne



= --Apple-Mail=_228953C7-8095-48FE-8D29-DD7E1EFE4D85-- From nobody Tue Nov 19 22:08:54 2019 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 084D3120802 for ; Tue, 19 Nov 2019 22:08:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 TsOtSTeNfMxg for ; Tue, 19 Nov 2019 22:08:51 -0800 (PST) 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 EB89A120274 for ; Tue, 19 Nov 2019 22:08:50 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id s5so2274075iln.4 for ; Tue, 19 Nov 2019 22:08:50 -0800 (PST) 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=y7eALm9DMeOsJzX1TvLNKBERsTGg5ps8AoLSMyMlHq4=; b=kcCHuF27pPMkHHFjCqwpPxYaNrdYxaVpHWGndoHL1qjgtsvc3Cxve/IhnddDNbui7O EzMAQ+uQLRCn3/U04NMhTCNY2fF4R9srGqiBuszKS5nnWdu8sL/8n0FWnIcc5zHuDxsW 07+1t8NIAdV5HJH7k7j3MWG+RfJgtroHRuSXmJCwdMvaR0lKnue2TBacXQyXCDfhawzY qW2FbFuLT7hLJQOZbdZnQuMairJ9XjPe4tYv2GaBHCVtHtjpky4oHCR7qBKN3vjg9r+J IvzCAtt26rCmLWQEcZu+xkX4mYpwrC1xp59eZrG9bBLkaxpXtw5fQHLhg9VEPsBCF+5E 3K9g== 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=y7eALm9DMeOsJzX1TvLNKBERsTGg5ps8AoLSMyMlHq4=; b=kOWC2uc5wAFJjvPZIEpjM1ikUGdn59/XBmhoRiVRUU9PyTvJnC39CpGLLM6CatUUhE JAY9C2HJqfwwK5h4lYPViPMJD3zpUernW9BvpSs5bLF9YJeAloskyvNSMEpnkqxQLl5z /SK2lp0oj8YJL4O8MIFeV7bSHHArS/LdIslo7SOiJWAXpaHeFMtdYlaT9mBWfHAgnx/z KgCabyROiv8Cxs9W1edpfFPIoPllsBwYRSZye4VwqB5XQL7LxwArCZblZHE0ZdF+nWDp yOt79u1mHC3b3DE7zvjkADfFhRN0W4QlkR74xzthhEycpiesj/S6HwA3norRTRufc65Y 7GjQ== X-Gm-Message-State: APjAAAU/RYhZDTIw7IRouAuCYJF6bi1eW0kzELTkq0WA89870qJnK3Pl pea6EOkhTW9a0b5SahpPph2pb3tqM73AaidkKfc= X-Google-Smtp-Source: APXvYqxed1Ob7tAZB53eltBQqpFyUvZiM4RND6/Fyv8ZV3HNNvLuK5x7snrcnA9p1NLI/EYUBc0jx5kiuFpo+BtiIVE= X-Received: by 2002:a92:9957:: with SMTP id p84mr1789030ili.290.1574230129992; Tue, 19 Nov 2019 22:08:49 -0800 (PST) MIME-Version: 1.0 References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> <29B6B33A-6099-47AB-8DAD-C6CE94AB5898@fugue.com> <945d3eae-ba3a-765a-0495-ba0db148d913@nic.cz> <43055dc3-6a10-2e2e-4b74-28f576d8dab7@groveronline.com> <7B49EFB0-0B30-424F-BA87-BB27EA10FE30@fugue.com> <8656991B-2357-4520-A81B-94EFD5606C48@gmail.com> In-Reply-To: <8656991B-2357-4520-A81B-94EFD5606C48@gmail.com> From: Ted Hardie Date: Wed, 20 Nov 2019 14:08:23 +0800 Message-ID: To: Suzanne Woolf Cc: Ted Lemon , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000b1686c0597c10312" Archived-At: Subject: Re: [Add] canary domain and recursion 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, 20 Nov 2019 06:08:53 -0000 --000000000000b1686c0597c10312 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to add an additional citation, the IAB's most recent statement on this usage of .arpa is at: https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-s= tatement-on-the-registration-of-special-use-names-in-the-arpa-domain/ regards, Ted On Wed, Nov 20, 2019 at 12:42 PM Suzanne Woolf wrote: > (DNSOP co-chair hat on) > > On Nov 19, 2019, at 6:17 AM, Ted Lemon wrote: > > On Nov 19, 2019, at 6:09 AM, Petr =C5=A0pa=C4=8Dek w= rote: > > Maybe there is a terminological disconnect: I was referring to special-us= e > names as defined in RFC 6761 - these are nightmare. > > I'm not objecting to getting a normal DNS mechanisms (from protocol and > DNS-resolver-code point of view!). If RFC 3172 allows us to get that in > near future then go for it but we will have to live couple years or more > with use-application-dns.net anyway. > > > Special-use names are just names that are treated specially. The > controversy was over special-use top-level names, because these had issue= s > of who has control over the name. canary.arpa would be controlled by th= e > IAB. Allocating home.arpa was trivial once we decided to do that instea= d > of home. > > > +1. The easy case is =E2=80=9Cthere=E2=80=99s a standards-track RFC that = specifies a SLD > under .arpa with the following easily-described behavior=E2=80=9D (signed > delegation, unsigned delegation, non-delegation with commitment not to > delegate, etc.). Examples include ipv4only.arpa and home.arpa. > > Standards track is required for the IAB and IANA to have the authority to > make the change in .arpa, per RFC 3172. > > People have a habit of thinking =E2=80=9Cspecial use name=E2=80=9D implie= s top-level label > (=E2=80=9CTLD=E2=80=9D). Such cases are indeed challenging, because they = involve either a > delegation of a name in the root zone or a commitment not to delegate a > name in the root zone, and the IETF doesn=E2=80=99t control the root zone= . However, > there=E2=80=99s no reason to assume a special use name is a top-level nam= e. > > > Suzanne > > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --000000000000b1686c0597c10312 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to add an additional citation, the IAB's mos= t recent statement on this usage of .arpa is at: https://www.iab.org= /documents/correspondence-reports-documents/2017-2/iab-statement-on-the-reg= istration-of-special-use-names-in-the-arpa-domain/

=
regards,

Ted

On Wed, Nov 20, 2019 at= 12:42 PM Suzanne Woolf <suzwo= rldwide@gmail.com> wrote:
(DNSOP co-chair = hat on)

On Nov 19, 2019, at 6:17= AM, Ted Lemon <me= llon@fugue.com> wrote:

On Nov 19, 2019, at 6:09 AM, Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz>= wrote:
Maybe there is a terminological disconnect: I was refer= ring to special-use names as defined in RFC 6761 - these are nightmare.

I'm not objecting to getting a normal DNS m= echanisms (from protocol and DNS-resolver-code point of view!). If RFC 3172= allows us to get that in near future then go for it but we will have to li= ve couple years or more with=C2=A0use-application-dns.net=C2=A0anyway.

Special-use names are just names that a= re treated specially. =C2=A0 The controversy was over special-use top-level= names, because these had issues of who has control over the name. =C2=A0 c= anary.arpa would be controlled by the IAB. =C2=A0 Allocating home.arpa was = trivial once we decided to do that instead of home.

+1. The easy case is =E2=80=9Cthere=E2=80=99s a stand= ards-track RFC that specifies a SLD under .arpa with the following easily-d= escribed behavior=E2=80=9D (signed delegation, unsigned delegation, non-del= egation with commitment not to delegate, etc.). Examples include ipv4only.a= rpa and home.arpa.=C2=A0

Standards track is requir= ed for the IAB and IANA to have the authority to make the change in .arpa, = per RFC 3172.

People have a habit of thinking =E2= =80=9Cspecial use name=E2=80=9D implies top-level label (=E2=80=9CTLD=E2=80= =9D). Such cases are indeed challenging, because they involve either a dele= gation of a name in the root zone or a commitment not to delegate a name in= the root zone, and the IETF doesn=E2=80=99t control the root zone. However= , there=E2=80=99s no reason to assume a special use name is a top-level nam= e.


Suzanne



--
Add mailing list
Add@ietf.org
https://www.ietf.org/mailman/listinfo/add
--000000000000b1686c0597c10312-- From nobody Wed Nov 20 00:24:37 2019 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 55682120A80 for ; Wed, 20 Nov 2019 00:24:36 -0800 (PST) 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 v3gFQqtl55Oe for ; Wed, 20 Nov 2019 00:24:35 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF42412004F for ; Wed, 20 Nov 2019 00:24:34 -0800 (PST) Received: from localhost (unknown [128.9.16.45]) by mail.hardakers.net (Postfix) with ESMTPA id 213B228F34 for ; Wed, 20 Nov 2019 00:24:33 -0800 (PST) From: Wes Hardaker To: add@ietf.org Date: Wed, 20 Nov 2019 00:24:32 -0800 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [Add] measuring the size of the canary 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, 20 Nov 2019 08:24:36 -0000 A short while after the announcement of Mozilla's canary domain, I was curious how the bird would grow over time. I finally collected the data and graphed it yesterday. The results are here: https://www.isi.edu/~hardaker/news/20191120-canary-domain-measuring.html -- Wes Hardaker USC/ISI From nobody Wed Nov 20 00:45:59 2019 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 4B13E12084A for ; Wed, 20 Nov 2019 00:45:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.838 X-Spam-Level: ** X-Spam-Status: No, score=2.838 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VrDqVddx9pEo for ; Wed, 20 Nov 2019 00:45:57 -0800 (PST) Received: from pigeon.groveronline.com (pigeon.groveronline.com [198.145.19.6]) by ietfa.amsl.com (Postfix) with ESMTP id 25945120058 for ; Wed, 20 Nov 2019 00:45:56 -0800 (PST) Received: by pigeon.groveronline.com (Postfix, from userid 501) id A4C3B60413; Wed, 20 Nov 2019 00:45:56 -0800 (PST) Received: from [172.16.180.116] (unknown [101.100.166.67]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pigeon.groveronline.com (Postfix) with ESMTPSA id 9015A60413 for ; Wed, 20 Nov 2019 00:45:55 -0800 (PST) To: add@ietf.org References: From: Andy Grover Autocrypt: addr=andy@pmtu.dev; keydata= mQENBFz6mPMBCAClDMGqYBeCSE0Q+rU7v0JibtGh+nSZoNTSdXOHUkk3rN7rmJwdjlWsL0aT 2BGsSYBQjuqlculeJAQq6GG8dj7gjkDX8zVvjNPVqZxNd0bRh9DFE5AZrz3TiTIUwNauKWE9 XvVCMn/ZfzEJhehLa7SUs5vgZ6NHaScq4KZByfNsmiu/n+mPRhJOjgIN7fql5u+ElnNHxOP3 Z9vsoQc5pS9YAMKtEvyWgljm4fbZMs6VBDUGJGaLRmALF5VrJ5AJKzbZWZmaXYNqoxdtakT5 PhJuXkqdnrijZw8TJCglQ/z2wiq2HCU2pzq6/l+19yV0m9iegEuPgtAuwqkh4ecsPAbbABEB AAG0IUFuZHkgR3JvdmVyIDxhZ3JvdmVyQG1vemlsbGEuY29tPokBVAQTAQgAPhYhBKVh7hV4 1gY7lZbAkBVqKb2tr6NBBQJc+pjzAhsDBQkDwmcABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheA AAoJEBVqKb2tr6NB7uwH/RIEtXUCpRGCbVO5LyXmlzTCue9djrb8YrvOOyeVzUxA5kIskguB 5DH7X7RuVa1PlsfsG2F40/5/bPS/fjYIUOGxTQdyiXGeVPotDvg4vaC/3zV16gs8YxOgzKgb P7QhFLHkZoITe6gOv4R0QH1qvRkbg9cyyPr5FoIPaLoXDnw4DWxaNBUSsN+fPRI87yUjPO1v kL+OWBOnBsHxNGaHjd/s9WsIUp8RbLbfMEI+xlM8lM+r5ccECkMS/l9NFX+mCMUlRXqTkd49 mWYJWY5zNnLyqbAZcaRGCrFlX/gjDn8p+pXQEdvtbbqy3KMofxrmf73ECSStM0WnOEgWtSFG ycW5AQ0EXPqY8wEIAMY7xc/W7mIt2nyAe9K/5RiuyGaDItuaEbFzfRmxFvISJm3s5LiyyrGA 82o0HQWqoMjPyLd+pGSSxHL5aWCUsj5vt/rV0FCPvC8W3a0bWxHa+sbb0VeAHna18Ozav1Cx RFLW437tqaD8yF5yh1c0aGolCqv2LjMHetm+UmFoQVbSfcJoxpXepJFVDwvrqqlL+5BoQM15 MzCwux/D8RCgNlTXTnlfm6bRvlD5ttgDoyzN7qYwm+RjA9Izhyps39fKzdk8xkgeu/A55C94 KcPuSs4U9ti7WeU+CubDaLB3bxp7KCyjWpX3oS2CxHFnQsBAbzGx8UeH3dXbdni1AjE71wkA EQEAAYkBPAQYAQgAJhYhBKVh7hV41gY7lZbAkBVqKb2tr6NBBQJc+pjzAhsMBQkDwmcAAAoJ EBVqKb2tr6NBP2MH/0g/e3idsu/ajGzRx6CaRd/ZNxG0/p0aYT4iQWUEt0KZVyHKf17OQK2z u3QSGjSR2V1H419U0m5V3HSMQmy5XrGi3ks4f01Cgq2HiYizhwVwqNVfZERY+WavEIr35w/L eJqEI2Cm4PySxbOOuFig6R7GAknL76iKQBlMH8uX7yV9p0JnrI6tn0lm2n4UjW76CJ3Fk6gD wqoDYDQXfIxYtyMD6QUfiSDZ+8KZoCMDYQQsEcDBz0hRI2mHwL1jHkGNMcVOhBZPtUHinFTc EiQKDXQKkBvschbpbcfJI5g82v6Bl5M995ob7wsXy8VN5+usot+bKqQHGYMsBMbqJf+Ci1I= Message-ID: <09b946bb-b4f6-2125-08bc-bba152073d8c@pmtu.dev> Date: Wed, 20 Nov 2019 16:45:49 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] measuring the size of the canary 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, 20 Nov 2019 08:45:58 -0000 On 11/20/19 4:24 PM, Wes Hardaker wrote: > > A short while after the announcement of Mozilla's canary domain, I was > curious how the bird would grow over time. I finally collected the data > and graphed it yesterday. The results are here: > > https://www.isi.edu/~hardaker/news/20191120-canary-domain-measuring.html > Very interesting, thanks for doing this. By the way, while NXDOMAIN certainly is treated as a positive canary response, it has been expanded to include all error responses as well as successful results that don't include A or AAAA records, so it might actually be a bit higher. -- Andy From nobody Wed Nov 20 01:26:57 2019 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 17633120AC1 for ; Wed, 20 Nov 2019 01:26:56 -0800 (PST) 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 YKQ1icREwdNR for ; Wed, 20 Nov 2019 01:26:54 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9F0120AB6 for ; Wed, 20 Nov 2019 01:26:54 -0800 (PST) Received: from localhost (dhcp-9208.meeting.ietf.org [31.133.146.8]) by mail.hardakers.net (Postfix) with ESMTPA id 0BBB928F55; Wed, 20 Nov 2019 01:26:53 -0800 (PST) From: Wes Hardaker To: Andy Grover Cc: add@ietf.org References: <09b946bb-b4f6-2125-08bc-bba152073d8c@pmtu.dev> Date: Wed, 20 Nov 2019 01:26:49 -0800 In-Reply-To: <09b946bb-b4f6-2125-08bc-bba152073d8c@pmtu.dev> (Andy Grover's message of "Wed, 20 Nov 2019 16:45:49 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Add] measuring the size of the canary 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, 20 Nov 2019 09:26:56 -0000 Andy Grover writes: > By the way, while NXDOMAIN certainly is treated as a positive canary > response, it has been expanded to include all error responses as well as > successful results that don't include A or AAAA records, so it might > actually be a bit higher. I'll look into a better measurement... most of the errors, though, were timeouts. But I'll check for real errors as well. -- Wes Hardaker USC/ISI From nobody Wed Nov 20 01:34:44 2019 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 B3E60120AC6 for ; Wed, 20 Nov 2019 01:34:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, RCVD_IN_DNSWL_NONE=-0.0001, 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 Fvw_iZb8czla for ; Wed, 20 Nov 2019 01:34:41 -0800 (PST) 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 D963A1208E6 for ; Wed, 20 Nov 2019 01:34:40 -0800 (PST) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id xAK9WGBw031110; Wed, 20 Nov 2019 01:34:36 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=hbr1KwuIZxB9ENCkEbRRlHk+iEs/0orlKwoGvpjNpCU=; b=kw8BRQb7k/6BOXf3PaniFrOO3IthFbkHHI5kYUQX9tSlIY+5nuRrv5ejGfite5PL1yty 4lOlOehHHN6imuAqjs5bxPjqgAYMf+UqY4M+NeR/t1XecgZrZ0qKYlDkTUlEW97xMfVi teO4zrUOfcQBTv8rgcS2LeSR/Fs5+9LvLt6PYrtDWwlNbcXZrr9a7Wec9b6iEsC/lK9m 6CgPoijFvc13n0CB5OB+y9Xgi9gKYc2+C22E81rc6Qz2QpsNfVvfCSEOdnQlGB8l7Rl8 nAZPVR0QBxteNzvSVBbTSdoz0xCebmtV0YlLmxOJMyuPk9xWGhJeDJ+uH5oaUiOefVV+ qg== Received: from sng-mtap-sz01.asia.apple.com (sng-mtap-sz01.asia.apple.com [17.84.80.20]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2wagn742x8-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 20 Nov 2019 01:34:36 -0800 Received: from sng-mmpp-sz01.asia.apple.com (sng-mmpp-sz01.asia.apple.com [17.84.80.62]) by sng-mtap-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.5.20190826 64bit (built Aug 26 2019)) with ESMTPS id <0Q1900JK0H8L5L00@sng-mtap-sz01.asia.apple.com>; Wed, 20 Nov 2019 17:33:57 +0800 (+08) Received: from process_milters-daemon.sng-mmpp-sz01.asia.apple.com by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q1900200GVJ7200@sng-mmpp-sz01.asia.apple.com>; Wed, 20 Nov 2019 17:33:56 +0800 (+08) X-Va-A: X-Va-T-CD: d3b848592102170ff64018d6d3356a88 X-Va-E-CD: e62bfd3cc624e598ad750dfa93f36b5e X-Va-R-CD: 141e9a5b110213f070adb5be84fcba28 X-Va-CD: 0 X-Va-ID: 4662d501-eba8-4ce7-bcc6-429dfa0bd0ad X-V-A: X-V-T-CD: d3b848592102170ff64018d6d3356a88 X-V-E-CD: e62bfd3cc624e598ad750dfa93f36b5e X-V-R-CD: 141e9a5b110213f070adb5be84fcba28 X-V-CD: 0 X-V-ID: fb8e1727-6dac-4b56-8466-bbecb4fb9031 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-20_02:,, signatures=0 Received: from [17.235.157.16] by sng-mmpp-sz01.asia.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q1900GQRH8FU870@sng-mmpp-sz01.asia.apple.com>; Wed, 20 Nov 2019 17:33:54 +0800 (+08) Sender: tpauly@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) From: Tommy Pauly In-reply-to: Date: Wed, 20 Nov 2019 17:33:47 +0800 Cc: Andy Grover , add@ietf.org Content-transfer-encoding: quoted-printable Message-id: <797ACE87-69BA-44CB-803F-AFAC092A2194@apple.com> References: <09b946bb-b4f6-2125-08bc-bba152073d8c@pmtu.dev> To: Wes Hardaker X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-20_02:, , signatures=0 Archived-At: Subject: Re: [Add] measuring the size of the canary 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, 20 Nov 2019 09:34:43 -0000 Thanks indeed for sharing this! Not sure if the data can show this, but I'd be curious to know if we see = patterns in the kinds of networks that are using the canary: School = Wi-Fi, home Wi-Fi, enterprise, etc. I also wonder what we think the overall marking rate will be. The fact = that the percentage is already 7% is pretty high, considering that the = use of the canary is still quite nascent. Best, Tommy > On Nov 20, 2019, at 5:26 PM, Wes Hardaker = wrote: >=20 > Andy Grover writes: >=20 >> By the way, while NXDOMAIN certainly is treated as a positive canary >> response, it has been expanded to include all error responses as well = as >> successful results that don't include A or AAAA records, so it might >> actually be a bit higher. >=20 > I'll look into a better measurement... most of the errors, though, = were > timeouts. But I'll check for real errors as well. >=20 > --=20 > Wes Hardaker > USC/ISI >=20 > --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add From nobody Wed Nov 20 01:40:59 2019 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 19BD21208E6 for ; Wed, 20 Nov 2019 01:40:55 -0800 (PST) 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 eSVPF8tikbRH for ; Wed, 20 Nov 2019 01:40:54 -0800 (PST) Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03AEC120AD8 for ; Wed, 20 Nov 2019 01:40:54 -0800 (PST) Received: from localhost (dhcp-9208.meeting.ietf.org [31.133.146.8]) by mail.hardakers.net (Postfix) with ESMTPA id 2D95E28F39; Wed, 20 Nov 2019 01:40:51 -0800 (PST) From: Wes Hardaker To: Andy Grover Cc: add@ietf.org References: <09b946bb-b4f6-2125-08bc-bba152073d8c@pmtu.dev> Date: Wed, 20 Nov 2019 01:40:50 -0800 In-Reply-To: <09b946bb-b4f6-2125-08bc-bba152073d8c@pmtu.dev> (Andy Grover's message of "Wed, 20 Nov 2019 16:45:49 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Add] measuring the size of the canary 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, 20 Nov 2019 09:40:58 -0000 Andy Grover writes: > By the way, while NXDOMAIN certainly is treated as a positive canary > response, Unfortunately, RIPE Atlas doesn't make it easy to determine what the rcode was. I can find other errors in it, but I think you'll agree that these other errors aren't sufficient in the analysis to be included: count error as reported by atlas ----- -------------------------- 2 "nameserver" : "no local resolvers found" 14 "socket" : "connect failed Invalid argument" 8 "socket" : "connect failed Network is unreachable" 4 "socket" : "connect failed Permission denied" 94 "timeout" : 5000 -- Wes Hardaker USC/ISI From nobody Wed Nov 20 03:58:32 2019 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 263441200B9 for ; Wed, 20 Nov 2019 03:58:31 -0800 (PST) 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 oJ0EYlknikMS for ; Wed, 20 Nov 2019 03:58:29 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.112]) (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 83CFF120043 for ; Wed, 20 Nov 2019 03:58:28 -0800 (PST) Received: from [85.158.142.193] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-1.bemta.az-b.eu-central-1.aws.symcld.net id 04/FF-14349-26A25DD5; Wed, 20 Nov 2019 11:58:26 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGJsWRWlGSWpSXmKPExsWi75kzVzdJ62q swZ3f3Bb/T69jc2D0WLLkJ1MAYxRrZl5SfkUCa8buM7PYC3Z6VTSsnsXawLjEuYuRi0NIYDuj xPwVW1ghnMOMEoc+32SHy3x8uoqli5ETyLnIKNH+kxPC7mWS6L9gDlF0l1Fi28dmJpAEm4C9x KV1L1hBbBEBZYmld7eDxYUFNCXebLvEAhHXkjh3eRI7hG0k8eDOYjCbRUBV4sOXlWD1vAIxEo 0Lu5ghFrQySbya/RusmVMgUOL+hg/MIDajgKzEl8bVYDazgLjErSfzwZolBAQkluw5zwxhi0q 8fPwP7DdegYcsEg96lrJDNEdJ7HzWwQZRpCDxetN/qGZZiUvzuxkhbF+Jd28fQtVoSdy9MBHK zpY4fnsrK4StJnHjTQfUMhmJnzd3MIEskxD4xirx7scKdkh4pUjM3biNHaJITmJV70MWmIYHN 7azTWA0nIXkCQg7T+LF1M9gNq+AoMTJmU9YIOI6Egt2f2KDsLUlli18zQxjnznwmAlZfAEj+y pGy6SizPSMktzEzBxdQwMDXUNDY10zEKmXWKWbpJdaqpucmldSlAiU1UssL9YrrsxNzknRy0s t2cQITFYphWyFOxiPf32rd4hRkoNJSZQ38sqVWCG+pPyUyozE4oz4otKc1OJDjDIcHEoSvIoa V2OFBItS01Mr0jJzgIkTJi3BwaMkwntKHSjNW1yQmFucmQ6ROsVoyTHh5dxFzBwfVy0Bkt9Bp BBLXn5eqpQ47zSQBgGQhozSPLhxsOR+iVFWSpiXkYGBQYinILUoN7MEVf4VozgHo5Iw7waQq3 gy80rgtr4COogJ6KCNay+BHFSSiJCSamDSzmua4jFRz3lPXIt61aTsxE7GSLNl3e7e+yafdz3 X/c9MbUpZfeTxrmvfuydJJc/hF93eafJQOjcpxmWl/evpa84GBO7TnvNcniuIm8cxJuxg0boV zg5rWbX+VSdKeU7rs+SYKKIp+Ld6jmIgo9SzfcpXUvfHCvkt5H4r8Mto1cX7zornVy/ZrPr7S 9Q7Xh3nH/9sX7pfdX/r/r01hEltEkth1Nc3usuWXZd0Psy7oLdgvmBF65vHZ2dP7zBk+iIabj NFx/S93pYlSwvu+qSeVH2kmKvMnSfWqOu6Njxk0nYRQ5F14a1hp75NO3fo/s9DD34v331UfsI 03bCzM9eXLtzQfUtGfsZzWZObj42VWIozEg21mIuKEwGcYk8EaQQAAA== X-Env-Sender: Kevin.Smith@vodafone.com X-Msg-Ref: server-8.tower-238.messagelabs.com!1574251105!262381!2 X-Originating-IP: [47.73.108.157] X-SYMC-ESS-Client-Auth: outbound-route-from=pass X-StarScan-Received: X-StarScan-Version: 9.44.22; banners=-,-,- X-VirusChecked: Checked Received: (qmail 21367 invoked from network); 20 Nov 2019 11:58:26 -0000 Received: from vgdpm15vr.vodafone.com (HELO voxe03hw.internal.vodafone.com) (47.73.108.157) by server-8.tower-238.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 20 Nov 2019 11:58:26 -0000 Received: from VOEXH06W.internal.vodafone.com (47.73.211.204) by edge1.vodafone.com (195.232.244.48) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 20 Nov 2019 12:58:20 +0100 Received: from voxe03hw.internal.vodafone.com (195.232.244.48) by VOEXH06W.internal.vodafone.com (47.73.211.204) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 20 Nov 2019 12:58:20 +0100 Received: from VOEXH09W.internal.vodafone.com (47.73.211.213) by edge1.vodafone.com (195.232.244.48) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 20 Nov 2019 12:58:17 +0100 Received: from EUR04-DB3-obe.outbound.protection.outlook.com (172.17.213.44) by VOEXH09W.internal.vodafone.com (47.73.211.213) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 20 Nov 2019 12:58:17 +0100 Received: from AM6PR05MB5861.eurprd05.prod.outlook.com (20.179.3.87) by AM6PR05MB5734.eurprd05.prod.outlook.com (20.178.93.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.16; Wed, 20 Nov 2019 11:58:16 +0000 Received: from AM6PR05MB5861.eurprd05.prod.outlook.com ([fe80::51c2:edfc:185:3362]) by AM6PR05MB5861.eurprd05.prod.outlook.com ([fe80::51c2:edfc:185:3362%6]) with mapi id 15.20.2451.031; Wed, 20 Nov 2019 11:58:16 +0000 From: "Smith, Kevin, Vodafone Group" To: ADD Mailing list Thread-Topic: [Add] Narrowed-down proposal Thread-Index: AQHVnseWRg7Bm4AYCkG7UIWQ/uWVVaeT8qvw Date: Wed, 20 Nov 2019 11:58:16 +0000 Message-ID: References: <63993ACD-2C7B-48E0-867F-3A545F086B15@piuha.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Enabled=True; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SiteId=68283f3b-8487-4c86-adb3-a5228f18b893; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Owner=Kevin.Smith@vodafone.com; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_SetDate=2019-11-20T11:58:15.1527930Z; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Name=C2 General; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Application=Microsoft Azure Information Protection; MSIP_Label_0359f705-2ba0-454b-9cfc-6ce5bcaac040_Extended_MSFT_Method=Automatic; Sensitivity=C2 General x-originating-ip: [47.73.248.74] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ff308b59-428c-4d75-e69f-08d76db0ed97 x-ms-traffictypediagnostic: AM6PR05MB5734: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(39860400002)(396003)(346002)(376002)(51444003)(189003)(199004)(186003)(6436002)(9686003)(6916009)(486006)(6306002)(236005)(54896002)(66066001)(55016002)(316002)(2906002)(476003)(6246003)(66446008)(561944003)(5660300002)(74316002)(7736002)(52536014)(14444005)(71200400001)(71190400001)(256004)(64756008)(66556008)(478600001)(66946007)(66476007)(33656002)(76116006)(76176011)(86362001)(25786009)(26005)(7696005)(6506007)(102836004)(53546011)(446003)(11346002)(8676002)(99286004)(6116002)(81166006)(81156014)(8936002)(229853002)(790700001)(14454004)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM6PR05MB5734; H:AM6PR05MB5861.eurprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: vodafone.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0YOu0OJD6k6rkpmk1th/XkT2nAa1NURm9tp5b9pDHrop+Bb7yvipfb0HPFyWCBRN+jIiMFeKUZiGi3x2tpjQNweLzBeiibBpIWSSQyXrn1tdkLA3VKJtvePerzug6Fry/zA39hBdq26muBsyUfAiDKGZj7h9yg/QCNEubb1rxpH3EoiYNqZOQzL/9IgtG2lGSd4SMY7YFpUXId7NssBAwL75SqUuVbFBr6N+J2+z9ij2YRJ6yih984jGi9vKyJtbGPZYesDgVTzyo8n9XL5Uq49BY5R6QuPFZjn7h882vcO0eqWmC9tMPoSY+8iDdXDmmWdGdIVXDfEqjACwzLspiEH3OFrQMKAsHMWPahNYpwXXZoelgLr29xwmEAM+7I3AKjLiGq4PQU4wm67oomCoLiQ1JxNFOf6dVyBbW4lrw0wXf6XGFzOUn9qGTD9Xmovm x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=HZS1KbSVbT3mJgLUMHuRhPu7BVMqbLwPXLzYSkaCDD6DUvAfHZw0FRvqxWNWFhHKM1L/o0BndN+CQP1cwbVCKtm3MagMmZYeWRnoNQVjJ2D3nynyk0EQz9cvFnAd71vZ5/c9hn6pd4QlA7CxrH0xLvFrclVi5fqQkcuQJlu01O0Re0Z2qPn/Wk3jz6DDIOww2JaiVyfkn2gLLEplRnP+nUsktTQSV5CD263T7AxphfGwm9n/dz2/tTck5XURPTZ81bTJanakbp+lyuEG1feRS96gPrKCZvWYQvY92vIufYE77/O+UTwztfHUrXkFwNS1P3xqIJoQKY2EjNeb/XHNPw== 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=xo7JvBGXlvPJm1CNMhSfgI6/stKXq1n0v84+jisVkHA=; b=TlZtuUWWXk3t1yv3MWsZn+XL2RLNp3LSvaVCjbQdiKXTugiKY35lIughzNUIX7qxC+ZrZmp+0R//7ycuRkXWdFuEjBMBg9JRDJAb6H8eNgIdZ6wc8V7fGW0OgIHJTXFrhV1vwtYAcAGpQOx7ypul2rw/l9uwUSY5dMdMFclrbUPG9ZM7SXeHbZRUr6mc2JEwxWeh+Fej/c1EwmnjniV/ZDsiqN4YWNGeMJgJzIJ2Fp8UeyjTnJnyZXpQoxIbbDTTY8+HVGTkX9u0jDza6LqSFoLq2GmuqNLonl+EAAToJvd4KByRk/r4iA6VmXATWpfE6ClakSPACVPd6MIHi3xFpg== arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=vodafone.com; dmarc=pass action=none header.from=vodafone.com; dkim=pass header.d=vodafone.com; arc=none x-ms-exchange-crosstenant-network-message-id: ff308b59-428c-4d75-e69f-08d76db0ed97 x-ms-exchange-crosstenant-originalarrivaltime: 20 Nov 2019 11:58:16.2712 (UTC) x-ms-exchange-crosstenant-fromentityheader: Hosted x-ms-exchange-crosstenant-id: 68283f3b-8487-4c86-adb3-a5228f18b893 x-ms-exchange-crosstenant-mailboxtype: HOSTED x-ms-exchange-crosstenant-userprincipalname: 5NmwZ2axHWfu1NZDlcdyinrZxj3zlM+Zmoe8extJew6NR9z02N05gxkWIeVyxYKt2/A5f23EmhTx2ex03AuIainauhNA8dOEYSjhxqpMk54= x-ms-exchange-transport-crosstenantheadersstamped: AM6PR05MB5734 Content-Type: multipart/alternative; boundary="_000_AM6PR05MB58619DD3BF10621277C7923A914F0AM6PR05MB5861eurp_" MIME-Version: 1.0 X-OriginatorOrg: vodafone.com X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Add] Narrowed-down proposal 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, 20 Nov 2019 11:58:31 -0000 --_000_AM6PR05MB58619DD3BF10621277C7923A914F0AM6PR05MB5861eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > I'm very much interested in working on the "Discovery of resolvers and th= eir capabilities and behaviors" item +1, so adding 'discovery and communication of resolver policy' to Jari's or= iginal proposal. > and the "Support for debugging and analysis". Yes, notwithstanding the privacy and security analysis as Stephen says. All best, Kevin From: Brian Dickson Sent: 19 November 2019 09:10 Cc: Jari Arkko ; ADD Mailing list ; dns= -privacy@ietf.org Subject: Re: [Add] Narrowed-down proposal On Tue, Nov 19, 2019 at 4:23 PM >= wrote: > From: Add > On Behalf O= f Stephen Farrell > > If there were sufficient interest in the above from multiple implementers= and > operators, then I'd be in agreement with Jari. I don't think we know if t= hat is or is > not the case. (Well, I don't know anyway.) I'm very much interested in working on the "Discovery of resolvers and thei= r capabilities and behaviors" item and the "Support for debugging and analy= sis". I have some ideas that might combine those two through mechanisms that supp= ort both use cases, so it might be possible to reduce the list of items by = one. (This may lead to an actual "DNS traceroute", BTW.) I'd prefer to work with 2-3 co-authors to ensure progress and good collabor= ation, not more and not fewer. Please contact me off-list if you are intere= sted, presuming (a) WG formation, and (b) WG chair approval. I'm willing to contribute ideas and review the item "Local DNS caches (e.g.= partitioning, use of stale records)". (I think that one is particularly im= portant, and important to get right.) Brian C2 General --_000_AM6PR05MB58619DD3BF10621277C7923A914F0AM6PR05MB5861eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> I'm very much interested in working on the "Discovery of resolvers and their capabilities and behaviors" = item

 = ;

+1, so= adding ‘discovery and communication of resolver policy’ to Jar= i’s original proposal.

 = ;

> and the "Support for debugging and = analysis".

 =

Yes, notwi= thstanding the privacy and security analysis as Stephen says.

 = ;

All best,<= br> Kevin

 = ;

From: = Brian Dickson <brian.peter.dickson@gmail.com>
Sent: 19 November 2019 09:10
Cc: Jari Arkko <jari.arkko@piuha.net>; ADD Mailing list <ad= d@ietf.org>; dns-privacy@ietf.org
Subject: Re: [Add] Narrowed-down proposal

 

 

 

On Tue, Nov 19, 2019 at 4:23 PM <chris.box@bt.com> wrote:

> From: Add <add-bounces@ietf.org> On Behalf Of Stephen = Farrell
>
> If there were sufficient interest in the above from multiple implement= ers and
> operators, then I'd be in agreement with Jari. I don't think we know i= f that is or is
> not the case. (Well, I don't know anyway.)

 

I'm very much interested in working on the "Discovery of resolvers and their capabilities and = behaviors" item and the "Support for debugging and analysis"= .

 

I have some ideas that might combine those two throu= gh mechanisms that support both use cases, so it might be possible to reduc= e the list of items by one. 

(This may lead to an actual "DNS traceroute&quo= t;, BTW.)

 

I'd prefer to work with 2-3 co-authors to ensure pro= gress and good collaboration, not more and not fewer. Please contact me off= -list if you are interested, presuming (a) WG formation, and (b) WG chair a= pproval.

 

I'm willing to contribute ideas and review the item = "Local DNS caches (e.g. partitioning, use = of stale records)". (I think that one is particularly important, and i= mportant to get right.)

 

Brian<= /p>

 

= C2 General

--_000_AM6PR05MB58619DD3BF10621277C7923A914F0AM6PR05MB5861eurp_-- From nobody Wed Nov 20 04:32:03 2019 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 26201120052 for ; Wed, 20 Nov 2019 04:32:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YivjbhLEuZRQ for ; Wed, 20 Nov 2019 04:31:57 -0800 (PST) Received: from mail-io1-xd2d.google.com (mail-io1-xd2d.google.com [IPv6:2607:f8b0:4864:20::d2d]) (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 CAA4D1200E9 for ; Wed, 20 Nov 2019 04:31:57 -0800 (PST) Received: by mail-io1-xd2d.google.com with SMTP id 1so27416275iou.4 for ; Wed, 20 Nov 2019 04:31:57 -0800 (PST) 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=wx3nWhUodmUx9hLOS1toRQLKDyExF75T7ZoPgF9cEDE=; b=r5Brv1lsJEEtyaDAu53xhaUuexdRS6skiP5km1hV0VJhHdo2LlcTeWReZNuy/jdSam zqweFeb1DUfPuutRBXLgDoc0ew4vFQ33cLSS5gke9FSqxhfcwInt4wiG74SZUrxDoCGA uLX3IccARn5ztfc3HxDcOfEDSnhE68zkZqxqgX75CinEkIbeB9GT14W5ueyiFae9UxZH x2UD+RzIqqb3Bf4nAQhKzU47uqm+Y+BBvkrp7EswGbAq3A96i+QpaJGg/eu0krJy2AoT ZOUfqadhnm9BmAhXEYh5z+EpkMlisQqPCUyIGW9DPx2rVUkIx9X0Yret3W1YI1gM6lk6 hGzw== 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=wx3nWhUodmUx9hLOS1toRQLKDyExF75T7ZoPgF9cEDE=; b=s4Y7zRrNGjd66dADY8A9FT9wVi5l3ftNXJPzRikJWcoohYed4Y8ngIIHkS14O7EDYQ ONFTUDJ3EJV7o9Lt3pFR88OK62nCpjcijEWIHodD/4fB+i6BZ3Mefcup8pLMqOuYCP+N Eo31Vv6TPVtY6Ycv2IRMWZUbSX0sdqB1teiYe0+rma9akmok3gLlPGkj/CJDmhVxVwOg bhEeMJfrheYNSb4S3bX6pjPgxrCXsdum5dewNtUZG3N0uZzpOI2fDoFUKkxTshY6I6LT Y+4DOAcSDhvpsWJkxF3nruuDYthyCmQU6krOoAXZkO106N6UZLtbZF1f3Gc5JTajY0sM DsCQ== X-Gm-Message-State: APjAAAXV3ydDj9VZ8ZqciBpqqV9NosrdBFNCC7vEs1Xz0upx39tD91up wTnAYuWV0N1MEPKdELcLqEK5PhCt7SHtXxISgZavDb11 X-Google-Smtp-Source: APXvYqyDhUPrIatUG4yOwx7XqrcDPg8uZ9t/W4L54HBEJaFCp5iYr9+1UG3DbtZP55IKvsWr4JubjEGk/aqnENhkpJQ= X-Received: by 2002:a02:ac0a:: with SMTP id a10mr2952944jao.53.1574253116570; Wed, 20 Nov 2019 04:31:56 -0800 (PST) MIME-Version: 1.0 From: Rob Sayre Date: Wed, 20 Nov 2019 04:31:45 -0800 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="000000000000ccc07c0597c65de5" Archived-At: Subject: [Add] communicating DNS configuration 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, 20 Nov 2019 12:32:02 -0000 --000000000000ccc07c0597c65de5 Content-Type: text/plain; charset="UTF-8" Hi, I noticed the first bullet point of the revised charter proposal was "Communicating configuration between the network, operating system, and applications". It seems to me that it's somewhat novel and unwise for the IETF to insert itself in the negotiation of DNS behavior between the operating system and applications. To the extent that kind of thing can be standardized, isn't it better suited to something like The Open Group? Refinements on DHCP options and such seem like fair game, though. thanks, Rob --000000000000ccc07c0597c65de5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I noticed the first bullet poin= t of the revised charter proposal was "Communicating configuration bet= ween the network, operating system, and applications".

<= /div>
It seems to me that it's somewhat novel and unwise for the IE= TF to insert itself in the negotiation of DNS behavior between the operatin= g system and applications. To the extent that kind of thing can be standard= ized, isn't it better suited to something like The Open Group?

Refinements on DHCP options and such seem like fair game, = though.

thanks,
Rob
--000000000000ccc07c0597c65de5-- From nobody Wed Nov 20 06:38:38 2019 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 3764B1208DF for ; Wed, 20 Nov 2019 06:38:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 wi_NFjMLO4Ez for ; Wed, 20 Nov 2019 06:38:35 -0800 (PST) Received: from ppsw-42.csi.cam.ac.uk (ppsw-42.csi.cam.ac.uk [131.111.8.142]) (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 D7E3B1208F6 for ; Wed, 20 Nov 2019 06:38:34 -0800 (PST) X-Cam-AntiVirus: no malware found X-Cam-ScannerInfo: http://help.uis.cam.ac.uk/email-scanner-virus Received: from grey.csi.cam.ac.uk ([131.111.57.57]:50352) by ppsw-42.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.138]:25) with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1iXR7p-000qgF-7U (Exim 4.92.3) (return-path ); Wed, 20 Nov 2019 14:38:33 +0000 Date: Wed, 20 Nov 2019 14:38:33 +0000 From: Tony Finch To: Rob Sayre cc: ADD Mailing list In-Reply-To: Message-ID: References: User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Add] communicating DNS configuration 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, 20 Nov 2019 14:38:37 -0000 Rob Sayre wrote: > > It seems to me that it's somewhat novel and unwise for the IETF to insert > itself in the negotiation of DNS behavior between the operating system and > applications. To the extent that kind of thing can be standardized, isn't > it better suited to something like The Open Group? RFC 3493 specifies getaddrinfo() but I don't know if the IETF still claims change control over the API. (It's kind of annoying that there used to be an almost de facto standard in the BIND4 resolver API that made it possible to dig the server IP address out of the resolver state structure, but implementations diverged significantly when adding IPv6 support so that isn't possible any more. Which makes it relatively hard for applications to get clever (e.g. concurrent queries, validation, etc.) while co-operating with the operating system resolver. And of course there's the issue of co-operating with non-DNS name resolution such as /etc/hosts, SMB, etc...) Tony. -- f.anthony.n.finch http://dotat.at/ Trafalgar: Cyclonic becoming west, 4 to 6, occasionally 7 at first. Rough or very rough, but moderate in sheltered southeast. Rain or thundery showers. Good, occasionally poor. From nobody Wed Nov 20 07:53:24 2019 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 83A46120821 for ; Wed, 20 Nov 2019 07:53:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=umich.edu 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 23HtP4g4lRwN for ; Wed, 20 Nov 2019 07:53:18 -0800 (PST) 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 692641200F5 for ; Wed, 20 Nov 2019 07:53:18 -0800 (PST) Received: by mail-lj1-x22e.google.com with SMTP id t5so28090720ljk.0 for ; Wed, 20 Nov 2019 07:53:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wwbLm748IkCdm0n5XkmWJEDdr/QTOdUmFoSO7L0DUXQ=; b=okub1CRTAqLljk6EhOTklUXp5iVAtrLwepa3lTAKqQlyVppYkoKSYIZTvpXWKbPL9D 1RdzHdw5C1kuSwdUrC3pUEe8tuBzWs9rUPyBLlLV5TtjKg6CRf8r7eP+NtwOdFWFI3qV wS5MG5PUP1se+15JgiFlQUaie4VWz2qeEBqNsS3yjuAhTNzBbkqe0DBhx1avuyytqP14 es0AOYe7iF1eV5DtdtICAD9DZ7oREKuR+DvB8ZytcsNhaHU8EFFiyiRsi0KytFqACsvG yIbKMwl5cghwxQRjnqgUjRNtOz9vpGUp4wJm022x6qIMthTtf5tQhq+11eL4gAZv22JK Gegg== 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=wwbLm748IkCdm0n5XkmWJEDdr/QTOdUmFoSO7L0DUXQ=; b=E11FG++KqNEqfLll5cgwbB0M3GhLTpT7CNQ0KfvArTgYsDdR/XRYc5Vh7Hh6CGE529 CdA6HrficqGfZMqTWovuWxlMmiVVPkJ5eXQ+RWLqH38AMGH7V3/Tvt1StSXuEtezw4BY 3XIuy/Z8RHcIIMWKVeIP7aED0tD/VEpLDlEd5jW7UNZ2vfJ+YtjgXNsSgixx1zlfFv/D te6Rm21RFbX7e88VqGhROTRsIie4EKxYB8KYluUAKzAwA3OeP4Vj+g5Ujd2DwDAoJIqL KqUn6QuQCoC8CzodWvBSVIHTNRYhTq1mcFyBPgS+sK4IWzT2wg1ktnVvW6sG69/5OWRC fFJw== X-Gm-Message-State: APjAAAUN1+VsHbU24PLNm/xPo/z3SFEe/fjZi2zXEK3aeioGxEDywBhZ C5+HqmMaZ6mcxGILic02AhtU5bKyWaDuGuFKtsEP+aSDSoU= X-Google-Smtp-Source: APXvYqyQ2nI7MVBaPPeWkA3rH82kenUJFJxcjWjSlHNjYJ9AB8U6W75qig96f3TqUeHHpt0N53ludkwfw/kVPw/kwnE= X-Received: by 2002:a2e:9802:: with SMTP id a2mr3461291ljj.254.1574265196643; Wed, 20 Nov 2019 07:53:16 -0800 (PST) MIME-Version: 1.0 References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> <29B6B33A-6099-47AB-8DAD-C6CE94AB5898@fugue.com> <945d3eae-ba3a-765a-0495-ba0db148d913@nic.cz> <43055dc3-6a10-2e2e-4b74-28f576d8dab7@groveronline.com> <7B49EFB0-0B30-424F-BA87-BB27EA10FE30@fugue.com> <8656991B-2357-4520-A81B-94EFD5606C48@gmail.com> In-Reply-To: From: Bob Harold Date: Wed, 20 Nov 2019 10:53:05 -0500 Message-ID: To: Ted Hardie Cc: Suzanne Woolf , ADD Mailing list , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , Ted Lemon Content-Type: multipart/alternative; boundary="000000000000d422610597c92de4" Archived-At: Subject: Re: [Add] canary domain and recursion 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, 20 Nov 2019 15:53:22 -0000 --000000000000d422610597c92de4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Corrected URL: https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab-s= tatement-on-the-registration-of-special-use-names-in-the-arpa-domain/ (displayed URL below is correct, but the link has an extra dot after iab) --=20 Bob Harold On Wed, Nov 20, 2019 at 1:09 AM Ted Hardie wrote: > Just to add an additional citation, the IAB's most recent statement on > this usage of .arpa is at: > https://www.iab.org/documents/correspondence-reports-documents/2017-2/iab= -statement-on-the-registration-of-special-use-names-in-the-arpa-domain/ > > > regards, > > Ted > > On Wed, Nov 20, 2019 at 12:42 PM Suzanne Woolf > wrote: > >> (DNSOP co-chair hat on) >> >> On Nov 19, 2019, at 6:17 AM, Ted Lemon wrote: >> >> On Nov 19, 2019, at 6:09 AM, Petr =C5=A0pa=C4=8Dek = wrote: >> >> Maybe there is a terminological disconnect: I was referring to >> special-use names as defined in RFC 6761 - these are nightmare. >> >> I'm not objecting to getting a normal DNS mechanisms (from protocol and >> DNS-resolver-code point of view!). If RFC 3172 allows us to get that in >> near future then go for it but we will have to live couple years or more >> with use-application-dns.net anyway. >> >> >> Special-use names are just names that are treated specially. The >> controversy was over special-use top-level names, because these had issu= es >> of who has control over the name. canary.arpa would be controlled by t= he >> IAB. Allocating home.arpa was trivial once we decided to do that inste= ad >> of home. >> >> >> +1. The easy case is =E2=80=9Cthere=E2=80=99s a standards-track RFC that= specifies a SLD >> under .arpa with the following easily-described behavior=E2=80=9D (signe= d >> delegation, unsigned delegation, non-delegation with commitment not to >> delegate, etc.). Examples include ipv4only.arpa and home.arpa. >> >> Standards track is required for the IAB and IANA to have the authority t= o >> make the change in .arpa, per RFC 3172. >> >> People have a habit of thinking =E2=80=9Cspecial use name=E2=80=9D impli= es top-level >> label (=E2=80=9CTLD=E2=80=9D). Such cases are indeed challenging, becaus= e they involve >> either a delegation of a name in the root zone or a commitment not to >> delegate a name in the root zone, and the IETF doesn=E2=80=99t control t= he root >> zone. However, there=E2=80=99s no reason to assume a special use name is= a >> top-level name. >> >> >> Suzanne >> >> >> >> -- >> 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 > --000000000000d422610597c92de4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, = Nov 20, 2019 at 1:09 AM Ted Hardie <ted.ietf@gmail.com> wrote:
Just to add an additional citatio= n, the IAB's most recent statement on this usage of .arpa is at: https://www.iab.org/documents/correspondence-reports-do= cuments/2017-2/iab-statement-on-the-registration-of-special-use-names-in-th= e-arpa-domain/

regards,

Ted

On Wed, Nov 20, 2019 at 12:42 PM Suzanne Woolf <suzworldwide@gmail.com= > wrote:
=
(DNSOP co-chair hat on)

On = Nov 19, 2019, at 6:17 AM, Ted Lemon <mellon@fugue.com> wrote:

On No= v 19, 2019, at 6:09 AM, Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> wrote:

I'm not objecting to getting a normal DNS mechanisms (from pr= otocol and DNS-resolver-code point of view!). If RFC 3172 allows us to get = that in near future then go for it but we will have to live couple years or= more with=C2=A0use-application-dns.net=C2=A0anyway.

Special-use names are just names that are treated special= ly. =C2=A0 The controversy was over special-use top-level names, because th= ese had issues of who has control over the name. =C2=A0 canary.arpa would b= e controlled by the IAB. =C2=A0 Allocating home.arpa was trivial once we de= cided to do that instead of home.

<= div>+1. The easy case is =E2=80=9Cthere=E2=80=99s a standards-track RFC tha= t specifies a SLD under .arpa with the following easily-described behavior= =E2=80=9D (signed delegation, unsigned delegation, non-delegation with comm= itment not to delegate, etc.). Examples include ipv4only.arpa and home.arpa= .=C2=A0

Standards track is required for the IAB an= d IANA to have the authority to make the change in .arpa, per RFC 3172.

People have a habit of thinking =E2=80=9Cspecial use = name=E2=80=9D implies top-level label (=E2=80=9CTLD=E2=80=9D). Such cases a= re indeed challenging, because they involve either a delegation of a name i= n the root zone or a commitment not to delegate a name in the root zone, an= d the IETF doesn=E2=80=99t control the root zone. However, there=E2=80=99s = no reason to assume a special use name is a top-level name.

<= /div>

Suzanne



--
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
--000000000000d422610597c92de4-- From nobody Wed Nov 20 16:49:50 2019 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 B57291208DB for ; Wed, 20 Nov 2019 16:49:48 -0800 (PST) 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 uTMMI5wYXMn9 for ; Wed, 20 Nov 2019 16:49:46 -0800 (PST) Received: from relay.sandelman.ca (relay.cooperix.net [176.58.120.209]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3E5E12006B for ; Wed, 20 Nov 2019 16:49:46 -0800 (PST) Received: from dooku.sandelman.ca (dhcp-89e3.meeting.ietf.org [31.133.137.227]) by relay.sandelman.ca (Postfix) with ESMTPS id 35B461F450 for ; Thu, 21 Nov 2019 00:49:44 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id C207DE6F; Thu, 21 Nov 2019 08:49:43 +0800 (+08) From: Michael Richardson To: add@ietf.org In-reply-to: <797ACE87-69BA-44CB-803F-AFAC092A2194@apple.com> References: <09b946bb-b4f6-2125-08bc-bba152073d8c@pmtu.dev> <797ACE87-69BA-44CB-803F-AFAC092A2194@apple.com> Comments: In-reply-to Tommy Pauly message dated "Wed, 20 Nov 2019 17:33:47 +0800." X-Mailer: MH-E 8.6; nmh 1.6; GNU Emacs 24.5.1 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Date: Thu, 21 Nov 2019 08:49:43 +0800 Message-ID: <24880.1574297383@dooku.sandelman.ca> Archived-At: Subject: Re: [Add] measuring the size of the canary 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, 21 Nov 2019 00:49:49 -0000 --=-=-= Content-Type: text/plain Tommy Pauly wrote: > Not sure if the data can show this, but I'd be curious to know if we > see patterns in the kinds of networks that are using the canary: School > Wi-Fi, home Wi-Fi, enterprise, etc. I believe that we will get self-selection bias because few of those places will have Atlas probes. > I also wonder what we think the overall marking rate will be. The fact > that the percentage is already 7% is pretty high, considering that the > use of the canary is still quite nascent. I was also surprised, and sent Wes a clarification question, and now realize that he said most of that was timeouts, not intentional configuration of the canary domain. i.e. the local DNS was maybe just broken :-) If only 7/1000 recursive DNS servers are broken, that's a pretty good DNS story :-) -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEERK+9HEcJHTJ9UqTMlUzhVv38QpAFAl3V3ycACgkQlUzhVv38 QpCQpQf/YRpR7mKfyg2KONtnRncT0MkjLA2zn35jcnpDr4ew15cdhxDgOfVXshNr WedXKIfdYRgFheD7iaWNWOcSaqbJkemAidofEo6tm6fi3701Wm5sb6wK8FisoQE5 M6m3Do533JcpTTcv+GMdZMfXTOB0Z02a2kHRot84VotBNXzSkbEuTVAoAlZ5aDj5 ezy8mELwFxXREIOmouxR6RiYYL93CwQr9lm67iGJcEb4jrycc8Dy+trODRytNhjy t4fNxsK4lJXm0+xfpNxmbPVjq3oayRO7ZOxy2+uv+jF/5ZQ6OYD3J7cOHylCq686 Cs8+NHwyHmNm3Wpd8vFzmYv4fHVr+g== =dTQo -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 20 20:57:59 2019 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 250FF12095C for ; Wed, 20 Nov 2019 20:57:58 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=kumari-net.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 yOEyRuwQd5yq for ; Wed, 20 Nov 2019 20:57:55 -0800 (PST) Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (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 92DFE1200F1 for ; Wed, 20 Nov 2019 20:57:55 -0800 (PST) Received: by mail-qk1-x72c.google.com with SMTP id b188so2026730qkg.1 for ; Wed, 20 Nov 2019 20:57:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gu5T+XOnjZllylfgurn9m54eJy6Zw6o1VkrsHYNyb+I=; b=Dp/FFNWE6vnbDIK+0vmipeutUp/eG4Lk00C613/gtMjXE6CRfSyB8fIqMC7G6SLL5x NuL6Sxqz/YnNRNRWB4P0uebJuZ/QPBnYRt1kgWbA6pgZp0EHsx28X45jwiOSRmb7A2ge 164e2W9jf0+I+iNBk1w1w7QQi1JnaFQ1UY2O+q9uOAFUCVNBDdNfoEWTdQL4EydXDEb0 3OKhbqAIapD1+awLk/KhADF9YAewIqAzB10Ws9Kh7eAHdduMzG1VaUG7azRLgj9ldFZt aWzTyHkOPo4SYPUg8G4UxHoicQSPRW6rrp/MAOH9PoSkMSm60Ec/Q4CpmkG0rZUZwAxV KzdQ== 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:content-transfer-encoding; bh=gu5T+XOnjZllylfgurn9m54eJy6Zw6o1VkrsHYNyb+I=; b=R6ifKPfVPHa+lYjf4qIPsl2rYIh4E5TaCshpz1otYjkTN0LkB8RxOQlMHLTfnQVCp3 DBlnVbJD4ak0puxKmpJwQMp1XSBwe1d/MvsAaHCfFO4IKmu06okBlvBZMvAnl+I1y7EE iXcKO3WSNBkw9GKqcbMWKU0CI43kqbl68mbsf2+nDnxW95m8zlZ8l5/BeDCOtHLPlsHT fjgmjNjhEoQfOkAfl6orAH138OTRzXwxhYctylpZ8LtbLNKfz5QI68NEeE1okTuVG+B/ M+BGCWBqs1I9Vs2w+ZBnw0wTf04cLR31mecq9hdG1U434rmI9Mm2ZENAwKnoh6WbbcRD sPcA== X-Gm-Message-State: APjAAAVU9Nr9Chm0L5ENynxDRD2jzfGPEaFSb1qiQR+mCGlAd+sE7cKf Fre5vKcjHVDHOPFzpxpjPMLSX1fTW+XkhLksKBtUCg== X-Google-Smtp-Source: APXvYqy7YamVtz9BiJzmi1X872i/6OEFq0/6MG+CiG/KPH9nj1ZsNkr+mVmhPVDck3Cmp7RO5BQUEres4SgjrlgbkoE= X-Received: by 2002:a37:9083:: with SMTP id s125mr6223413qkd.192.1574312274249; Wed, 20 Nov 2019 20:57:54 -0800 (PST) MIME-Version: 1.0 References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> In-Reply-To: <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> From: Warren Kumari Date: Thu, 21 Nov 2019 12:57:16 +0800 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Cc: ADD Mailing list Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Add] canary domain and recursion 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, 21 Nov 2019 04:57:58 -0000 On Tue, Nov 19, 2019 at 3:10 PM Petr =C5=A0pa=C4=8Dek = wrote: > > On 19. 11. 19 8:00, Ralf Weber wrote: > > Moin! > > > > On 19 Nov 2019, at 14:16, Manu Bretelle wrote: > >> One of the potential issue with a standard domain, is that the local > >> network will perform recursion to learn its records. > >> > >> This basically allow anyone upstream/on-path from the resolver to inte= rcept > >> and change the result to their liking. > > Not if you DNSSEC sign it. Then the last resolver still can NXD it, but > > nobody in the way can as it would not validate. > > I agree with Ralf. .... assuming that they validate. In an ideal world, everybody validates, but until then someone upstream could use this to downgrade the connection - this is a poor failure mode, but perhaps that is just more impetus for local validation (which also doesn't really work, because it's unclear who exactly up the path should be allowed to do this). > > > > >> How about signaling this through .test domain [0] or similar? The reso= lver > >> is not supposed to query/lookup authoritative servers for it. > >> Someone wanting to disable DoH, would be able to return answers for A/= AAAA, > >> NXDOMAIN would mean that there is no intent to disable it. > > Asking for a new special-use name is usually asking for trouble for two r= easons: Getting special-name reservation involves too much politics, and ge= tting it deployed requires changes in all DNS stacks. Please let's use a no= rmal DNS delegation. I really dislike this entire opt-out solution, but if it is used, something under .arpa (like others have suggested downstream) seems less bad.... > > Petr =C5=A0pa=C4=8Dek @ CZ.NIC > > > We can do this, but it would require changes in the software as nothing= is > > defined for these. .arpa might be better, but the problem with the > > software is the same. And you can certainly not sign .test, but you mig= ht > > be able to sign something in .arpa. > > > > So long > > -Ralf > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add --=20 I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf From nobody Wed Nov 20 22:05:15 2019 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 9F07A120124 for ; Wed, 20 Nov 2019 22:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=bMs4ygbB; dkim=pass (2048-bit key) header.d=comcast.com header.b=eM8gxCPj; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=JXOvcUVv 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 wezMeIcUQOmb for ; Wed, 20 Nov 2019 22:05:12 -0800 (PST) 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 5ED151200FB for ; Wed, 20 Nov 2019 22:05:12 -0800 (PST) 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 xAL5rRgf002669 for ; Thu, 21 Nov 2019 01:05:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=RRzHSiyllXiTUfjYypOGSTyZkbQgV+N6zYFpnnoE+eM=; b=bMs4ygbBC5t4yUwgMzazPr5DYObgE9ORVdZQ5d30Nb9N7vdVMNadEBYcwouOEgH8DBF2 uexuReDyCDpg568cmabkwkD2/mbFGVIQ5jhLD8DYQPoEB0GVEpriomqq8B0Bnl3S+txb oYBgf91j/N4fYUl7YD12e3gijTfreGscFjp5Goyt/qJXoZJvWWj16+8UvVF6TQyTxJx9 iTICRMl+NS3ZlEVnyC5uBaYlJv3ckw7NEcc1ayBclqRQrdjAelgEasIWTy8QPrpQQI8w LiVqPI4Wr4Wyd35g0msmCtY/RZZ6DJHTaN4NLd3XHA/NwlY8eBU+AjZPdx17a6dBtZu2 Cw== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 2wd8gxw2fv-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 21 Nov 2019 01:05:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1574316311; x=2438229911; 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=RRzHSiyllXiTUfjYypOGSTyZkbQgV+N6zYFpnnoE+eM=; b=eM8gxCPjDZiglkYiAPMNA3FQQCqfSdQFI/On652WTPfHSIWoxGTTWKM+OeVIBWS1 fjc6EwCNYZEo291LMVwg3EMxEhBs066AgE1RozoRooWTOpgHkN6FNC/SEVBme1TX JyBeKp1aGmKJs700HZ/kKgYe6Gh8honvphjR4qjmXtS1Ye9VtmuZVkqPh9n5Gw2I ezTpdRdNoanCKupO3sE0pJTUVkw6Oa0/bwRtRqhuduP4fITlIRNV4I7zesDeS9lH oiPFxvaw3+S1dHHmnp2Lu/YH5+qMkPxv3SqRYEMcl4mJwCMJzV5z578DT2dqZQAg CvoXGB4y3Ji6dWHiFGfpEA==; X-AuditID: 60729ed4-04dff7000000a7f4-12-5dd6291719e8 Received: from COPDCEX16.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 copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 66.D4.42996.71926DD5; Wed, 20 Nov 2019 23:05:11 -0700 (MST) Received: from COPDCEX49.cable.comcast.com (147.191.125.148) by COPDCEX16.cable.comcast.com (147.191.124.147) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 23:05:11 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX49.cable.comcast.com (147.191.125.148) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 20 Nov 2019 23:05:10 -0700 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (104.47.37.56) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 21 Nov 2019 01:05:10 -0500 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB4151.namprd11.prod.outlook.com (10.255.162.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.30; Thu, 21 Nov 2019 06:05:08 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a%7]) with mapi id 15.20.2474.018; Thu, 21 Nov 2019 06:05:08 +0000 From: "Livingood, Jason" To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= , Ted Lemon CC: "add@ietf.org" , Manu Bretelle Thread-Topic: [Add] canary domain and recursion Thread-Index: AQHVnqECLnlvaulAZ02+niHOe69kdqeSENyAgAACxICAABIQAIAACKAAgAAHagCAABwLAIADWlSA Date: Thu, 21 Nov 2019 06:05:08 +0000 Message-ID: <1087D8B6-164D-4D79-BCBE-BAB7C111C71E@cable.comcast.com> References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <01aa273f-6e5e-2e19-5998-9a5ce4bf23ea@nic.cz> <29B6B33A-6099-47AB-8DAD-C6CE94AB5898@fugue.com> <945d3eae-ba3a-765a-0495-ba0db148d913@nic.cz> In-Reply-To: <945d3eae-ba3a-765a-0495-ba0db148d913@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1e.0.191013 x-originating-ip: [31.133.155.20] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 39436a84-158a-4e72-4c08-08d76e48c318 x-ms-traffictypediagnostic: BY5PR11MB4151: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(4636009)(346002)(376002)(396003)(39860400002)(136003)(366004)(189003)(199004)(6436002)(3846002)(33656002)(5660300002)(8936002)(80792005)(99286004)(66446008)(476003)(14454004)(478600001)(11346002)(4744005)(186003)(8676002)(81156014)(6306002)(6512007)(4326008)(81166006)(2906002)(6486002)(86362001)(966005)(66556008)(64756008)(6116002)(66066001)(76116006)(66476007)(446003)(91956017)(53546011)(54906003)(305945005)(25786009)(6246003)(316002)(6506007)(66946007)(76176011)(2616005)(71200400001)(71190400001)(486006)(26005)(7736002)(102836004)(110136005)(256004)(58126008)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB4151; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: xTuBWSYldPCNQemkQHZWIa7g0IOvON+p+yyZWdOFrrxdPNJitNa2WjIJr5hI54hbDaK8MmxYMCdJxOvsdhVBW2ci+as4F+qtrvEHSkVUZcAEMblp3W+nFF7FJMm9tMU/y/g+FfqtXYANUScKB78o6enTVNAuYI8gp5SBW+Mkpi7gBIDEo8MPllmRb9GWlcAVOLb3qF+Ry6Kz0/6t2COyzau7hHKTkW562q93tCjizDjzWDxVS3uYe07mldKMRSZVK91reGe1tZjaZXY053OtdrG+CTJkuTzjkaK6bRd7Rttm2A/AsEvdRk4HSIt/HrWT/SrcEVSmQ+DQkC63OKbTwaDNY3esGMvPh5BvXfDviJA5OKDk+PIl4Z7BK8Os1I63oc7ZcMTgFeCUhNJcV4Y1wmy1bfiwwrXmbP1/2y/PJdVLmnjZDYM8FTKclfIc89os x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QncYSVfMVMEVyiL0viAcNDSFR9MyHfu3OyQeQUlilL0Gr8UUvsPR5eqrcO2IUkYpI/8N3leg9ZdUR5ssNeWEPKXEZQDtk1BG9oGKlaUOsxT8uQhtZViJSVOWZGaKO7EwXwQg8ji1X4tUSNuIlcSL6lgHPb0G01Y6MERQtEnZlq+ip/9oQYAwiD+Jlj0h0b6yP3fPcKyKTcnYnTqdtKz+W3CF+NSgMKkTAxYX0rpi7KH5mN+t2jdmDrsZMev8dyzAj1ZW2cjeMuy0PHbQZx1QX7dGc7zzHm00WwOHUYiGva96Mw+UV0r/v+NlLvXVB9XPmecNDQsKa3pFSohkg72/LQ== 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=Tkli27lz90dUsENXSVpYLBQrk6JTJ//e1xZ2YcLGkaE=; b=QGEWrRyVfBUQBmnPQtU2q5HswRG3zdqRUFAvXMDwEKirOIqeEfKfy4h5OtAgIlo/O+fdEmAdr4eYl6G0Gtm5+tE+eC0bmR6fgXWP5iUYRr0uMJw363ozyQg2mUadCfeaZ03hR5Ed7lMtnpIRCDlIRpk60+eC2r5Crj+b7OWpLaj9hLXUoEfKWe5hsRo3K4ZwSJ8msqHvOS8pZJJ5g4AQOFr4SCtJrFX80+hlqfjX9KspOVdoaSRnHnXF6x5yrBsZwGez2wmBGCnqYEqoCY4zAuJBud9HvapCalPlmtJDJgVbeemKsfzmdQzjXJAiymotCnbxvFc6XW7gFOxh6k6Fbg== 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=Tkli27lz90dUsENXSVpYLBQrk6JTJ//e1xZ2YcLGkaE=; b=JXOvcUVvXbd/t1nKxYI0LNYVVJ8A3Ft4HeVYpMvdeExA25UPcoa39HOAvGk5hOjxuvpAf+FUHcOWW1mBIhe5KSPalRudlaO629FW2oR11ndadqQEjPcwohem88P7jd/jQiIDu366PWbDHhj0LXXwcN0bAluGVEM7B04pgMjeal0= x-ms-exchange-crosstenant-network-message-id: 39436a84-158a-4e72-4c08-08d76e48c318 x-ms-exchange-crosstenant-originalarrivaltime: 21 Nov 2019 06:05:08.4345 (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: lzCsbrIayi94UA3OmE6eZILFcerfE/sK2bdPvw6bocjI06FTE5F3izHVd8rHKaOtVwsPAngzbF7vxVxXZ4ijhwZ/Pp/GFWNKEDWUXZ7+mZg= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB4151 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <4E26B4F9F250C04C82325CAA3AC7471B@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprEJsWRmVeSWpSXmKPExsWSUDRnsq645rVYg0PbDC3+n17HZjH93Dcm izdrjjBZdP7zcWDxaLqwjN1j56y77B5Llvxk8th0+Q5jAEtUA6NNSUZRamKJS2paal5xqh2X AgawSUpNyy9KdU0syqkMSs1JTcSuDKQyJTUnsyy1SB+rMfpYzUnoYspYtaqbtWACT8Xq3zfZ GxhfcHcxcnJICJhIrLm/jRHEFhI4zCTRf0K6i5ELyD7EKLF14VYmCOcOo8SR/h1sEM4JRokp yx6zQ7RMYZK4u7ISIvGIUaLj4y2wBJuAmcTdhVeYQWwRgUiJCyu3sYLYzAIuEsu/bAWLCwvo SRyfOR2qRl/izfuZUHaUxL2Xz5hAbBYBVYnbi3axgNi8QL2XVz9nh1jWyyyxZ8FeNpAEp4CV xJ7/S8BsRgExie+n1jBBLBOXuPVkPhPEowISS/acZ4awRSVePv4HdBAHhyjQ4oN/fSFaUyQW dy2CKleUWPp5IVS5rMSl+d2MELavxL8OmBotiS2XZrBB2NkSS1d3sEPYahJT1n+C6pWRuP7w CDjkJAT+skocv7uMCWSvkECWxNurdhMYTWchuXQWUIZZQFNi/S59iLCHxNHb0xghbEWJKd0P 2WeBQ0JQ4uTMJywLGFlXMfJZmukZGproGZpa6BkZGm1iBKfUeVd2MF6e7nGIUYCDUYmHl0no WqwQa2JZcWUuMGI5mJVEePdcvxIrxJuSWFmVWpQfX1Sak1p8iFGag0VJnJdv7YJYIYH0xJLU 7NTUgtQimCwTB6dUA+PqHY3TfEzlH53zcBLwPnVqZ73rurML9/J80l7zbfGnrKm7GB5NXmiV I3h7z+8sHTHB2xu9JDcun3x0xwX7BuPY4xus5zZsKYwqrzKaHLadoVuF+1Qx69+U37lbzk5S uPdXt+CU16FnSjuOKz0OOhBec7ezy+/agi13lhS7lX3JsBDUPl4516tFiaU4I9FQi7moOBEA grDpzqUDAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-20_08:2019-11-20,2019-11-20 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] canary domain and recursion 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, 21 Nov 2019 06:05:14 -0000 VGhpcyBwcmVzZW50YXRpb24gZnJvbSBSb3kgQXJlbmRzIG1heSBiZSBvZiBpbnRlcmVzdCBvbiB0 aGUgc3ViamVjdCBvZiBzcGVjaWFsIHVzZSBkb21haW5zOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9tZWV0aW5nLzEwNi9tYXRlcmlhbHMvc2xpZGVzLTEwNi1kbnNvcC1zZXNzYS1kcmFm dC1hcmVuZHMtcHJpdmF0ZS11c2UtdGxkDQoNCkphc29uDQoNCu+7v09uIDExLzE5LzE5LCA2OjUz IFBNLCAiQWRkIG9uIGJlaGFsZiBvZiBQZXRyIMWgcGHEjWVrIiA8YWRkLWJvdW5jZXNAaWV0Zi5v cmcgb24gYmVoYWxmIG9mIHBldHIuc3BhY2VrQG5pYy5jej4gd3JvdGU6DQoNCiAgICBPbiAxOS4g MTEuIDE5IDEwOjEyLCBUZWQgTGVtb24gd3JvdGU6DQogICAgPiBPbiBOb3YgMTksIDIwMTksIGF0 IDM6NDYgQU0sIFBldHIgxaBwYcSNZWsgPHBldHIuc3BhY2VrQG5pYy5jeiA8bWFpbHRvOnBldHIu c3BhY2VrQG5pYy5jej4+IHdyb3RlOg0KICAgID4+IFNpbXBseSBJIGRvIG5vdCBzZWUgc3VmZmlj aWVudCBiZW5lZml0IGluIGV4cGxvcmluZyB0aGlzIHNwZWNpYWwtZG9tYWluIHJhdCBob2xlLCBu b3JtYWwgZG9tYWluIHNob3VsZCB3b3JrIGZvciB0aGlzIHB1cnBvc2UganVzdCBmaW5lLg0KICAg ID4NCiAgICA+IFRoZSBwcm9ibGVtIHdpdGggbm9ybWFsIGRvbWFpbnMgaXMgdGhhdCB0aGVpciBy ZWdpc3RyYXRpb24gaXMgbm90IHBlcm1hbmVudC4NCg0KICAgIEluIG15IGV5ZXMgdGhhdCdzIG5v dCBzdWZmaWNpZW50IHRvIGp1c3RpZnkgb3ZlcmhlYWQgb2YgZ2V0dGluZyB5ZXQgYW5vdGhlciBz cGVjaWFsLWRvbWFpbiBuYW1lLCBlc3BlY2lhbGx5IGlmIHdlIHdhbnQgdG8gc2VlIGl0IGRlcGxv eWVkIGluIHRoaXMgZGVjYWRlLg0KDQogICAgLS0NCiAgICBQZXRyIMWgcGHEjWVrICBAICBDWi5O SUMNCg0KICAgIC0tDQogICAgQWRkIG1haWxpbmcgbGlzdA0KICAgIEFkZEBpZXRmLm9yZw0KICAg IGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2FkZF9fOyFyeF9MNzVJVGdPUSFUc2xNMFpJWkY1Z3k3X1FzamQyc3ZFazFHMXFr YjZOdlNTNWc1cDJrRUw1akxYMGM4QmFXMDhsLWhqcElnUktBV3JrZXp3JA0KDQoNCg== From nobody Wed Nov 20 22:26:30 2019 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 9594312008A for ; Wed, 20 Nov 2019 22:26:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_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 Cqk0L_Qz24NE for ; Wed, 20 Nov 2019 22:26:27 -0800 (PST) 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 C426C120033 for ; Wed, 20 Nov 2019 22:26:26 -0800 (PST) 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)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 94C3A6A27D; Thu, 21 Nov 2019 07:26:23 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1574317583; bh=KjhKgTtPSjz7a44uMkQTC56vjHBExlDdpuWxx9pXEB0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=Tb9oet5lFzkmrMjVbFxWd7NNpzwJoYGS19poEmfONoaUXm1GDh7E/eDlecFuFKMo6 6eDnSNC3M7BS5UV7UrU+mmwa5fSgJ5yXJApBe7EnTFaOspqUHflhOkCvThugHJCykC hkgUYJEg3R8dBl+B2psnhgpcjEsZVfJWIKuNWQ1ignPhAc6of2hEUUvRn3l/o2kNu1 qzxHDeRUGifCcJvK4kIBGmCe4tJo9G6MPsSWzHGW3jCB/1JFLbG26RparVm7aExEUI ByWc5nfTxuKiGiZIPEQDTUYywxRUNaYf+kQzf0bes5g2YncpHfwME4t2F8QRBpstbD JiaNVV6sfP7tQ== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (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 87C813C035F; Thu, 21 Nov 2019 07:26:23 +0100 (CET) Date: Thu, 21 Nov 2019 07:26:23 +0100 (CET) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Warren Kumari Cc: ADD Mailing list Message-ID: <1871693264.18877.1574317583456@appsuite-gw2.open-xchange.com> In-Reply-To: References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev17 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] canary domain and recursion 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, 21 Nov 2019 06:26:29 -0000 > Il 21 novembre 2019 05:57 Warren Kumari ha scritto: > > I really dislike this entire opt-out solution, but if it is used, > something under .arpa (like others have suggested downstream) seems less bad.... If I may broaden the discussion a little... The introduction of the canary domain was a positive and appreciated step by Mozilla to deal with the immediate problems caused by their DoH deployment model. At the same time, however, it is a conceptual nonsense: if you pick a deployment model that bypasses the local network and resolver because you do not trust them, then it does not make sense to ask them whether you should actually turn DoH on or not. (Personally, I think that Mozilla's need for this mechanism is also a sign that the entire deployment model is conceptually flawed, but I do not ask them to share this conclusion.) It is just a matter of time before some entity that uses the local resolver in ways Mozilla do not like turns the canary on, and then they will have to implement additional logic to distinguish proper and improper uses of the canary, or give up the entire mechanism altogether. So, before we get to that point, we should already think at what could be a better way to deal with a problem which could be formulated as "distinguishing between good and bad local networks" or "getting policy indications from the local network in a secure, authenticated way that could also allow the client to take decisions on whether to accept or reject them". Possibly, a good local resolver discovery mechanism could provide a solution to this problem, at least in part. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Wed Nov 20 22:46:44 2019 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 02900120143 for ; Wed, 20 Nov 2019 22:46:43 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=netorgft5189650.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 N5-GMt3DkCJK for ; Wed, 20 Nov 2019 22:46:41 -0800 (PST) Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-eopbgr110058.outbound.protection.outlook.com [40.107.11.58]) (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 BFCB8120124 for ; Wed, 20 Nov 2019 22:46:40 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=H5S5pohvtu479FEGjL6WbOfMwSc5mmYrVv0wzdjbZ9mnA+wI1VfGxozcpZwm52VkX65X5OxC/eYxiJXZARrdARALn618eP+Kefl7K3THGGYcIEdYkzJIA+4YC/we09/fW93krm5uQcTJmZFjEVWlwnUDB3sPPAy2KNUMmS2gNR/Qq3Rid+EWiSgE6siEUYlkc7RNNxeHnbRl1xpJeEcbLud8s4aCMOyXiAA9j1mQ9nvDpycHAZB+pJm62v5L4ZTayR4ncR3CRPogqsfXXkLwZjlIxnCNRyBATYCWv3ZNiF8EZcNE7tfwEDAfxb3V688hof2PapsOst6gjffpKRj8nw== 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=pIGUWJTj9UuAoqDVoPEn8Py3XMBCQt9tDPMqcnXgeD0=; b=l3TsyTYmC+hbjU7el9W+tiP77Y5zWI35jKcI/gRfVNSsvnB9ZMsCd8AtTkLLBCRci0C1h6Y/yik5VP7uJdrftl8fjAFd5uB0C7Q2BmAFPi0urE+8HfRkHTCSmm91TzFiZlwy1wbrfet9pMkYeypNswiKloYDd2RNamLsRQbB12UVzrmy9AD9gc+lFO0rSWyNTnJwqyyRIrCQjKzReTRyLPOCxkiGZDhy2Y4PVoJT3kUUohvkjJJMxjCjgnnQEPMXn5Qdw8uAAHnjhTpEsTbWliU4bzCux++AwJ3H57g8f0EHQA1JUdnTSJ8Z9qOP8zdisHy/Zeq8nmNnhRKavAH4/A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=pIGUWJTj9UuAoqDVoPEn8Py3XMBCQt9tDPMqcnXgeD0=; b=FLTXTad9J6yP8hFiQLly2sGA6L2oB1xHxklmwSn5qm6Wx0RUTjN/FJdSBgdXmi05ULECiPUYgsJ8VAleg/f5tdGkbHqVOuEgelqGYiEzjYzXBGX2aAx/JWL54Ag/bg3KP5Ad8DdaTpGuvGTUFPMBFl+oJ7FEHgTc+iIWcpng86Q= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2P265MB0398.GBRP265.PROD.OUTLOOK.COM (10.166.100.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.30; Thu, 21 Nov 2019 06:46:37 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712%7]) with mapi id 15.20.2451.031; Thu, 21 Nov 2019 06:46:37 +0000 From: Andrew Campling To: Vittorio Bertola , Warren Kumari CC: ADD Mailing list Thread-Topic: [Add] canary domain and recursion Thread-Index: AQHVoDSgU+UZIVhMHkaqsIP4mvCvpaeVLLKA Date: Thu, 21 Nov 2019 06:46:37 +0000 Message-ID: References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <1871693264.18877.1574317583456@appsuite-gw2.open-xchange.com> In-Reply-To: <1871693264.18877.1574317583456@appsuite-gw2.open-xchange.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [2001:67c:370:128:5855:8e60:995f:4546] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 06207960-078b-419f-efe8-08d76e4e8ebd x-ms-traffictypediagnostic: LO2P265MB0398: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39830400003)(346002)(136003)(376002)(199004)(189003)(102836004)(44832011)(66946007)(76116006)(64756008)(6116002)(33656002)(5660300002)(52536014)(4744005)(66556008)(6246003)(9686003)(6436002)(2906002)(55016002)(14454004)(4326008)(229853002)(25786009)(71190400001)(71200400001)(8676002)(45080400002)(508600001)(186003)(81166006)(81156014)(66446008)(99286004)(76176011)(53546011)(7696005)(8936002)(6506007)(7736002)(74316002)(446003)(305945005)(66476007)(46003)(86362001)(316002)(256004)(110136005)(11346002)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2P265MB0398; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: XWHqO2iYWmf7RRXxuVwWZlbKWDqrrJ9I7FLrPWvu9HYUZP3wtlFFU9XRT+5B278cCpImqC+L0ysHAHrWaLzqVhiIOclJ4sEzXEJnueawhcZSi6rSGgXYxiXgx3DEfQb9UuXun58+1alOxyVTxCTmuJ3xuUlpFKQjS+36FQKYapZNAFbtrnxWcLoVrWykxT9FYN9FH/Kn4gS/MfcaTOvt02Lr3moqHpaxnrR0Ena1oDmiqE54BVGESl6RWp73RwTIA6pTlP1KWsAE4Aa9K3+n+UrVM2r6ujF0IvQPkVcMcgWuob2Pz2AW7tjgodq0ow1jqH1FCwy1FM28rNniSZed1keTCoYTlOLnjfnPAqcSqeF/GIBGxoid1YOG149ppljPtAOb2LgZ7C4z5jyj7EpJisVHjse3AQDV2lQY0Xzlc598SmgJpzLDZ2UXubJWloVq x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 06207960-078b-419f-efe8-08d76e4e8ebd X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2019 06:46:37.6761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: b53Yp7VBnJ+KBdd0N+m1HnXgQFVHrsIB607E8iyRoVbp/gTTvsEAIM+zqXSov2Px8wR7MUyqbsr0StEQ8Snhy2/Rfg0a2Z6VcFY8uzMHWLU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2P265MB0398 Archived-At: Subject: Re: [Add] canary domain and recursion 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, 21 Nov 2019 06:46:43 -0000 PiBPbiAyMSBOb3ZlbWJlciAyMDE5IDE0OjI2IFZpdHRvcmlvIEJlcnRvbGEgPHZpdHRvcmlvLmJl cnRvbGFAb3Blbi14Y2hhbmdlLmNvbT4gd3JvdGU6DQo+DQo+IFBvc3NpYmx5LCBhIGdvb2QgbG9j YWwgcmVzb2x2ZXIgZGlzY292ZXJ5IG1lY2hhbmlzbSBjb3VsZCBwcm92aWRlIGEgc29sdXRpb24g dG8gdGhpcyBwcm9ibGVtLCBhdCBsZWFzdCBpbiBwYXJ0Lg0KDQpJIGFncmVlIHRoYXQgYW4gYWx0 ZXJuYXRlIGFwcHJvYWNoIHdvdWxkIGJlIHByZWZlcnJlZCBhbmQgdGhhdCBtb3ZpbmcgdG8gYSBs b2NhbCByZXNvbHZlciBkaXNjb3ZlcnkgbWVjaGFuaXNtIHNlZW1zIGxpa2UgdGhlIHJpZ2h0IHBs YWNlIHRvIHN0YXJ0LiAgU3VjaCBhIHNvbHV0aW9uIHdvdWxkIGhhdmUgdGhlIGFkdmFudGFnZSBv ZiBsaWtlbHkgZml0dGluZyBiZXR0ZXIgd2l0aCB0aGUgYXBwcm9hY2hlcyB0YWtlbiBieSBHb29n bGUgYW5kIE1pY3Jvc29mdCB0b28uICBBIGNvbnNpc3RlbnQgYXBwcm9hY2ggd291bGQgYmUgbW9z dCBoZWxwZnVsLiAgDQoNCkFuZHJldyANCg0K From nobody Wed Nov 20 23:15:28 2019 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 2BDF2120807 for ; Wed, 20 Nov 2019 23:15:26 -0800 (PST) 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 W5R4WLXn9SEM for ; Wed, 20 Nov 2019 23:15:24 -0800 (PST) Received: from pigeon.groveronline.com (pigeon.groveronline.com [198.145.19.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF8B120133 for ; Wed, 20 Nov 2019 23:15:24 -0800 (PST) Received: by pigeon.groveronline.com (Postfix, from userid 501) id C7DF1608E6; Wed, 20 Nov 2019 23:15:23 -0800 (PST) Received: from [172.16.180.116] (unknown [101.100.166.67]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by pigeon.groveronline.com (Postfix) with ESMTPSA id 8D893601B8 for ; Wed, 20 Nov 2019 23:15:22 -0800 (PST) To: add@ietf.org References: <244D3253-966E-48B0-A099-209951D14D1A@fl1ger.de> <4c46566e-6a1d-6cad-ce05-9f0833b4884d@nic.cz> <1871693264.18877.1574317583456@appsuite-gw2.open-xchange.com> From: Andy Grover Autocrypt: addr=andy@pmtu.dev; keydata= mQENBFz6mPMBCAClDMGqYBeCSE0Q+rU7v0JibtGh+nSZoNTSdXOHUkk3rN7rmJwdjlWsL0aT 2BGsSYBQjuqlculeJAQq6GG8dj7gjkDX8zVvjNPVqZxNd0bRh9DFE5AZrz3TiTIUwNauKWE9 XvVCMn/ZfzEJhehLa7SUs5vgZ6NHaScq4KZByfNsmiu/n+mPRhJOjgIN7fql5u+ElnNHxOP3 Z9vsoQc5pS9YAMKtEvyWgljm4fbZMs6VBDUGJGaLRmALF5VrJ5AJKzbZWZmaXYNqoxdtakT5 PhJuXkqdnrijZw8TJCglQ/z2wiq2HCU2pzq6/l+19yV0m9iegEuPgtAuwqkh4ecsPAbbABEB AAG0IUFuZHkgR3JvdmVyIDxhZ3JvdmVyQG1vemlsbGEuY29tPokBVAQTAQgAPhYhBKVh7hV4 1gY7lZbAkBVqKb2tr6NBBQJc+pjzAhsDBQkDwmcABQsJCAcCBhUKCQgLAgQWAgMBAh4BAheA AAoJEBVqKb2tr6NB7uwH/RIEtXUCpRGCbVO5LyXmlzTCue9djrb8YrvOOyeVzUxA5kIskguB 5DH7X7RuVa1PlsfsG2F40/5/bPS/fjYIUOGxTQdyiXGeVPotDvg4vaC/3zV16gs8YxOgzKgb P7QhFLHkZoITe6gOv4R0QH1qvRkbg9cyyPr5FoIPaLoXDnw4DWxaNBUSsN+fPRI87yUjPO1v kL+OWBOnBsHxNGaHjd/s9WsIUp8RbLbfMEI+xlM8lM+r5ccECkMS/l9NFX+mCMUlRXqTkd49 mWYJWY5zNnLyqbAZcaRGCrFlX/gjDn8p+pXQEdvtbbqy3KMofxrmf73ECSStM0WnOEgWtSFG ycW5AQ0EXPqY8wEIAMY7xc/W7mIt2nyAe9K/5RiuyGaDItuaEbFzfRmxFvISJm3s5LiyyrGA 82o0HQWqoMjPyLd+pGSSxHL5aWCUsj5vt/rV0FCPvC8W3a0bWxHa+sbb0VeAHna18Ozav1Cx RFLW437tqaD8yF5yh1c0aGolCqv2LjMHetm+UmFoQVbSfcJoxpXepJFVDwvrqqlL+5BoQM15 MzCwux/D8RCgNlTXTnlfm6bRvlD5ttgDoyzN7qYwm+RjA9Izhyps39fKzdk8xkgeu/A55C94 KcPuSs4U9ti7WeU+CubDaLB3bxp7KCyjWpX3oS2CxHFnQsBAbzGx8UeH3dXbdni1AjE71wkA EQEAAYkBPAQYAQgAJhYhBKVh7hV41gY7lZbAkBVqKb2tr6NBBQJc+pjzAhsMBQkDwmcAAAoJ EBVqKb2tr6NBP2MH/0g/e3idsu/ajGzRx6CaRd/ZNxG0/p0aYT4iQWUEt0KZVyHKf17OQK2z u3QSGjSR2V1H419U0m5V3HSMQmy5XrGi3ks4f01Cgq2HiYizhwVwqNVfZERY+WavEIr35w/L eJqEI2Cm4PySxbOOuFig6R7GAknL76iKQBlMH8uX7yV9p0JnrI6tn0lm2n4UjW76CJ3Fk6gD wqoDYDQXfIxYtyMD6QUfiSDZ+8KZoCMDYQQsEcDBz0hRI2mHwL1jHkGNMcVOhBZPtUHinFTc EiQKDXQKkBvschbpbcfJI5g82v6Bl5M995ob7wsXy8VN5+usot+bKqQHGYMsBMbqJf+Ci1I= Message-ID: <3bb75fd0-7e20-40ab-970c-ac6ff0fc9183@pmtu.dev> Date: Thu, 21 Nov 2019 15:15:20 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <1871693264.18877.1574317583456@appsuite-gw2.open-xchange.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [Add] canary domain and recursion 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, 21 Nov 2019 07:15:26 -0000 On 11/21/19 2:26 PM, Vittorio Bertola wrote: >> Il 21 novembre 2019 05:57 Warren Kumari ha scritto: >> I really dislike this entire opt-out solution, but if it is used, >> something under .arpa (like others have suggested downstream) seems less bad.... > If I may broaden the discussion a little... > > The introduction of the canary domain was a positive and appreciated > step by Mozilla to deal with the immediate problems caused by their > DoH deployment model. At the same time, however, it is a conceptual > nonsense: if you pick a deployment model that bypasses the local > network and resolver because you do not trust them, then it does not > make sense to ask them whether you should actually turn DoH on or > not. Because the owner of the local network is often not the one running the recursive resolver the network is using, usually the ISP runs it. If the owner wants parental controls to work instead of secure DNS, then that should be honored. The local network owner can block the canary via something on their gateway, or maybe the ISP has some setting for enabling DNS-based parental controls, and doing this also blocks the canary -- for that customer only. As you note below, the scheme falls apart if the ISP blocks the canary for all customers. Since the canary would no longer be an accurate heuristic for the wishes of the local network, it would make sense for the application to stop honoring the canary for that ISP. Therefore it would not be in the interest of the ISP to block the canary for customers others than those that explicitly opt in to parental controls. > (Personally, I think that Mozilla's need for this mechanism is also a > sign that the entire deployment model is conceptually flawed, but I > do not ask them to share this conclusion.) > > It is just a matter of time before some entity that uses the local > resolver in ways Mozilla do not like turns the canary on, and then > they will have to implement additional logic to distinguish proper > and improper uses of the canary, or give up the entire mechanism > altogether. Give it up at least for that ISP. > So, before we get to that point, we should already think at what > could be a better way to deal with a problem which could be > formulated as "distinguishing between good and bad local networks" > or "getting policy indications from the local network in a secure, > authenticated way that could also allow the client to take decisions > on whether to accept or reject them". I'm sure there are better ways, which I'm hoping we can work on designing here. > Possibly, a good local resolver discovery mechanism could provide a > solution to this problem, at least in part. I don't know if it helps this particular problem, but it certainly seems to be an important piece that is missing. Regards -- Andy From nobody Wed Nov 20 23:27:43 2019 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 E7506120960 for ; Wed, 20 Nov 2019 23:27:41 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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=netorgft5189650.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 H_WTknCe4NTY for ; Wed, 20 Nov 2019 23:27:40 -0800 (PST) Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-eopbgr100054.outbound.protection.outlook.com [40.107.10.54]) (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 11BE6120048 for ; Wed, 20 Nov 2019 23:27:39 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IfwURHYDtoU87Q2K8ffKhnkyGoaQD0pprpo/tgD2ropnty1Os288/i+7q5CLqkpKQ1KRSP4OHeJpiqia0VzQ9xgDg8p9+p51YQ1mTCu7lU+/gzz3kVJvz7KhVoZk7FmfASpR7TuIedzzh/72//5srebUtYU8dO+g2OTOUTiPJ6R/rEFh4UCTIEyIF10pO3Bmlz6EuSpmTkPRlypcxhozoFAD1SQ46UagVNu6E9YgozOomavichq9Ci11VLexnlM0Nb7JJON81Mi4qUqrFfl5zNk2gGA1YAL0hJIwrQlBSzGErMJ0k/UrqmlYM6Lurp7t1N/UKJiZJ4oZhUfMary2kw== 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=sgNZAaWMW6HMm8i5ctkMLGgpunnuOjGFinBOD6R3Ado=; b=h5EkhIHgySPVE7GGHEF2AosC3jrc1SmkydiC7dNPImuiGfuInXxL5eSnGBonp3EFnaMLboiUYUqEZE/ZOTamH9R/N22uTeb7nTtyEb9YksA+xAjHPHU4PZsj3vTwalPtln/cik9iVN2xAXtWE85FdTBZ6oDn0nQoa7+HjLrCoMa16M4suM6ez7wwuX/TuvTmOSv9PdR9RkNvnYy1cqIPjncjQyWwcf5MociByN66ThMJNuasOcHYMLodM/IN3MxgXx7JfqhUxVNOQlDWd6iTY5EhAqNDOCqz3dphRi3hchi/l3BdFnoH+S5SmCz8lbDgR0QVt6bIbk40v8+0V/QGjQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=419.consulting; dmarc=pass action=none header.from=419.consulting; dkim=pass header.d=419.consulting; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=NETORGFT5189650.onmicrosoft.com; s=selector1-NETORGFT5189650-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sgNZAaWMW6HMm8i5ctkMLGgpunnuOjGFinBOD6R3Ado=; b=K/sRBgRDNtcg0buDHM9s/U7e4MS7PVua2wG4Bu8K/B6h0of9aq1WbBMCwNWuAbQV4z/v7YgDUdamOH7CDVVCxKLuKotkHMdXL2yKp9okaVECQnDrwjI80TtdNekVIMa1Xk1/ipbHoFhDid24uJZw0LyQqQbvn/Sk76H1Pordzoc= Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM (10.166.85.15) by LO2SPR01MB0024.GBRP265.PROD.OUTLOOK.COM (20.176.155.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2474.16; Thu, 21 Nov 2019 07:27:37 +0000 Received: from LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712]) by LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM ([fe80::11f9:b3d3:221d:6712%7]) with mapi id 15.20.2451.031; Thu, 21 Nov 2019 07:27:37 +0000 From: Andrew Campling To: Paul Ebersman , Joe Abley CC: "add@ietf.org" Thread-Topic: [Add] Draft on deployment models for Internet infrastructure Thread-Index: AQHVnbUJ0tMx3MKmb06riEDS29BqhaeVNdRg Date: Thu, 21 Nov 2019 07:27:37 +0000 Message-ID: References: <20191118020806.AD1D51969BB0@fafnir.remote.dragon.net> <20191119060914.C67ED197521B@fafnir.remote.dragon.net> In-Reply-To: <20191119060914.C67ED197521B@fafnir.remote.dragon.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=andrew.campling@419.consulting; x-originating-ip: [2001:67c:370:128:5855:8e60:995f:4546] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 89e5b691-d53c-4949-afdc-08d76e544904 x-ms-traffictypediagnostic: LO2SPR01MB0024: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(346002)(376002)(39830400003)(199004)(189003)(46003)(508600001)(11346002)(2906002)(446003)(6506007)(25786009)(76116006)(7696005)(76176011)(14454004)(44832011)(6116002)(53546011)(4326008)(8936002)(86362001)(74316002)(81156014)(305945005)(52536014)(81166006)(8676002)(7736002)(110136005)(33656002)(316002)(5660300002)(6246003)(71200400001)(14444005)(9686003)(71190400001)(256004)(186003)(102836004)(229853002)(66946007)(66476007)(66556008)(64756008)(66446008)(6436002)(99286004)(55016002)(46492004); DIR:OUT; SFP:1101; SCL:1; SRVR:LO2SPR01MB0024; H:LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: 419.consulting does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BddleRDlwp6H29uANLrYXZ0KrtQNoCJcUnX1HJjvBvCvKo5kR43r95k3fUUIpwdSCqpIW8v9CQrmJcuUbiSXdSmqPA4k/gOQlYQuPWMGzUPjZMbEBqXZ0LzrEXeNv3MSoBxdd4XC7d7MYX2iYWBgKQAMIFLjP9zgNhCnvsm/A2isPPzSEHemlYYCBM5x4LfEWf5mixtxhfyNeN4S2X0+VfwHkivanFkf73QIlI94Qk8YmbcRodj5olyu0oY+PHKmyJ4UW9zJ1o3mwWpNkzUtt4w4+hwsUgQ6ISB4BlyKsDePoAXw9dildwWE1VQg3m9IiZprkVnud51TjR9Ep8s1dwGtl5Z4mGC9HBimAfM6W08ZWz2x0JxyJr7PrZgzcDGivLo8AwnLgG4sHEW6K3a3O64ctCNMLVya+4US1kBapcElaotJneYmJnqGj0F+p4/+ x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: 419.consulting X-MS-Exchange-CrossTenant-Network-Message-Id: 89e5b691-d53c-4949-afdc-08d76e544904 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2019 07:27:37.5118 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9c2ced3e-7522-4755-87dc-f983abc66ec3 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: ssvKVDwXaBP12Hi8o/JAQmYCGdR9GboOxX4+vOVG/VlddH7wlx3sAQ5U/fFq2Kv6ozH8c9nQJfgAFOrB3h+OdihsTRZPM0OAqvVGVqxlS7w= X-MS-Exchange-Transport-CrossTenantHeadersStamped: LO2SPR01MB0024 Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 21 Nov 2019 07:27:42 -0000 > On 19 November 2019 14:09 Paul Ebersman wrote: > >> On 19 Nov 2019, at 05:23, Joe Abley wrote:=20 >> The problem with VPNs in general is that naive users (most >> users) have no good way to trust their tunnel termination=20 >> points. There are also fewer termination points than there are=20 >> potential users, so this is another example of centralisation=20 >> which in general I think is reasonable to be considered at odds=20 >> with privacy. Surely the Issue with trust applies to DoH resolvers too? Possibly more so= given apps may opt to use DoH without user knowledge or consent? The degr= ee of centralization from VPNs is far less of an issue given the many avail= able suppliers, each of which typically has many servers in many countries.= =20 > Tor and VPN certainly have issues also, but DoH (and any other=20 > DNS query/response encryption) is insufficient protection, since=20 > the following web/email/app traffic isn't necessarily encrypted.=20 > Other tech that encrypts everything is still needed. Agreed. Also use of VPNs is far more transparent, with the user able to swi= tch it on and off at will, maintaining clarity of when traffic is being rou= ted without having to configure each app individually. For the dissident u= se case, such simplicity, clarity and user control seems to me to be of par= amount importance. =20 Andrew=20 From nobody Thu Nov 21 13:48:39 2019 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 8D6D8120142 for ; Thu, 21 Nov 2019 13:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 IleBFC7tOQ1W for ; Thu, 21 Nov 2019 13:48:35 -0800 (PST) Received: from mail-io1-xd2f.google.com (mail-io1-xd2f.google.com [IPv6:2607:f8b0:4864:20::d2f]) (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 391AE120045 for ; Thu, 21 Nov 2019 13:48:35 -0800 (PST) Received: by mail-io1-xd2f.google.com with SMTP id z193so5363991iof.1 for ; Thu, 21 Nov 2019 13:48:35 -0800 (PST) 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=a7DoY/Xq0bI8MY4peb9C1VdxURh9Ic9mT+QhaF5bDj0=; b=cDSyu12HPTQl+vHkexcT1f8ZZ1Gij46rcngB34gDyP7dvQ9D9QXrDm2cJapOjQo2ZF G/hKE2ryMK9yWLUT0GgxxCeZtHcKWpq3RCb+7sEInzTrxAp8oRFrDUa+dnJTDPOcVgQw Z59Y9jlYKL8JEMPk9E0E9OoZpaaVKH2FZamMISe1BDKLt9q5AbGIH+5CbqIdenwSt/J9 M0DPTL6h/qvcLiLL/UefbQEXORSasgoB1MZjTUbNzsG2tm7p25nNyLcuTxItjMW7sx7e EqYJ6YrB+iMsNhpp/vLEXRq8y7HEWxv3Ed2Pfdg9ip11ihtmTVydsfdUhM4KwWENNV2A prjQ== 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=a7DoY/Xq0bI8MY4peb9C1VdxURh9Ic9mT+QhaF5bDj0=; b=dEmiRuScpePxP+gVtGAzf9x5SPAJv6Jal60j3YjqP9lsSResMNIUBf8Zf0+5YEQzkv Ncv1EKccjT0XaO5TzvXO2QJeAUH2cl9X1DpYufuF9oyiVEC3O/XCpWWPSKvvLYmEYwyS zSfs5dPvGgLRiwbA/6rSjHIkwZxyVzURVoJkUuh59o8UYwH/S27ntNeVTLHLbt1gfzPG r/nCEvOwOxUeHPIpBn6EZvQWM5bS7JjpVSJqFXPrSZZCpRMt2t6Mc8AmffqzYfUMMMI7 sbWd4nK+X7dZdOyi7RqJWmge4bcFareu1bOJigASFasX6neJ0/z5ImuJg2+hba45Y46d x6MA== X-Gm-Message-State: APjAAAWMn07BWjjCJElrXTqynn2t/jMZ9F1RquI/OnAIfotPI21dNCOC PH5EMsu7O04Y5p10IZtiR2+p/jiAZ1CGZ5k1pARlQSlZ X-Google-Smtp-Source: APXvYqwzQkJFwjXMfi4kRzW9UQfamC0qXnSgWKyYZW+iVsUm5K37JTgzC6Nn3shCvlrtbueMpWAKCc0fDkcLzl1SpqA= X-Received: by 2002:a02:740a:: with SMTP id o10mr11204917jac.106.1574372914218; Thu, 21 Nov 2019 13:48:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Thu, 21 Nov 2019 13:48:22 -0800 Message-ID: To: Tony Finch Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000004bcc920597e24272" Archived-At: Subject: Re: [Add] communicating DNS configuration 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, 21 Nov 2019 21:48:38 -0000 --0000000000004bcc920597e24272 Content-Type: text/plain; charset="UTF-8" On Wed, Nov 20, 2019 at 6:38 AM Tony Finch wrote: > Rob Sayre wrote: > > > > It seems to me that it's somewhat novel and unwise for the IETF to insert > > itself in the negotiation of DNS behavior between the operating system > and > > applications. To the extent that kind of thing can be standardized, isn't > > it better suited to something like The Open Group? > > RFC 3493 specifies getaddrinfo() but I don't know if the IETF still claims > change control over the API. > > (It's kind of annoying that there used to be an almost de facto standard > in the BIND4 resolver API that made it possible to dig the server IP > address out of the resolver state structure, but implementations diverged > significantly when adding IPv6 support so that isn't possible any more. > Which makes it relatively hard for applications to get clever (e.g. > concurrent queries, validation, etc.) while co-operating with the > operating system resolver. And of course there's the issue of co-operating > with non-DNS name resolution such as /etc/hosts, SMB, etc...) > I asked about this issue on the dprive list once, fwiw: https://mailarchive.ietf.org/arch/msg/dns-privacy/ATxeUHBKpef27mvOjJypYigSK3o Assuming that description is accurate, I'm not sure API suggestions make sense in a standards track document (if that's what the goal is here...). thanks, Rob --0000000000004bcc920597e24272 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Nov 20, 2019 at 6:38 AM Tony Finc= h <dot@dotat.at> wrote:
=
Rob Sayre <sayrer@gmail.com> wrote:<= br> >
> It seems to me that it's somewhat novel and unwise for the IETF to= insert
> itself in the negotiation of DNS behavior between the operating system= and
> applications. To the extent that kind of thing can be standardized, is= n't
> it better suited to something like The Open Group?

RFC 3493 specifies getaddrinfo() but I don't know if the IETF still cla= ims
change control over the API.

(It's kind of annoying that there used to be an almost de facto standar= d
in the BIND4 resolver API that made it possible to dig the server IP
address out of the resolver state structure, but implementations diverged significantly when adding IPv6 support so that isn't possible any more.=
Which makes it relatively hard for applications to get clever (e.g.
concurrent queries, validation, etc.) while co-operating with the
operating system resolver. And of course there's the issue of co-operat= ing
with non-DNS name resolution such as /etc/hosts, SMB, etc...)

I asked about this issue on the dprive list once, fwiw:https://mailarchive.ietf.org/arch/msg/dns-privacy/ATxeUHBK= pef27mvOjJypYigSK3o

Assuming that description is accurate, I'= ;m not sure API suggestions make sense in a standards track document (if th= at's what the goal is here...).

thanks,
Rob

--0000000000004bcc920597e24272-- From nobody Thu Nov 21 15:37:49 2019 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 44D6B12011D for ; Thu, 21 Nov 2019 15:37:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.499 X-Spam-Level: X-Spam-Status: No, score=-17.499 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, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMQW1WrG-LmK for ; Thu, 21 Nov 2019 15:37:45 -0800 (PST) Received: from mail-wm1-x329.google.com (mail-wm1-x329.google.com [IPv6:2a00:1450:4864:20::329]) (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 E8E7212080C for ; Thu, 21 Nov 2019 15:37:44 -0800 (PST) Received: by mail-wm1-x329.google.com with SMTP id n188so3709970wme.1 for ; Thu, 21 Nov 2019 15:37:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=5+ba9OTGISj35hW0Cjgii23RIzaF4w1Gk6nu+dSGH2c=; b=CUXVTUcu4tZj20xkJCNsFA6mBVVUZgas302/DSDgePAtDKlXtn6tLAaRQqyq6y/8dn 5QN35AiHcr9dE4xfnoC25IjqfT/4l/elqADpF6bGF3luXpXYEVqs6hjOpyTQK7TX1eeT +sAn6gcIlNEU4lP9G4X0KYlE6Eu8D0MhEUvxM5d6R9QkKtUxeCkS4jadvlS1vMyAXgY4 Z+gGqHRk6rop6QT+gxElq0LbkIbvpu6Psa3TD1MC/7tiy5qRRujidsHNOVs8fAQgOsz2 tbNvGUhOmMLOc21jOQ31NbvyGs/4FSkz91RuC9KmrcQtYjcEfTGyVTcuGMA9JJIRxmVf CRnw== 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=5+ba9OTGISj35hW0Cjgii23RIzaF4w1Gk6nu+dSGH2c=; b=pPI2IaKh93U9r8Gbv9X9PcCIa6oz5ZF8pe5U3J6QdQCKFJwK13sK9uSkkKFMBOAuqR 41jepyP6v4V67cw4ISA5xuAXIdDijoQzYKanAu/ggNAAYl+4vBykrZI87GsYdy88Fuhg Ajk5qctIk+RTM6J4oBnoobEsL2mdWY1Om5Qx93qUIBU1B3E9KWVBumwLeVP40bsty15Y osrvIZiEof1bNZyvnu624/qhSq3rvAFZNd32xoMc75u5idNGXyPMr73f/eVXY4eT3zqI 6gsRxuq9A225VZ36KnxiNlKuLjm1RBPCqUay4OMm+bRrjC29eOwCNTLRa+0GODUahXd5 2pgQ== X-Gm-Message-State: APjAAAVC676+V5mAJk/AXm9D5WEdHp+2w+OKkElc9CmLjEGDlp8rWFGy 2L1ha7pJVTcIkEsuc2/vAnSPkCf2C8qQk7jZs8K5NtBLBb0= X-Google-Smtp-Source: APXvYqyNa3QDXJuMe5jDxrAII9nXUrGLpseWP08O4TIOnGcFtOxUDYwHxgP86gxf5OXEXrVov9ljjNHBPX4FgLmCvDI= X-Received: by 2002:a05:600c:2945:: with SMTP id n5mr14058648wmd.80.1574379462761; Thu, 21 Nov 2019 15:37:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Eric Orth Date: Fri, 22 Nov 2019 07:37:31 +0800 Message-ID: To: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000009f12780597e3c85d" Archived-At: Subject: Re: [Add] communicating DNS configuration 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, 21 Nov 2019 23:37:48 -0000 --0000000000009f12780597e3c85d Content-Type: text/plain; charset="UTF-8" The only precedence I can think of are the getaddrinfo RFCs, and those were only ever informational. While I really hope some new OS APIs for DNS configuration can be standardized, I don't think IETF has the right expertise to be the primary body for that work. On Fri, Nov 22, 2019, 5:48 AM Rob Sayre wrote: > > On Wed, Nov 20, 2019 at 6:38 AM Tony Finch wrote: > >> Rob Sayre wrote: >> > >> > It seems to me that it's somewhat novel and unwise for the IETF to >> insert >> > itself in the negotiation of DNS behavior between the operating system >> and >> > applications. To the extent that kind of thing can be standardized, >> isn't >> > it better suited to something like The Open Group? >> >> RFC 3493 specifies getaddrinfo() but I don't know if the IETF still claims >> change control over the API. >> >> (It's kind of annoying that there used to be an almost de facto standard >> in the BIND4 resolver API that made it possible to dig the server IP >> address out of the resolver state structure, but implementations diverged >> significantly when adding IPv6 support so that isn't possible any more. >> Which makes it relatively hard for applications to get clever (e.g. >> concurrent queries, validation, etc.) while co-operating with the >> operating system resolver. And of course there's the issue of co-operating >> with non-DNS name resolution such as /etc/hosts, SMB, etc...) >> > > I asked about this issue on the dprive list once, fwiw: > > https://mailarchive.ietf.org/arch/msg/dns-privacy/ATxeUHBKpef27mvOjJypYigSK3o > > Assuming that description is accurate, I'm not sure API suggestions make > sense in a standards track document (if that's what the goal is here...). > > thanks, > Rob > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > --0000000000009f12780597e3c85d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The only precedence I can think of are the getaddrin= fo RFCs, and those were only ever informational.=C2=A0 While I really hope = some new OS APIs for DNS configuration can be standardized, I don't thi= nk IETF has the right expertise to be the primary body for that work.
On Fri, = Nov 22, 2019, 5:48 AM Rob Sayre <say= rer@gmail.com> wrote:

On Wed, Nov 20, 2019 at 6:38 AM Tony Finch &l= t;dot@= dotat.at> wrote:
Rob Sayre <sayrer@gmail.com> wrote:
>
> It seems to me that it's somewhat novel and unwise for the IETF to= insert
> itself in the negotiation of DNS behavior between the operating system= and
> applications. To the extent that kind of thing can be standardized, is= n't
> it better suited to something like The Open Group?

RFC 3493 specifies getaddrinfo() but I don't know if the IETF still cla= ims
change control over the API.

(It's kind of annoying that there used to be an almost de facto standar= d
in the BIND4 resolver API that made it possible to dig the server IP
address out of the resolver state structure, but implementations diverged significantly when adding IPv6 support so that isn't possible any more.=
Which makes it relatively hard for applications to get clever (e.g.
concurrent queries, validation, etc.) while co-operating with the
operating system resolver. And of course there's the issue of co-operat= ing
with non-DNS name resolution such as /etc/hosts, SMB, etc...)

I asked about this issue on the dprive list once, fwiw:https://mailarchive.i= etf.org/arch/msg/dns-privacy/ATxeUHBKpef27mvOjJypYigSK3o

Assumin= g that description is accurate, I'm not sure API suggestions make sense= in a standards track document (if that's what the goal is here...).

thanks,
Rob

--
Add mailing list
Add@ie= tf.org
https://www.ietf.org/mailman/listinfo/add
--0000000000009f12780597e3c85d-- From nobody Thu Nov 21 16:04:44 2019 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 C6C27120129 for ; Thu, 21 Nov 2019 16:04:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.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 fLMm6Pw3H8Tl for ; Thu, 21 Nov 2019 16:04:41 -0800 (PST) Received: from mail-oi1-x22e.google.com (mail-oi1-x22e.google.com [IPv6:2607:f8b0: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 B4633120091 for ; Thu, 21 Nov 2019 16:04:41 -0800 (PST) Received: by mail-oi1-x22e.google.com with SMTP id n16so4940123oig.2 for ; Thu, 21 Nov 2019 16:04:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc; bh=HVHsv/Bc98biHbMmLGUCku0QaQmUXXQM+NnHdpwKtwY=; b=mPjm8oqsns6dbkJqQ1jUm/JM9c/FBX35Q9OQsLF9BsKuFubpZXIk8UkFhdTD9Gm4dH s7swWwcsNx4ELtgMuwVKWBMB9gF08sMrOQlyu/WYlXQBXqmdTkJk7Xy4cEht2lbBLiDF xmbaoxwtEiGa9H5wjG57XYfQq17upME2jwj1Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc; bh=HVHsv/Bc98biHbMmLGUCku0QaQmUXXQM+NnHdpwKtwY=; b=Jmvj0DWdyPQN8dNwzitVdrY0GKzAtaH5PUzTdSSiuCxuQehK6FLXq9NR9u8NieeX/R c0JdtUfNdcZ7Ro5Dl8p0wwiFEhwC17VlJGgIG0P75m9dVc6m0PKLlByYwnAoaFx4gd/9 fs9o4JNk/wOoMYxLk83DxZSTgAYvutWsWW5OIZIXFQVcmTy2OJRv7GyoZzvNPlNmVL+a Bgj992xiZCNQvQCPKVT4OhOG6DIjzIQ98xfexTIDwlZFjRCrbUCVjTAd0cBb75z7C1vh ya+tCqfQl+ohkHHPWVd53fIP1hjVn742FatD6Ob2KOkTgg0L7B+rGzEr37C0+exzIXpO ICGQ== X-Gm-Message-State: APjAAAW2KdZt8zeYcVUqe38XUpoYG8YDuYVDavUWQwSExqbe/7CTfmzQ eEPSKqAb+FCWBpMrXoRsogAHneJmei5JX0wTTaMxpA== X-Google-Smtp-Source: APXvYqyMCTSAtXTbqiM0PjCSZz/8SjiXOD1KlGLdnbGGw5y0XDbuOLIs7eQDjwaMQXGDXo9pBuwbpxq8RRlSzbLQRLY= X-Received: by 2002:aca:2811:: with SMTP id 17mr9557155oix.46.1574381080875; Thu, 21 Nov 2019 16:04:40 -0800 (PST) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Nov 2019 16:04:40 -0800 From: Joe Abley Mime-Version: 1.0 (1.0) References: In-Reply-To: Date: Thu, 21 Nov 2019 16:04:40 -0800 Message-ID: To: Rob Sayre Cc: ADD Mailing list Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Add] communicating DNS configuration 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, 22 Nov 2019 00:04:43 -0000 On Nov 20, 2019, at 07:31, Rob Sayre wrote: > Refinements on DHCP options and such seem like fair game, though. There's surely an interpretation of "DHCP options and such" that actually means "communicating parameters between the network and applications." For example, section 8 of RFC 2132 is entitled "Application and Service Parameters" and describes DHCP options for configuring lots of things that I would call applications. Joe From nobody Thu Nov 21 16:34:23 2019 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 E4EBB120180 for ; Thu, 21 Nov 2019 16:34:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 NS6p8Vz8Nvvf for ; Thu, 21 Nov 2019 16:34:18 -0800 (PST) Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (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 215501200B6 for ; Thu, 21 Nov 2019 16:34:18 -0800 (PST) Received: by mail-qt1-x832.google.com with SMTP id y10so5882510qto.3 for ; Thu, 21 Nov 2019 16:34:18 -0800 (PST) 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=yaX5pHbIk57pOtjgg3GR3g7/ttch0U07BNIM+RbvIqk=; b=tQmPcfdsuC0THu1hzIFsSb1vwr8JNF2d4q3D6looMnQOAzEBvFPSOYq1yEJKYow6eC zSlvWhgHRi3q4ImVT+dC1VU9IY79uF8+iQaVRC7Cx4/zOxY/Z8FKeG8NK0PRgrIo2LLC 8vf141+DR/ezPdpDX5IT0pY4I/ftoge8ABMshkYZ5NbX4JuNw2jBwKDQ9ePwoiVlfG4s 1P6AYBc0vb1QyoinDvKWPoJhuaR6TgTv29WwSmQr2xmBpWYiUK9/Dt8/hP06i0LpgODp nwWmIkMiuBKXAq6XtSzx2iEYmdDN1pDx8AbCMJ85F88FMHbii0aNF+hC4m+2ARx/NUn3 W0cw== 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=yaX5pHbIk57pOtjgg3GR3g7/ttch0U07BNIM+RbvIqk=; b=iU0jGco1ZT7GwGh96/kDhv5TMUb31RU/Pv8WdulJT0+oNPBm/N2nXR73baXRIR2PWF pJkLBg4K/ItecbTrnIun/NrFC1p4bfbCsqCaHEVkAD/DQh4lg38fN9NEgoNGXKbicsAq HLBEKkJK5x7+ThN3npIT42pUf7M/el+KUB5reUsF4t44LYe1KPis7NrgQ608nhvfiknR pUdL1WUyVDM80/c7WZyR/pp604oZ3m6t636/VpRBhuhSQxmToooa1NMZJb6S+ToT/ekM P7AMr7b9y1MnRhQrmsCn/23jMI/FnAdL+nOFcTu946sL+rKypfFoZy9+b35i3EyHOwog 4YuA== X-Gm-Message-State: APjAAAU6EiL6hxK+lutGPK2lVeT5wA3X1Y48osJ6VQQlbt1e5kbcRfq8 zaF4pyDY1vXswmuJI+XozhCWQUcVtGQLSF2ag0yrezEQchg= X-Google-Smtp-Source: APXvYqyaSIFqmvhGslIAEpPKo33P5xDh7iHb7rIawR67BgSUg6iJpV6AGmyJckp8kpQlUmLXfNKoMmil5axLa16DNwk= X-Received: by 2002:ac8:6683:: with SMTP id d3mr6043317qtp.326.1574382856858; Thu, 21 Nov 2019 16:34:16 -0800 (PST) MIME-Version: 1.0 References: <20191118020806.AD1D51969BB0@fafnir.remote.dragon.net> <20191119060914.C67ED197521B@fafnir.remote.dragon.net> In-Reply-To: From: Alec Muffett Date: Fri, 22 Nov 2019 00:33:40 +0000 Message-ID: To: Andrew Campling Cc: Paul Ebersman , Joe Abley , "add@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ec78d20597e49246" Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 22 Nov 2019 00:34:21 -0000 --000000000000ec78d20597e49246 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Regards messages like this: On Thu, 21 Nov 2019 at 07:27, Andrew Campling wrote: >> On 19 November 2019 14:09 Paul Ebersman wrote: >>> On 19 Nov 2019, at 05:23, Joe Abley wrote: >>> The problem with VPNs in general is that naive users (most >>> users) have no good way to trust their tunnel termination >>> points. There are also fewer termination points than there are >>> potential users, so this is another example of centralisation >>> which in general I think is reasonable to be considered at odds >>> with privacy. > Surely the Issue with trust applies to DoH resolvers too? Possibly more so given apps may opt to use DoH without user knowledge or consent? The degree of centralization from VPNs is far less of an issue given the many available suppliers, each of which typically has many servers in many countries. >> Tor and VPN certainly have issues also, but DoH (and any other >> DNS query/response encryption) is insufficient protection, since >> the following web/email/app traffic isn't necessarily encrypted. >> Other tech that encrypts everything is still needed. > Agreed. Also use of VPNs is far more transparent, with the user able to switch it on and off at will, maintaining clarity of when traffic is being routed without having to configure each app individually. For the dissident use case, such simplicity, clarity and user control seems to me to be of paramount importance. ...and this: ebersman> Agreed. Tor/VPN and similar solve the dissident case; DoH is an insufficient protection against state actors or folks with similar resources. ...these exchanges betray some shocking misconceptions of how information and network security actually work in the real world. For instance: - there is no such thing as "solved" in network security; nor is there any such thing as "perfect security" - because there's generally a means to bypass ANY system security, so long as one is willing to spend enough money on the problem. Indeed, the deep truth of information security is that is a cost/benefit war. - So the "sufficiency" of value of DoH is that it is better than either Do53 or DoT for some "dissident" (and: normal user) use-cases. That's all that DoH needs to be: not "perfect", simply "better, for anti-censorship purposes, than the extant protocol". It's no more reasonable to say "DoH is an imperfect, insufficient protection against state actors" than to say "motorcycle helmets are useless, they're just not adequate to protect you under combat conditions". The actual question is what your motorcycle helmet - or DoH - enables you to achieve under your given circumstances, that you could not do previously. In combat conditions or otherwise. - Conversely: anyone who believes that Tor is some magic-wand-waving panacea for dissidents, is again being presumptuous about dissident needs in a manner akin to the apocryphal "let them eat cake" of legend*; motivated nation states can be very successful at blocking access to Tor at a nation state level, and the only strategy which works in the face of such is to give the nation state many more and wondrously varied, "harder-than-average-to-block" protocols to deal with. This will increase the state's work-factor - it will increase the state's *cost* of censorship= . Similarly, re: > The problem with VPNs=E2=80=A6is that naive users=E2=80=A6have no good wa= y to trust their tunnel termination points. =E2=80=A6 this is another example of centralisat= ion which in general I think is reasonable to be considered at odds with privacy. ...it does not advance our discussion to have statements that contain zero discussion of whom the user is attempting to be private *from*. Without clearly stating a "threat model" - the presumptions of what the user will want to achieve - there can be no meaningful way to judge the value (or otherwise) of the proposed solution. I would like to invite other readers ADD to go visit this thread on Twitter= : https://twitter.com/Ammir/status/1196786007225622528 https://twitter.com/Ammir/status/1196798148095725568 https://twitter.com/Ammir/status/1196801992322142208 https://twitter.com/Ammir/status/1196870201121345547 https://twitter.com/Ammir/status/1196897012278595589 https://twitter.com/Ammir/status/1196923749515382784 ...which describes that: Tor is being gradually blocked in Iran, that Skype and Viber are being likewise, and that people in the street are sharing software of dubious provenance because their own, and that other extant tools are not sufficiently censorship-resistant. Feel free to read around the topic, too; lots of people have opined on this list, re: what works and does not work in state censorship. Feel free to go check out your theories, it's a "good" time to do so. Further down, Andrew writes: "For the dissident use case, such simplicity, clarity and user control seems to me to be of paramount importance." Higher than that, higher than all of those "paramount" things is "access" - because a smartphone which cannot connect is far less useful. The likes of Skype or Viber, when they hypothetically become DoH-enabled "Applications Doing DNS", will greatly increase the work factor of the Iranian government pursuing censorship - and the obvious "reactionary-tech-nerd" response of "Yes but the Iranian Government will simply traffic-fingerprint Viber, and block it, so making Viber DoH-enabled is pointless!" - will yet again miss the point. The point being: the Iranian Government wouldhave to *do* that. DoH would mean that they have to work harder, thereby increasing their cost. Which is the whole point of the exercise, and anyone who does not expound from that perspective, is not a security person. And we still want to give such nation states the ability to turn-off DoH, upstream? To restrict the ability of Apps to perform their own name-resolution? - alec * https://en.wikipedia.org/wiki/Let_them_eat_cake -- http://dropsafe.crypticide.com/aboutalecm --000000000000ec78d20597e49246 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Regards messages like th= is:

On Thu, 21 Nov 2019 at 07:27, Andrew Campling <andrew.camplin= g@419.consulting> wrote:
>> On 19 November 2019 14:09 Paul Eber= sman <list-add@dragon.net>= wrote:
>>> On 19 Nov 2019, at 05:23, Joe Abley wrote:
>&= gt;> The problem with VPNs in general is that naive users (most
>&= gt;> users) have no good way to trust their tunnel termination
>&g= t;> points. There are also fewer termination points than there are
&g= t;>> potential users, so this is another example of centralisation>>> which in general I think is reasonable to be considered at od= ds
>>> with privacy.
> Surely the Issue with trust a= pplies to DoH resolvers too?=C2=A0 Possibly more so given apps may opt to u= se DoH without user knowledge or consent?=C2=A0 The degree of centralizatio= n from VPNs is far less of an issue given the many available suppliers, eac= h of which typically has many servers in many countries.

>> To= r and VPN certainly have issues also, but DoH (and any other
>> DN= S query/response encryption) is insufficient protection, since
>> = the following web/email/app traffic isn't necessarily encrypted.
>= ;> Other tech that encrypts everything is still needed.
> Agreed.= Also use of VPNs is far more transparent, with the user able to switch it = on and off at will, maintaining clarity of when traffic is being routed wit= hout having to configure each app individually.=C2=A0 For the dissident use= case, such simplicity, clarity and user control seems to me to be of param= ount importance. =C2=A0

...and this:

ebersman> Agreed. Tor= /VPN and similar solve the dissident case; DoH is an insufficient protectio= n against state actors or folks with similar resources.

...these exc= hanges betray some shocking misconceptions of how information and network s= ecurity actually work in the real world.

For instance:=C2=A0

- there is no such thing as "solved" in network= security; nor is there any such thing as "perfect security" - be= cause there's generally a means to bypass ANY system security, so long = as one is willing to spend enough money on the problem.=C2=A0 Indeed, the d= eep truth of information security is that is a cost/benefit war.

- S= o the "sufficiency" of value of DoH is that it is better than eit= her Do53 or DoT for some "dissident" (and: normal user) use-cases= .=C2=A0 That's all that DoH needs to be: not "perfect", simpl= y "better, for anti-censorship purposes, than the extant protocol"= ;. It's no more reasonable to say "DoH is an imperfect, insufficie= nt protection against state actors" than to say "motorcycle helme= ts are useless, they're just not adequate to protect you under combat c= onditions". The actual question is what your motorcycle helmet - or Do= H - enables you to achieve under your given circumstances, that you could n= ot do previously.=C2=A0 In combat conditions or otherwise.

- = Conversely: anyone who believes that Tor is some magic-wand-waving panacea = for dissidents, is again being presumptuous about dissident needs in a mann= er akin to the apocryphal "let them eat cake" of legend*; motivat= ed nation states can be very successful at blocking access to Tor at a nati= on state level, and the only strategy which works in the face of such is to= give the nation state many more and wondrously varied, "harder-than-a= verage-to-block" protocols to deal with.=C2=A0This will increase the s= tate's work-factor - it will increase the state's *cost* of censors= hip.

Similarly, re:

> The problem with VPNs=E2=80=A6is tha= t naive users=E2=80=A6have no good way to trust their tunnel termination po= ints. =E2=80=A6 this is another example of centralisation which in general = I think is reasonable to be considered at odds with privacy.

...it d= oes not advance our discussion to have statements that contain zero discuss= ion of whom the user is attempting to be private *from*. Without clearly st= ating a "threat model" - the presumptions of what the user will w= ant to achieve - there can be no meaningful way to judge the value (or othe= rwise) of the proposed solution.

.= ..which describes that: Tor is being gradually blocked in Iran, that Skype = and Viber are being likewise, and that people in the street are sharing sof= tware of dubious provenance because their own, and that other extant tools = are not sufficiently censorship-resistant.=C2=A0Feel free to read around th= e topic, too; lots of people have opined on this list, re: what works and d= oes not work in state censorship.=C2=A0 Feel free to go check out your theo= ries, it's a "good" time to do so.


Further down, A= ndrew writes: "For the dissident use case, such simplicity, clarity an= d user control seems to me to be of paramount importance."

High= er than that, higher than all of those "paramount" things is &quo= t;access" - because a smartphone which cannot connect is far less usef= ul.

The likes of Skype or Viber, when they hypothe= tically become DoH-enabled "Applications Doing DNS", will greatly= increase the work factor of the Iranian government pursuing censorship - a= nd the obvious "reactionary-tech-nerd" response of "Yes but = the Iranian Government will simply traffic-fingerprint Viber, and block it,= so making Viber DoH-enabled is pointless!" - will yet again miss the = point.

The point being: the Iranian Government wouldhave to *do* tha= t.=C2=A0 DoH would mean that they have to work harder, thereby increasing t= heir cost. =C2=A0

Which is the whole point of the exercise, and anyo= ne who does not expound from that perspective, is not a security person.
And we still want to give such nation states the ability to turn-off D= oH, upstream? To restrict the ability of Apps to perform their own name-res= olution?
<= /div>
--000000000000ec78d20597e49246-- From nobody Thu Nov 21 16:35:47 2019 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 67C48120129 for ; Thu, 21 Nov 2019 16:35:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 PgrKwOe89qfj for ; Thu, 21 Nov 2019 16:35:44 -0800 (PST) Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 E3C251200B6 for ; Thu, 21 Nov 2019 16:35:43 -0800 (PST) Received: by mail-io1-xd2a.google.com with SMTP id v17so5870604iol.12 for ; Thu, 21 Nov 2019 16:35:43 -0800 (PST) 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=Kk7NtaDXJeLKr5X1dI0CP93eCBHJhNNISUY8tmwDUsA=; b=hgE9/HPGJBuCsd7J5esxn2XMjxawOg3+J16kbwiZsMpn5Bx/SxQQ2Z1Vb6y/hhk7hb QZG5Tuf0Wsogbl5Wcc7h7e8K8iv/4kFW50UAioXymFg1m6HLpn8Pr2MDTgmG6nbTjHsA dUESzH1h3/7qwQyJP4PjZ3CGKtFhG+VpiMI2q/TW4YnXngM5iGaDMlM2gDr/RGh8Wr4r QO9HTDZGSGjjIUbEPpAYyQoWt1yXyxIrJziT/EupR3BqK2ROV5NhpGk04fQ/aQNQO641 VKxEyepHHKlRrC/gxtA6VX8JOohR8p6GvqVZv1k2HFjTJoTVGOdwj5c/UFc3fS3LEfo2 HlQw== 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=Kk7NtaDXJeLKr5X1dI0CP93eCBHJhNNISUY8tmwDUsA=; b=aq8sc1QFsMppj22V9xBX9ULY7xcuO35fPOgVKde6vTuVEMfXSZ/GJ9hjz53QJYclbz O7JCYXpb+ue0++V0MguKn7Kh+h/0TQbD/wupUpLPhP7Vc4hE5IjIeF1qqIXgueAI5D0P RNHU6KH1hMkDcBUnx4021Cl9Q76yMLlnZRUYwPFQmmu7dE4zh6RdGtLNCoF0Np0idUYh yt8hvpoZJ9cKXeKiOP4MhVCdza5z6prmh9UtUP38P3YFLigJEPA3ZMW4UfiVC+WXA9Mb Ozp5nAhU0IGoLEOUxs1ve+b1N4k1vNDfR6Oy96/2qBsnVz+HoZY417S2z5iPZox9tgsB CcAg== X-Gm-Message-State: APjAAAXG81bZU07Me1Bjk+MxzMzOZ+VdDEN6DIeiAo/6xhfNPJfoVFxv T4y+2xzihw/yS7BlqTnP14O3E9M+/3dHgVI0YpCGPOsq X-Google-Smtp-Source: APXvYqxw9ZRSWT3T2JIMyV6aBDiVYeuBNE+GW7PL4nSaYMq/66zcfdw0I6sxsQPghrEzwAs15pMfMBZ1Gn1P9Vel3Fk= X-Received: by 2002:a5d:9555:: with SMTP id a21mr360188ios.49.1574382943105; Thu, 21 Nov 2019 16:35:43 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rob Sayre Date: Thu, 21 Nov 2019 16:35:31 -0800 Message-ID: To: Joe Abley Cc: ADD Mailing list Content-Type: multipart/alternative; boundary="0000000000001079960597e4989e" Archived-At: Subject: Re: [Add] communicating DNS configuration 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, 22 Nov 2019 00:35:46 -0000 --0000000000001079960597e4989e Content-Type: text/plain; charset="UTF-8" On Thu, Nov 21, 2019 at 4:04 PM Joe Abley wrote: > On Nov 20, 2019, at 07:31, Rob Sayre wrote: > > > Refinements on DHCP options and such seem like fair game, though. > > There's surely an interpretation of "DHCP options and such" that > actually means "communicating parameters between the network and > applications." > I agree. There are three relations here: Network -> OS Network -> Application OS -> Application It's only the last one that strikes me as something the IETF might not be the right venue for. It occurs to me that the charter might have only been intended to cover the first two. Some wordsmithing to make it clear what's in scope is probably needed, but I'm hesitant to suggest anything, because I don't know what the intent was. thanks, Rob --0000000000001079960597e4989e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 21, 2019 at 4:04 PM Joe Abley= <jabley@hopcount.ca> wrote= :
On Nov 20, 2019, at 07:31, Rob Sayre <sayrer@gmail.com> wrote:

> Refinements on DHCP options and such seem like fair game, though.

There's surely an interpretation of "DHCP options and such" t= hat
actually means "communicating parameters between the network and
applications."

I agree. There are = three relations here:

Network -> OS
N= etwork -> Application
OS -> Application

It's only the last one that strikes me as something the IETF migh= t not be the right venue for. It occurs to me that the charter might have o= nly been intended to cover the first two. Some wordsmithing to make it clea= r what's in scope is probably needed, but I'm hesitant to suggest a= nything, because I don't know what the intent was.

=
thanks,
Rob

--0000000000001079960597e4989e-- From nobody Thu Nov 21 18:11:50 2019 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 7ECEA120845 for ; Thu, 21 Nov 2019 18:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, RCVD_IN_DNSWL_MED=-2.3, 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 oPFNerVFOcW9 for ; Thu, 21 Nov 2019 18:11:47 -0800 (PST) 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 0A992120836 for ; Thu, 21 Nov 2019 18:11:47 -0800 (PST) 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)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 3AF2D6A299; Fri, 22 Nov 2019 03:11:44 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1574388704; bh=nm97+ieK/dPRtr1mVnCfYH6UqkiFYxaeD0Dl+j3CiUk=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:From; b=T2rqL7PvYPzzhZsh7pkMeikTrE9TRAnkXDwP4+ioCkMGjpEL+cN3cxUYcSeBWV1IF X7n1qjzACb2xzQda7Dh5ov7JET/yQdO2X0LNIuHkNi9YqmHomLZl96KMzGWBm9Fv0m hnYPHCekaAgLpiMM4jujIyZFp+gPx6n0ra/TN0lZARhF/iV3qim5jcIftvNVeA8IjW EPN9ay3Rt1VBil4znH2ZT0a9/HdNrZMP42N3cdhSeJa+ri0UwyG9INanhqKmFgSl9Y p6FA3SZSeqcY2hMe3Zj9FdRsgyvPefHI24nrLjWWkyacNXorOItMaSsRL28rD7ndJY cbP+2s/dM6nhw== 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 2E7D23C0160; Fri, 22 Nov 2019 03:11:44 +0100 (CET) Date: Fri, 22 Nov 2019 03:11:44 +0100 (CET) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Alec Muffett Cc: "add@ietf.org" Message-ID: <1256237814.1322.1574388704093@appsuite-gw1.open-xchange.com> In-Reply-To: References: <20191118020806.AD1D51969BB0@fafnir.remote.dragon.net> <20191119060914.C67ED197521B@fafnir.remote.dragon.net> MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev17 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] Draft on deployment models for Internet infrastructure 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, 22 Nov 2019 02:11:48 -0000

Il 22 novembre 2019 01:33 Alec Muffett <alec.muffett@gmail.com> ha scritto:

- So the "sufficiency" of value of DoH is that it is better than either Do53 or DoT for some "dissident" (and: normal user) use-cases..  That's all that DoH needs to be: not "perfect", simply "better, for anti-censorship purposes, than the extant protocol".
The point IMHO is rather of cost vs benefit. Is this increase in "anti-censorship purposes" worth breaking a ton of stuff and creating disadvantages for many parties, users included, especially when a similar or greater increase can be obtained through Tor/VPN/etc?
And we still want to give such nation states the ability to turn-off DoH, upstream? To restrict the ability of Apps to perform their own name-resolution?
I know that the IETF has taken a formal stance against pervasive monitoring, but I miss the pointer to where IETF has done the same against "censorship" (which, by the way, includes first of all an agreed definition of censorship). Yet this point continues to come up, so the entire discussion would benefit from some clarity once for all: is disempowering "nation states" from regulating Internet content an objective of the IETF, and thus a requirement for work in this area, or not? This would help in not having this argument again and again.

-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
vittorio.bertola@open-xchange.com 
Office @ Via Treviso 12, 10144 Torino, Italy
From nobody Fri Nov 22 03:00:13 2019 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 AAF4312026E for ; Fri, 22 Nov 2019 03:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 V_qeBsR1YoYT for ; Fri, 22 Nov 2019 03:00:10 -0800 (PST) Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) (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 71FDF120088 for ; Fri, 22 Nov 2019 03:00:10 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id r20so7269462qtp.13 for ; Fri, 22 Nov 2019 03:00:10 -0800 (PST) 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=lIpMd69Gp7Euqq7t61hs5711Rgl+tGiQTwEx6UNeYys=; b=AV4CvcOZyoV++niGS7MGSgymugV61DxvHR8/ztAU5gGZr+KlqqgN+6o5iZxFRNGypw GngUwi1ExHA4S1GUrjzdIn3vnx/BclCH/q539TpOgsEOsQB44vHzlaMxOmqKZG0y771p XDLkWzXf3ab18APnH5k2dvvfsmU1nWjaWBqcoeELa1JsqCaJGrtHNB6wE0mDRDA6PxMh gMWr6qNwhUErrPgwPH9hnVLqRoSVBGFlmOwpPf5TysecBL+Dd53DSeIUh4wB2072dq5b ggu0lpuDkgWd995XB06IuwkvbfwPcVCn18lzbiSkFTGKcM890v6o6h4t9mg/XWq6kQ/h 2pMA== 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=lIpMd69Gp7Euqq7t61hs5711Rgl+tGiQTwEx6UNeYys=; b=P0M/q29VEZnwVMo/fF1nwKkzmUfF5FsQK2t4CCm7byxDeNvu3F/qqHKSN+d1Sb3Q7w HpANVQ7GysG14RJPWfuWdyesBnwQw2YUKS50Erk1nU69IiaY67PqBl02cougvIYifTn3 33Z1tCtA4hXsIIoH6gM2Jumbc6lALFICtZ9c8T+AaEVxKBv/NQOC7OD5ZIRI2B/bhef6 9amqsaIPMGV37+XmEYE9xoCTSu1NvU7OkfiWdqSwhrP35Wo0+YIzzDr5wikyUKZz72St oSFHb7TsmWwsp1xeqZdYigG/PxgrkeLawht0H5oChVKOUDG6VabhRq5oDrgJkTRJodI1 VLxQ== X-Gm-Message-State: APjAAAWEHaR4dV9lyO0V8ux2OsSTcztSCsIrUE685++0dXmiy+OG8mYN 4lvjeJpEREyoJp1f3mSVBBBYqYy1v9aLuWVxCKgCLmeVJk4= X-Google-Smtp-Source: APXvYqw6An2cxrDETv85h8FEhr2kbUcCZcR4l+o1hlLV85h7/Nc1i78Xv+kkpwk5O0PfxwqXbZn0wBYc+uJckta3Zc4= X-Received: by 2002:ac8:7282:: with SMTP id v2mr3081380qto.75.1574420409408; Fri, 22 Nov 2019 03:00:09 -0800 (PST) MIME-Version: 1.0 References: <20191118020806.AD1D51969BB0@fafnir.remote.dragon.net> <20191119060914.C67ED197521B@fafnir.remote.dragon.net> <1256237814.1322.1574388704093@appsuite-gw1.open-xchange.com> In-Reply-To: <1256237814.1322.1574388704093@appsuite-gw1.open-xchange.com> From: Alec Muffett Date: Fri, 22 Nov 2019 10:59:32 +0000 Message-ID: To: Vittorio Bertola Cc: "add@ietf.org" Content-Type: multipart/alternative; boundary="0000000000003ae11a0597ed5190" Archived-At: Subject: Re: [Add] Draft on deployment models for Internet infrastructure 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, 22 Nov 2019 11:00:13 -0000 --0000000000003ae11a0597ed5190 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 22 Nov 2019 at 02:11, Vittorio Bertola < vittorio.bertola@open-xchange.com> wrote: > Il 22 novembre 2019 01:33 Alec Muffett ha > scritto: > > - So the "sufficiency" of value of DoH is that it is better than either > Do53 or DoT for some "dissident" (and: normal user) use-cases.. That's a= ll > that DoH needs to be: not "perfect", simply "better, for anti-censorship > purposes, than the extant protocol". > > The point IMHO is rather of cost vs benefit. Is this increase in > "anti-censorship purposes" worth breaking a ton of stuff and creating > disadvantages for many parties, users included, especially when a similar > or greater increase can be obtained through Tor/VPN/etc? > Welcome to China, where installation or possession of "secure" applications =E2=80=94 ie: ones which are secure enough to communicate with "The West" = =E2=80=94 is either/both blocked and can get you arrested: https://twitter.com/RealSexyCyborg/status/1086811226376523777 To assume "awareness" and "capability" of users to assure their own security, is to create an underclass - a "security peasantry" who are under-equipped to *either* communicate securely, *or* to lift themselves out of those circumstances. "They should just use a VPN" is the modern equivalent of "let them eat cake". And we still want to give such nation states the ability to turn-off DoH, > upstream? To restrict the ability of Apps to perform their own > name-resolution? > > I know that the IETF has taken a formal stance against pervasive > monitoring, but I miss the pointer to where IETF has done the same agains= t > "censorship" (which, by the way, includes first of all an agreed definiti= on > of censorship). Yet this point continues to come up, so the entire > discussion would benefit from some clarity once for all: is disempowering > "nation states" from regulating Internet content an objective of the IETF= , > and thus a requirement for work in this area, or not? This would help in > not having this argument again and again. > Fortunately, Vittorio, I have an entire essay on that topic. Go for it: https://medium.com/@alecmuffett/how-to-help-dissidents-with-technology-lift= -all-boats-e6fcb72d0da1 - alec --=20 http://dropsafe.crypticide.com/aboutalecm --0000000000003ae11a0597ed5190 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On = Fri, 22 Nov 2019 at 02:11, Vittorio Bertola <vittorio.bertola@open-xchange.com> wrote:<= /div>
Il 22 novembre 2019 01:33 Alec Muffett <alec.muffett@gmail.com> ha scritto:

- So the "sufficiency" of value of DoH is that it is = better than either Do53 or DoT for some "dissident" (and: normal = user) use-cases..=C2=A0 That's all that DoH needs to be: not "perf= ect", simply "better, for anti-censorship purposes, than the exta= nt protocol".
The point IMHO is rather of cost vs benefit. Is this increase in "a= nti-censorship purposes" worth breaking a ton of stuff and creating di= sadvantages for many parties, users included, especially when a similar or = greater increase can be obtained through Tor/VPN/etc?

Welcome to China, where installation or possession = of "secure" applications =E2=80=94 ie: ones which are secure enou= gh to communicate with "The West" =E2=80=94 is either/both blocke= d and can get you arrested:


To assume "awareness" and "capa= bility" of users to assure their own security, is to create an undercl= ass - a "security peasantry" who are under-equipped to *either* c= ommunicate securely, *or* to lift themselves out of those circumstances. = =C2=A0

"They should just use a VPN" is t= he modern equivalent of "let them eat cake".

=

And we still want to give = such nation states the ability to turn-off DoH, upstream? To restrict the a= bility of Apps to perform their own name-resolution?
I know that the IETF has taken a formal stance against pervasive monitor= ing, but I miss the pointer to where IETF has done the same against "c= ensorship" (which, by the way, includes first of all an agreed definit= ion of censorship). Yet this point continues to come up, so the entire disc= ussion would benefit from some clarity once for all: is disempowering "= ;nation states" from regulating Internet content an objective of the I= ETF, and thus a requirement for work in this area, or not? This would help = in not having this argument again and again.=C2=A0
=

Fortunately, Vittorio, I have an entire essay on that t= opic. =C2=A0


=C2=A0 = =C2=A0 - alec

=C2=A0
--
http://dropsafe.crypticide.com/aboutalecm<= br>
--0000000000003ae11a0597ed5190-- From nobody Sun Nov 24 18:03:08 2019 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 ED5FF120152 for ; Sun, 24 Nov 2019 18:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.2 X-Spam-Level: X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, RCVD_IN_DNSWL_LOW=-0.7, 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 CST8mbmwlZor for ; Sun, 24 Nov 2019 18:03:05 -0800 (PST) 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 1A86912016E for ; Sun, 24 Nov 2019 18:03:05 -0800 (PST) Received: from xse178.mail2web.com ([66.113.196.178] helo=xse.mail2web.com) by mx37.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iZ3iN-00040D-Bb for add@ietf.org; Mon, 25 Nov 2019 03:03:01 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 47Lqz454PXz9l3 for ; Sun, 24 Nov 2019 18:01:52 -0800 (PST) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iZ3hI-0002hu-JE for add@ietf.org; Sun, 24 Nov 2019 18:01:52 -0800 Received: (qmail 16330 invoked from network); 25 Nov 2019 02:01:52 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Nov 2019 02:01:51 -0000 To: "add@ietf.org" From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: <50a84f44-bdd3-fa68-8ade-f5a5683dbc7f@huitema.net> Date: Mon, 25 Nov 2019 10:01:50 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.196.178 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.178/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.178/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: unsure X-Spampanel-Outgoing-Evidence: Combined (0.15) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0fIjBzH0XxYvWQgWH/ix0mSpSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDNzOpszOkW3faMySFwG163+fH zJ6mVE7ewsipSVIfs4Z1aVZeuZINZGjfEDnIQj/ZgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cBN5HyO9svXODFfKDo2spNmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdLn4jABaJqtNDIuGYj2WGeveXgFMyx0sD4hRS2uyMFprER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnB5aBPiMI+5j SdCRNhQ7VQKZusCm1UASYxmQqsGnM7tl8URTXEgO0i5xD9cCt+TVRzKR6RgQ6scM/oDJnhhySxmt geb+dJ2Ayn+xE2aWh9YImhlKb/lC+C9AijoWgc8vkIGThCScvU0cCIiHSQbmcVJzHMu/HO3hv5Fn Ucy4pGLxde0+sZxmlLkZlQRRl3/ru9cUcwUc3dSEwz47sM5ca0wqAIu/m66lTbIgDjs1hC0pXPWl FdaGOH191uXjgjQN/RTaYTLUj/RFhcnr3QktcdiP30HnKtpW+NwnpBaFMD/Z1vEjHyvS2QZiR+AZ YvfxEvZFKu+ZM2mB1CpThxyaBpbeNHk15VolAGHS5rCXQKDyCQUljhSWDhWh87HBSLhNUo4qiB0X MVQG2R7iUfOzATaF5R3hQJk8CwyURYKQ0Ye0iR3bHfnMCIEU+nrglojKwJanfcoq9IsR6l/OZb9V MEM= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: [Add] Not looking at DNS privacy in isolation 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, 25 Nov 2019 02:03:07 -0000 I would like to make a plea here to not only look at DNS privacy in isolation, but to consider the combined information disclosure of both the DNS transactions and the Application transactions, typically a web transaction. Consider the typical HTTPS web request starting on a local network, and resulting in a connection to a web server. Let's assume that the transaction is using TLS 1.3 and Encrypted SNI. If we do not assume that, all information would be available to all observers on path, and there is little advantage using anything but the local resolver. We can consider three actors: the local network provider, the DNS resolver, and the web hoster.and that the Each of them will receive some information about the transaction: * The local network will see the IP addresses of server and client, and the name of the fronting server in the "public" SNI. (The same information is available to all on path observers.) * The web hoster will see the IP addresses of server and client, as well as both the public SNI and the hidden SNI, since the web hoster has to redirect the HTTP request to the selected server. * The DNS provider will see the IP addresses of the client in the queries, the name of the fronting server in the A/AAAA request, and the name of the hidden server in the HTTPSRV request. If we did not consider the application traffic, we may assume that selecting a "trusted" DNS resolver is an improvement in DNS privacy. But if we consider the entire chain, the response may be very different. The minimal disclosure is achieved if both the A/AAAA requests and the HTTPSRV request are served by the DNS resolver associated with the web hoster, because doing so does not leak any information that the web hoster would not also obtain from the application traffic. If the resolver of the web hoster is not available or unknown, the minimal disclosure is obtained by splitting the A/AAAA request and the HTTPSRV request, because they disclose different information. The A/AAAA request for the fronting server discloses exactly the information that is always available to on path observers, and thus minimal disclosure is achieved by resolving it through the local DNS server. On the other hand, the HTTPSRV request discloses information that is not visible to the local network, and thus better privacy is achieved by resolving it through a "trusted" resolver. The best result is achieved if in addition to splitting the A/AAAA and HTTPSRV requests, the client caches the result of the HTTPSRV request, including the name of the fronting server. That means that the "trusted" resolver will not know the exact time at which the client establishes the application connection. Also, the name of the fronting server can be used to identify the web hoster and the associated DNS resolver, and thus direct future transactions to that resolver. So, clearly, we need to not just reason about DNS queries in isolation, but we should consider both DNS queries and application traffic. -- Christian Huitema From nobody Mon Nov 25 07:52:49 2019 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 CF1D1120988 for ; Mon, 25 Nov 2019 07:52:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-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 Kqv6pv0SjrKE for ; Mon, 25 Nov 2019 07:52:47 -0800 (PST) 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 741421208B0 for ; Mon, 25 Nov 2019 07:52:47 -0800 (PST) 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)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 614036A357; Mon, 25 Nov 2019 16:52:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1574697163; bh=tlCCop3jmZ1DQthoinOQIMOzw57KbpFpCxaRtSxPCVA=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From; b=iLqEQkrJPe7NGZYGpjOzgHYULGAi4T1v0/PdO1hGbvYGGO2b9ECpFBJczW6YPyisW shECFdVty3Um7kJUs58k2ukUxTt9oS6Df8Z39x07CxTmGHElRy/Z632gZHnkozvR0l ES+Q6FR9PLOaU/RbodVWEZXE54PLYclcn/xMrkp2HUSLFVW9rbC2HreO37o9mjSgVm myOVCNzaKgg5rpNsxt+F1+2/jEvGHfurXVvaGBOeIEpJj38RNLQMMq9UMYYosYUWCX idEAcsGi3nveaKhDMVoNBnRH10Y2acI+Smf2/qMNn/9JjdF1n/ViWtLMRjLwFEA+fw ut49514dw+quA== Received: from appsuite-gw2.open-xchange.com (appsuite-gw2.open-xchange.com [10.20.28.82]) (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 540373C03A4; Mon, 25 Nov 2019 16:52:43 +0100 (CET) Date: Mon, 25 Nov 2019 16:52:43 +0100 (CET) From: Vittorio Bertola Reply-To: Vittorio Bertola To: Christian Huitema , "add@ietf.org" Message-ID: <713446008.7630.1574697163242@appsuite-gw2.open-xchange.com> In-Reply-To: <50a84f44-bdd3-fa68-8ade-f5a5683dbc7f@huitema.net> References: <50a84f44-bdd3-fa68-8ade-f5a5683dbc7f@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.2-Rev17 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] Not looking at DNS privacy in isolation 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, 25 Nov 2019 15:52:49 -0000 > Il 25 novembre 2019 03:01 Christian Huitema ha scritto: > > if we consider the entire chain, the response may be very different. The > minimal disclosure is achieved if both the A/AAAA requests and the > HTTPSRV request are served by the DNS resolver associated with the web > hoster, because doing so does not leak any information that the web > hoster would not also obtain from the application traffic. First of all, the "DNS resolver associated with the web hoster" already exists, it is called the "authoritative name server" for the destination domain. So what you have found is that less information is circulated if the user does not adopt any resolver and just does the entire resolution process directly, something which is well known. But this does not necessarily mean that doing name resolution directly provides more privacy, because by adding a resolver in the middle two things happen: - the user's request is merged with the requests by many other users, so tracking is much harder than with direct requests (and if the resolver is local to the user's access network, there is no need to add client subnet or other information that might help tracking the specific user); - in most cases, the user's request will be cached and no information at all will be circulated beyond the local resolver - something that also speeds up the process considerably. IMHO, the proposals to have each website reply to DNS requests for "its own" domains seem to ignore all the operational wisdom developed by the DNS community in the last thirty years. Possibly they should also explain why that wisdom is not valid any more. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Mon Nov 25 22:32:36 2019 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 D0752120096 for ; Mon, 25 Nov 2019 22:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 6NeKyfnYi_Td for ; Mon, 25 Nov 2019 22:32:31 -0800 (PST) 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 98567120FD7 for ; Mon, 25 Nov 2019 22:32:02 -0800 (PST) Received: from xse279.mail2web.com ([66.113.197.25] helo=xse.mail2web.com) by mx63.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iZUO3-0004IM-2w for add@ietf.org; Tue, 26 Nov 2019 07:31:56 +0100 Received: from xsmtp21.mail2web.com (unknown [10.100.68.60]) by xse.mail2web.com (Postfix) with ESMTPS id 47MYv32DYpz9x4 for ; Mon, 25 Nov 2019 22:30:55 -0800 (PST) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp21.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iZUND-0007lZ-6g for add@ietf.org; Mon, 25 Nov 2019 22:30:55 -0800 Received: (qmail 18812 invoked from network); 26 Nov 2019 06:30:55 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Nov 2019 06:30:54 -0000 To: Vittorio Bertola , "add@ietf.org" References: <50a84f44-bdd3-fa68-8ade-f5a5683dbc7f@huitema.net> <713446008.7630.1574697163242@appsuite-gw2.open-xchange.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Tue, 26 Nov 2019 14:30:48 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <713446008.7630.1574697163242@appsuite-gw2.open-xchange.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US X-Originating-IP: 66.113.197.25 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/gcnlw0VyY7+E5Em8uC8nykI/JrD6pSDasLI4SayDByyq9LIhVUZbR67CQ7/vm /hHDJU4RXkTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDNzOpszOkW3faMySFwG163+fH zJ6mVE7ewsipSVIfs4bcDRIEaMF8Fy4oBhodGJ/RgyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+cNeCzkayK9X+vYtyDmRenUmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfDtw+Ut ziY+nbU7qa50sEXj8hEv6ylbrSataIASdByf+qyWDcKgIew/Pqmv8CiR0A+Ffy7fEg460Hn2xYnW avStyzAiWbbj13U46jbWFIz21cHX/YzWyFk7762whX3QQ+5uhkPm88V7ziklAaTl19sU919xeAvO xjeQEcL5lNmXdLn4jABaJqtNDIuGYj2WGeveXgFMyx0sD4hRS2uyMFprER9E+btGG8Xk1uugE/FU 4J9TrjYo22Tif+7yfJXbGyN6EipRzMVZ5LqwTx7Vvn9SP+LiFhV9TEgXGI3XmDfDnOu9dHI/x63E XXKWrOjLtA8Ya0DFhKR0reMjbnA+hNVVzhxxUJ5qiJJ1CEibuTv+ejKR6RgQ6scM/oDJnhhySxkN 9rgBi15bvnmJUy7l4X8Sn8HCOY5o9O4BeTlbpwF6zQyEZ9MYp5iiF2omUcFCWyEkQBBqJtY4Pu0I BOZMHRuJS9y9uNbs1DqwO711CiNzc9K7r7/TbM7rh7za11QGlcq3/XTPyYgiig3N5JtZy8eIctgz cDoFd+96Xw4QUNtTnUQO7MLiS3xeo6BPJ6AFzN/WAD85XDmk06RIlqTP4gt02fa5Z8JMyvt2otFY eJV5EEl45oFndAaW0zhwtclwNLITiSzBvtjMqHJKbcoJ3LAWa8Mrc8quJ4btPpt/2FLuFDHRLWyH Qs+3RVQ97CmIM68WJB4pGe8YrEHjBXb8vVkXYd/jKzjiuDYHz/0WYr1rU3B7HfKjI1eYNYaA4ur2 /Is= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Add] Not looking at DNS privacy in isolation 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, 26 Nov 2019 06:32:34 -0000 On 11/25/2019 11:52 PM, Vittorio Bertola wrote: >> Il 25 novembre 2019 03:01 Christian Huitema ha s= critto: >> >> if we consider the entire chain, the response may be very different. T= he >> minimal disclosure is achieved if both the A/AAAA requests and the >> HTTPSRV request are served by the DNS resolver associated with the web= >> hoster, because doing so does not leak any information that the web >> hoster would not also obtain from the application traffic. > First of all, the "DNS resolver associated with the web hoster" already= exists, it is called the "authoritative name server" for the destination= domain. So what you have found is that less information is circulated if= the user does not adopt any resolver and just does the entire resolution= process directly, something which is well known. Maybe, maybe not. There are many cases in which the CDN, for example, also acts as authoritative DNS server for the domains. But there are exceptions. > > But this does not necessarily mean that doing name resolution directly = provides more privacy, because by adding a resolver in the middle two thi= ngs happen: > - the user's request is merged with the requests by many other users, s= o tracking is much harder than with direct requests (and if the resolver = is local to the user's access network, there is no need to add client sub= net or other information that might help tracking the specific user); > - in most cases, the user's request will be cached and no information a= t all will be circulated beyond the local resolver - something that also = speeds up the process considerably. The privacy issue is two-folds. One side is what can third parties learn by observing traffic, which is why we really want encrypted DNS transport, and some of your arguments apply -- although if you consider both DNS traffic and application traffic you may get a different picture. The other side is the aggregation of data at the resolver. You assert that "no information will be circulated beyond the initial resolver", but that assumes that nobody accesses the resolver logs. The best privacy posture is achieved when the data is not in the resolver logs in the first place. The second best is achieved when the information in the resolver logs provides no additional knowledge over logs of network traffic. This is why we need to consider both DNS traffic and application traffic. > IMHO, the proposals to have each website reply to DNS requests for "its= own" domains seem to ignore all the operational wisdom developed by the = DNS community in the last thirty years. Possibly they should also explain= why that wisdom is not valid any more. You are making an argument about DNS server load and practicality of some strategies. Yes, overwhelming under-provisioned servers would be bad. But there are examples where this is not a concern. Cloudflare, for example, seems happy to serve as DNS resolver for anyone who asks. They would probably be ready to serve DNS requests for all of the web sites in the Cloudlflare CDN. -- Christian Huitema From nobody Tue Nov 26 08:45:30 2019 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 BEF7B12098B for ; Tue, 26 Nov 2019 08:45:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=oxjySV8b; dkim=pass (2048-bit key) header.d=comcast.com header.b=NkxwM0GW; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=Ccwl9Cbs 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 2Y1fNyFNu45z for ; Tue, 26 Nov 2019 08:45:27 -0800 (PST) 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 C5DDC120128 for ; Tue, 26 Nov 2019 08:45:27 -0800 (PST) Received: from pps.filterd (m0156892.ppops.net [127.0.0.1]) by mx0a-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xAQGJsEO028186 for ; Tue, 26 Nov 2019 11:45:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=20190412; bh=teT+vCTljC8Z8X7gAaIeSzXUnLtQ/PPXUZmXfTtH38M=; b=oxjySV8bkK6U+gRoPG9GBUDoGFU8vOCtbWvOc1V9CAlmG818zmbXxvMwQY+5WOM/VBIt FNDU4MdHGujrC24d/KiW9pghR406Xz6fgyHFnuqFoVkOSaq/fl2xmwYVYlVXMG7F2XoL 1CXcQW8a1P+ZxSUdaNEx5w7+MvR4a8VqMzN3xg19O2Q8pO0kOOlNrRr/J+iKpAVc3LFu 0kI0VcKU+0eqi6DvRjJQCX4MUVKnFTBdyQqJqEs6RdOpVTy7StJh3DfYtoVOFBNFMqcr V31ny4let1/5jUZm4s29hpEyKqYKct0TcID5zrPR6wxQ/iZa1XecSUKUAlBkNutspXcu WQ== Received: from copdcmhout02.cable.comcast.com (copdcmhout02.cable.comcast.com [96.114.158.212]) by mx0a-00143702.pphosted.com with ESMTP id 2wgm0v9ak3-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Tue, 26 Nov 2019 11:45:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1574786724; x=2438700324; 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=teT+vCTljC8Z8X7gAaIeSzXUnLtQ/PPXUZmXfTtH38M=; b=NkxwM0GWHSkpOfgRCLgY69pDgu7S6PHBa9y6z6MbhSAJAaaKgV5F/iM9jxrJL9YN Im4eT95ZFaUuWgwzh3kSgkn0c2qaLJ29dAZyfaSDX9evxyyxJoZLFshjawApG85n nsO0TYz9YFVz127g4vVrosSvMHkeDLQgi0nBa2IAoVtdPnCPQ8ul1CaxU8pvzN1C 3z8VgfF18PeU0OfH21uZ1TIYicHMNRxc05U6QBZAmuxjh9r3ZAot0I561O0C9L8K E9+n1nz9X/qAgaOig2agj64SkOdJZvWIpgRMa3hIZFIznHEWSaDSbumBgRyQpuIY 8GjmzLB9S2zTCb53kqtfDw==; X-AuditID: 60729ed4-24fff7000000bc72-ff-5ddd56a4d53a Received: from COPDCEX11.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 copdcmhout02.cable.comcast.com (SMTP Gateway) with SMTP id 56.9B.48242.4A65DDD5; Tue, 26 Nov 2019 09:45:24 -0700 (MST) Received: from COPDCEX18.cable.comcast.com (147.191.124.149) by COPDCEX11.cable.comcast.com (147.191.124.142) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Nov 2019 09:45:23 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX18.cable.comcast.com (147.191.124.149) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 26 Nov 2019 09:45:23 -0700 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (104.47.38.52) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Nov 2019 11:45:05 -0500 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB3880.namprd11.prod.outlook.com (10.255.160.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.17; Tue, 26 Nov 2019 16:45:05 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a%7]) with mapi id 15.20.2474.023; Tue, 26 Nov 2019 16:45:05 +0000 From: "Livingood, Jason" To: Christian Huitema , "add@ietf.org" Thread-Topic: [Add] Not looking at DNS privacy in isolation Thread-Index: AQHVozSQfdX0GbcB/Ema/eOqIa7jXaedV3kA Date: Tue, 26 Nov 2019 16:45:05 +0000 Message-ID: <3193A9C1-F164-41EC-B9AB-7FC5C1A08007@cable.comcast.com> References: <50a84f44-bdd3-fa68-8ade-f5a5683dbc7f@huitema.net> In-Reply-To: <50a84f44-bdd3-fa68-8ade-f5a5683dbc7f@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-originating-ip: [198.178.12.46] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9b4f89be-a1f0-4a33-1038-08d7728ffd53 x-ms-traffictypediagnostic: BY5PR11MB3880: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0233768B38 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(346002)(376002)(396003)(366004)(39860400002)(189003)(199004)(6246003)(256004)(8676002)(6436002)(81166006)(81156014)(8936002)(14444005)(478600001)(2906002)(71200400001)(71190400001)(6512007)(25786009)(86362001)(14454004)(80792005)(446003)(66066001)(33656002)(11346002)(2616005)(6506007)(4744005)(76116006)(91956017)(66946007)(66476007)(66446008)(64756008)(66556008)(5660300002)(2501003)(99286004)(229853002)(6116002)(76176011)(3846002)(6486002)(316002)(305945005)(58126008)(110136005)(186003)(102836004)(26005)(7736002)(53546011); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB3880; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P1VRqxdmakkr32E6EWCf4HSZjybWWUi48zBjk7RBa8/pcEefQJXL6+ADwzC+k2guF0gEf/GPqNx98ApnyBpWizTRHTcbjXfgtItEbH196fgsJaHuxen6mFYlMVZAJENXMqSfI0NrYOyO5Dqikaqpdec+iXfOTMBxAUwQqKeSA16jayFOXYoDipywjaDuKE0l9SBDtaZ7AJnPcNKq4jQwczwLCnee94uDSb66iPBt/9NjtNRX6jdJrgkiCrT31uLeyIz/5yRpO0lsZbYDpLQAQt6+cWrxKYLPe+WNHj/Fo4+innBVMgZ3qNsOu7Z2Ps0hF2WsOg7D3PZtChwmkUZhTclN+1AvYOt/zW/u9QezUVByu3SLx8pT5xkZ/wpg0WnlQAp5hjwggt2uS56McUWn10r1xVkuK2MMctRSM9RCRZxh3LJ7KucvCxVrgeT33Peo x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Pvlw2qTb/MRYeKCStQTetdeTrBnWwFvLVn9p3jWWJIhTShhOEPA2Jlru1xu0aUu3xaaphFS0IIAEiOG/kt9LartOQFTkwzZt4hFA9W5KsI4U4m6bN1i3CDXzkRGIs7jQdgt8RgG9HuzCLQBdZ8AVZ8jMhXyfnaUZZT3I58WrehZk9xbueHkRrAp4jQ5366mmiNt4ObHbX//gF9ooDcYJV1lKGw7Kcq0cHfe6dSl4pZHJRtOXLxasDrxLLTwFij7APWMg6FOH6VpCp/gliCrjvwO6c3O3KnmYrsxw+2WSKbiHWg77cmq4HyipILr3ui6WQTHFg+TzYzkA0BMP6Uy3NA== 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=YSScq3J3kqndqMGPV+treFX3R8N0jwYFRbYQANmzSbw=; b=P9QrscFVfEMah7TOa1GaOWZFjKLAAt+DyLFv3rFX9N2/Hzf579OVssdfwoPtLSB0Y2Um+epjeVDCn9ilDaSHz/5See/wBm/mmLN4WdjWWY0QF9JtBDE0NMDlkcEQ8qxwLtOCnqe79x6ibWzEmJ2azfbgQxsjRiMmeFJ6cRsjYcG+4muuy6w80qx3WpGOsUJS3aoq3qwhxZLrWLt+xaISj5sDg7shFHZYG+q6MaoVO3XPMHHioHze3eugRUIxQOZijjcsCttbYCqosyQjwA0IU/7lcdyqUXwtOApbtmXOwjeey1q12M++75LHSx3XQdOcO0tPc9GVbMDoxry/hnQ1Yg== 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=YSScq3J3kqndqMGPV+treFX3R8N0jwYFRbYQANmzSbw=; b=Ccwl9CbsfRcokSVrAuUZAHkrDTPmlQArNbNG7IVN9eeV1CDDY2wR50D2QkmCbioqdKpf2Zo++t8JIC9R7eXO0TSf6JALZaWiO082EzSA5F0XoQQt2Nurg2BWoKJt1EIG2rRtHIJHosdt6AdLNKQVtZssWWNhdlrCVqq/MPjL6aA= x-ms-exchange-crosstenant-network-message-id: 9b4f89be-a1f0-4a33-1038-08d7728ffd53 x-ms-exchange-crosstenant-originalarrivaltime: 26 Nov 2019 16:45:05.1014 (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: tfN46iML2gRQJXuULNduO2N7YXWw+v9Z9e1vAZcZAqEkQYGymzBrRuvH+RAPvW3+OYDyX7Sq+w/o4CDnTOs0Zrqe2EHmu8g7O36Wt9qZN2A= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB3880 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <6B097101A7496943B9A56EB02D180A3B@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHKsWRmVeSWpSXmKPExsWSUDRnsu6SsLuxBl27BS3+n17HZjG5cTa7 A5PHrRmnWDyWLPnJFMAU1cBoU5JRlJpY4pKalppXnGrHpYABbJJS0/KLUl0Ti3Iqg1JzUhOx KwOpTEnNySxLLdLHaow+VnMSupgy9r7/xFqwg6vi8MZlzA2MU7i6GDk5JARMJA7eWcHUxcjF ISRwmElizq85UM4hRoktpw+wQjh3GCUeHNwN5ZxglLh3bTU7hDOZSWLG1XdsEM4jRomXux4y gkxmEzCTuLvwCjOILSLgJXG95Tc7iC0sYCXx5ut6Roi4tcTadSeYIGwjib//rgHVc3CwCKhK NLTxgYR5BVwkFlz8zApiCwnYSVzZuIsRpIRTwF7i/PE6kDCjgJjE91NrwKYwC4hL3Hoynwni NwGJJXvOM0PYohIvH/8DGyMqoC9xp2svO0RvisTirkVQ9YoSN3q/QdXLSlya380IYftK9Lzb xwpha0kcWHIHqiZb4s+Z3SwQtprEjTcdUHEZiVcHz4ODUULgMqvE5h9bWUFuFhLIknh71Q6i Rk5iVe9DlgmMJrOQnD0LqIpZQFNi/S59CNND4u4CeYgKRYkp3Q/ZZ4HDRFDi5MwnLAsYWVcx 8lma6RkamugZmlroGRkabWIEp8p5V3YwXp7ucYhRgINRiYf3tdvdWCHWxLLiylxgtHIwK4nw ah++EyvEm5JYWZValB9fVJqTWnyIUZqDRUmcl2/tglghgfTEktTs1NSC1CKYLBMHp1QD46Ll vZpenzd2L7hxfsfzeXqLcuZNuZQqtfRJ6xOel8VcE/aqsZ7dr2NwW/iWSu/LJL0lnByWd2Mj bHfU+6+Rz1jtdz+nXKeJw5czr9raIJyLxf5FO0NnBHe6z/WsBhcL5/s1H6NmqTH47z95Zald 8BtjE9/tJn/v9M9ukT/PWP5uV5hncYK1EktxRqKhFnNRcSIAf9ePS5EDAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-26_04:2019-11-26,2019-11-26 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] Not looking at DNS privacy in isolation 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, 26 Nov 2019 16:45:30 -0000 T24gMTEvMjQvMTksIDk6MDMgUE0sICJBZGQgb24gYmVoYWxmIG9mIENocmlzdGlhbiBIdWl0ZW1h IiA8YWRkLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGh1aXRlbWFAaHVpdGVtYS5uZXQ+ IHdyb3RlOg0KPiAgICBXZSBjYW4gY29uc2lkZXIgdGhyZWUgYWN0b3JzOiB0aGUgbG9jYWwgbmV0 d29yayBwcm92aWRlciwgdGhlIEROUw0KICAgIHJlc29sdmVyLCBhbmQgdGhlIHdlYiBob3N0ZXIu YW5kIHRoYXQgdGhlIEVhY2ggb2YgdGhlbSB3aWxsIHJlY2VpdmUgc29tZQ0KICAgIGluZm9ybWF0 aW9uIGFib3V0IHRoZSB0cmFuc2FjdGlvbjoNCg0KPiAqIFRoZSBsb2NhbCBuZXR3b3JrIHdpbGwg c2VlIHRoZSBJUCBhZGRyZXNzZXMgb2Ygc2VydmVyIGFuZCBjbGllbnQsIGFuZA0KICAgIHRoZSBu YW1lIG9mIHRoZSBmcm9udGluZyBzZXJ2ZXIgaW4gdGhlICJwdWJsaWMiIFNOSS4gKFRoZSBzYW1l DQogICAgaW5mb3JtYXRpb24gaXMgYXZhaWxhYmxlIHRvIGFsbCBvbiBwYXRoIG9ic2VydmVycy4p DQoNCltKTF0gQXMgeW91IG5vdGUgcGFyZW50aGV0aWNhbGx5IHRoaXMgaXMgdHJ1ZSBvZiBhbnkg bmV0d29yayBhbG9uZyB0aGUgZW5kIHRvIGVuZCBwYXRoIGJldHdlZW4gdGhlIGNsaWVudCBhbmQg dGhlIHNlcnZlci4gRnJvbSBhIHRocmVhdCBhc3Nlc3NtZW50IHN0YW5kcG9pbnQgdGhvc2Ugbm9u LWxvY2FsIG5ldHdvcmsgcHJvdmlkZXJzIG1heSBiZSBhIGdyZWF0ZXIgcmlzayAoYnVtcHMgaW4g dGhlIHdpcmUpLCBwYXJ0aWN1bGFybHkgYXMgdGhleSBhcmUgbGlrZWx5IHVua25vd24gdG8gZW5k IHVzZXJzIChzdWNoIGFzIHRyYW5zaXQgbmV0d29ya3Mgb3Igc3VibWFyaW5lIGxpbmsgcHJvdmlk ZXJzKS4gU28gSSB3b3VsZCByZWNvbW1lbmQgeW91IG5vdCBmb2N1cyBvbiBqdXN0IGEgbG9jYWwg bmV0d29yayBidXQgbW9yZSBicm9hZGx5IHRvIGFueSBuZXR3b3JrIG9uIHRoZSBFMkUgcGF0aC4N Cg0KDQo= From nobody Tue Nov 26 11:01:38 2019 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 560C0120A7A for ; Tue, 26 Nov 2019 11:01:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=ducksong.com header.b=VUnNHCuq; dkim=pass (2048-bit key) header.d=outbound.mailhop.org header.b=bTYY1DPH 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 gWQdlRK9fkkh for ; Tue, 26 Nov 2019 11:01:32 -0800 (PST) Received: from outbound2r.ore.mailhop.org (outbound2r.ore.mailhop.org [54.200.129.228]) (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 C8F5A120A6E for ; Tue, 26 Nov 2019 11:01:32 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1574794892; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=hs/FivmCvLTZLyRpzooI+JePLZLSm4PtjcJvVjOsqZ4mptc/qXlk02gPVMQGNX9CXIMky43P4bgG8 /d5lyIPIoqs9G+86Us+7ohbNQvYcFsvBy8Zn8vEYnK78lQADb0swOwI+okarPFx6iuEj+Ffe6bTf2E rJYY+PWwV9vKLL3U2SfmJI9Ce6AEY//yuXhR5cbyz7Ceg7QAB3VlKv2vHOgsfyLYJT7gG6Dnk2gn9F FDBo8dpIE76RTEXCN2m57QTEglGZA6yIMrDB3KfBXOBzU4x4AAFD6AvjPly0nzQARcuz6pzcxfT35Q zD8ov2i1cT1RKm/WFusFHQVEGPjo6ww== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:dkim-signature:dkim-signature:from; bh=8Sdwu6K+875vly2bk/0nAuPsIa1RMDaVAFL0MSn2ehc=; b=NG6pBHIQg0YnHohVibpK22FfFt8SOoXpLfCiMnvaNrbAkV880Yq+Ez8Dx7lnvYQOA93GsVn70ugoa iIvJAj8a1ubues9EvqwxIo6U6t1QXwXsOh7qyGyJWBOeEHA3iOWspgnmDf2wSm4+6dDKsF8La3lgHG 5U0QGgAuX/4YOKZGqRRHvWMPBog/i+jzzyU+IOeY8Gcv4ZuXMLgXgkGrYYl+fOP1tTH3ttHweHmqI0 71/pjHPoBhQnQbJPrUnGLz3T/9wsgJf7psGiOjBND2VBEQx2O9iTViEk5fN3WodoS4904rwGpF8dTL /sZPfZuWF+jv2a8XXpnarntLTJK6Vrg== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=pass smtp.mailfrom=ducksong.com smtp.remote-ip=209.85.167.173; dmarc=none header.from=ducksong.com; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ducksong.com; s=duo-1537391512170-ea99bbb3; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=8Sdwu6K+875vly2bk/0nAuPsIa1RMDaVAFL0MSn2ehc=; b=VUnNHCuqfY1WJ30+McY7NedJXEs/TJ6KeLwPHMqGA7n5aXhthr+iEm69SIZwiinYUVkAkMGx0LJ5D 8qmqxwwUVdBxcRnN4iscjsrzQjbYHeWjv2oDTc6USnk47GxZc56BrMGY0+BZ21gow5ILnYSwzotiW0 GB+VbG2U/9LM/AuY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-type:cc:to:subject:message-id:date:from:in-reply-to:references: mime-version:from; bh=8Sdwu6K+875vly2bk/0nAuPsIa1RMDaVAFL0MSn2ehc=; b=bTYY1DPHlv4jCiElNe1XYnB019b4szn+Q7EMg+3KfDty9/GnyyJjdXIfP5gEdXucwmK3M6iTi7DvD zcdEFfWIohLLAloTcLxOl8k78wLSwzUjCgbeIjIQ/Fo0gkoV/4liPJLDbxaHheFFh59dyHEEeaWyQ1 /+rj95+jDZr1Fz42pLkKBtEaSJNc4BG1TeHwC/gP/YLLL9d/vOeGGyJfaNFByjGNHXWlj/3rXdPeZI vYmoIpjd7J/3D0V+ol9VcU50K5gA1PpzZvf0+bcP0aUabvuNxqTluJgqfvmjenxs6v69piNzJj1Gxp vJBx0CUfI0deJEoo73z6SNoRZF4DVTg== X-MHO-RoutePath: bWNtYW51cw== X-MHO-User: 27e5e934-107f-11ea-829e-79a40d15cccd X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 209.85.167.173 X-Mail-Handler: DuoCircle Outbound SMTP Received: from mail-oi1-f173.google.com (unknown [209.85.167.173]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 27e5e934-107f-11ea-829e-79a40d15cccd; Tue, 26 Nov 2019 19:01:31 +0000 (UTC) Received: by mail-oi1-f173.google.com with SMTP id n14so17609687oie.13 for ; Tue, 26 Nov 2019 11:01:30 -0800 (PST) X-Gm-Message-State: APjAAAWBTaveoHsQHePnWUf3/ajLK4WSJN+TBOFK9ZTHmh3XiVQz3Bl6 quEypDaKDtmZJbxKCb0BZOMs7nUEmwMa6kWS8u0= X-Google-Smtp-Source: APXvYqwBk3AEiUVLhS0uO5mfd3MZuQcQtBqSoFbpb342kldEKYGI4JGkO9tRg4d1fcP+gY95FqG5E1X8XVs09WXGl+g= X-Received: by 2002:aca:f495:: with SMTP id s143mr434530oih.118.1574794890150; Tue, 26 Nov 2019 11:01:30 -0800 (PST) MIME-Version: 1.0 References: <50a84f44-bdd3-fa68-8ade-f5a5683dbc7f@huitema.net> <3193A9C1-F164-41EC-B9AB-7FC5C1A08007@cable.comcast.com> In-Reply-To: <3193A9C1-F164-41EC-B9AB-7FC5C1A08007@cable.comcast.com> From: Patrick McManus Date: Tue, 26 Nov 2019 14:01:19 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "Livingood, Jason" Cc: Christian Huitema , "add@ietf.org" Content-Type: multipart/alternative; boundary="000000000000058d5a0598448233" Archived-At: Subject: Re: [Add] Not looking at DNS privacy in isolation 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, 26 Nov 2019 19:01:35 -0000 --000000000000058d5a0598448233 Content-Type: text/plain; charset="UTF-8" otoh the local network is probably responsible for the IP assignment and, especially when known to the end user, is capable of mapping that directly to real-life identity and other bits of profile linked to that identity. This gives them a somewhat unique threat attribute to be considered. -P On Tue, Nov 26, 2019 at 11:45 AM Livingood, Jason < Jason_Livingood@comcast.com> wrote: > On 11/24/19, 9:03 PM, "Add on behalf of Christian Huitema" < > add-bounces@ietf.org on behalf of huitema@huitema.net> wrote: > > We can consider three actors: the local network provider, the DNS > resolver, and the web hoster.and that the Each of them will receive > some > information about the transaction: > > > * The local network will see the IP addresses of server and client, and > the name of the fronting server in the "public" SNI. (The same > information is available to all on path observers.) > > [JL] As you note parenthetically this is true of any network along the end > to end path between the client and the server. From a threat assessment > standpoint those non-local network providers may be a greater risk (bumps > in the wire), particularly as they are likely unknown to end users (such as > transit networks or submarine link providers). So I would recommend you not > focus on just a local network but more broadly to any network on the E2E > path. > > > -- > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add > > --000000000000058d5a0598448233 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
otoh the local network is probably responsible for the IP = assignment and, especially when known to the end user, is capable of mappin= g that directly to real-life identity and other bits of profile linked to t= hat identity. This gives them a somewhat unique threat attribute to be cons= idered.

-P


On Tue, Nov 26, 2019 at 1= 1:45 AM Livingood, Jason <Jason_Livingood@comcast.com> wrote:
On 11/24/19, 9:03 PM, "Add on behalf of Ch= ristian Huitema" <add-bounces@ietf.org on behalf of huitema@huitema.net> wrote:
>=C2=A0 =C2=A0 We can consider three actors: the local network provider,= the DNS
=C2=A0 =C2=A0 resolver, and the web hoster.and that the Each of them will r= eceive some
=C2=A0 =C2=A0 information about the transaction:

> * The local network will see the IP addresses of server and client, an= d
=C2=A0 =C2=A0 the name of the fronting server in the "public" SNI= . (The same
=C2=A0 =C2=A0 information is available to all on path observers.)

[JL] As you note parenthetically this is true of any network along the end = to end path between the client and the server. From a threat assessment sta= ndpoint those non-local network providers may be a greater risk (bumps in t= he wire), particularly as they are likely unknown to end users (such as tra= nsit networks or submarine link providers). So I would recommend you not fo= cus on just a local network but more broadly to any network on the E2E path= .


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

--000000000000058d5a0598448233-- From nobody Tue Nov 26 12:59:37 2019 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 07B24120AD2 for ; Tue, 26 Nov 2019 12:59:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0syBJOVC1WhL for ; Tue, 26 Nov 2019 12:59:35 -0800 (PST) Received: from mx36-out10.antispamcloud.com (mx36-out10.antispamcloud.com [209.126.121.30]) (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 C73DC120A3D for ; Tue, 26 Nov 2019 12:59:34 -0800 (PST) Received: from xse246.mail2web.com ([66.113.196.246] helo=xse.mail2web.com) by mx26.antispamcloud.com with esmtp (Exim 4.89) (envelope-from ) id 1iZhvf-0004Ol-RI for add@ietf.org; Tue, 26 Nov 2019 21:59:26 +0100 Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 47Mx8v1ckXz2rbV for ; Tue, 26 Nov 2019 12:59:11 -0800 (PST) Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from ) id 1iZhvT-0001V3-3T for add@ietf.org; Tue, 26 Nov 2019 12:59:11 -0800 Received: (qmail 16674 invoked from network); 26 Nov 2019 20:59:10 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.197.82]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Nov 2019 20:59:10 -0000 To: "Livingood, Jason" , "add@ietf.org" References: <50a84f44-bdd3-fa68-8ade-f5a5683dbc7f@huitema.net> <3193A9C1-F164-41EC-B9AB-7FC5C1A08007@cable.comcast.com> From: Christian Huitema Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= mQENBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAG0J0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PokBOQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1a5AQ0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAYkCPgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8= Message-ID: Date: Wed, 27 Nov 2019 04:59:10 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.2.2 MIME-Version: 1.0 In-Reply-To: <3193A9C1-F164-41EC-B9AB-7FC5C1A08007@cable.comcast.com> Content-Type: multipart/alternative; boundary="------------076EF8641320FF6906E0ED4E" Content-Language: en-US X-Originating-IP: 66.113.196.246 X-Spampanel-Domain: xsmtpout.mail2web.com X-Spampanel-Username: 66.113.196.246/32 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.196.246/32@xsmtpout.mail2web.com X-Spampanel-Outgoing-Class: ham X-Spampanel-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0VyY7+E5Em8uC8nykI/JrD6pSDasLI4SayDByyq9LIhV7NjrYv96OSQ9 P5TpMqhWVUTNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDNzOpszOkW3faMySFwG163+fH zJ6mVE7ewsipSVIfs4Z625kySGYK8oRTgYhujTW4gyWFxOA5dILPypvKxNVhWQwOVcNrdpWfEYrY fLBY3+drkGak0OTW5UdRG0gJLGgmmdySlZou9qHIGOZDEEo7O2nS6C1mWTD2n8BB0gTSSfCrE2rb Hpkagd3yMuHMqQJIX+gRCHfMVnsAk591zk0uilUI+ZL4xWiN8NS6C+dmX6OEdA4u1aThyWrQ/ou2 +v/lmX4Em37yFgrCB6NHRn1g+f3uncIqYSL3lhh5c81YyJqFoLZMmkWsaurVZfvqROaDnDtHb8z5 dpPkEuJ8Snwqla7jUnW3hy14Yji8fo+4xCnSRo4Rcu5Z37rMuDjCny5fE9ykbJ7I9co1MAEE3ruN Xsm8UJsAPvDcVSKtDCYkioPY5Qx4fJOk03R5fJtf/Dv/dkIzS7m4GUpXCY1Y3j3ilTqCGDo5tULO OlnO//Ji/vX1v48+tFzsIm9Lt0u4eTC75UNw+lGDQSn+uc/VDCBoPiquJ5+jddDfP0MqCP88xAFU PVcmx1QL+XiKf76y/BgK2cUrORdkQf6VU8F13rI+evKY2AXNZGS5G93aGyH8MqMlOQRMVMd0HCeT skOZ5TL8MXUvpZKRNSVL++3aoLTWczXg724gFzhHYUe+7aKm0vXP2pJZgY36crEjoyTf/mIlTi+J 2sBvM/O0p+zizleC4va6FPcpDHjXMKZJK8+chias/iaDuf+kU1qNnQlGYzxt7cTs80/2FnZg/IMs IAdedSzLrjsyfTPCYbMCLdmf5h2vfxw3Qvb2Glio5Cia/9Kfg4kJ0WtAYbrpe3OOAtQNb87OBHCz Hbokiue7PjVB1S6AQRz4SqXhOP5fdiQt7lu5Jm5nk4BSgYHOJJgUtm67rBRli6kULE5BQDZnPvvF VsQ= X-Report-Abuse-To: spam@quarantine11.antispamcloud.com Archived-At: Subject: Re: [Add] Not looking at DNS privacy in isolation 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, 26 Nov 2019 20:59:37 -0000 This is a multi-part message in MIME format. --------------076EF8641320FF6906E0ED4E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11/27/2019 12:45 AM, Livingood, Jason wrote: > On 11/24/19, 9:03 PM, "Add on behalf of Christian Huitema" wrote: >> We can consider three actors: the local network provider, the DNS > resolver, and the web hoster.and that the Each of them will receive= some > information about the transaction: > >> * The local network will see the IP addresses of server and client, an= d > the name of the fronting server in the "public" SNI. (The same > information is available to all on path observers.) > > [JL] As you note parenthetically this is true of any network along the = end to end path between the client and the server. From a threat assessme= nt standpoint those non-local network providers may be a greater risk (bu= mps in the wire), particularly as they are likely unknown to end users (s= uch as transit networks or submarine link providers). So I would recommen= d you not focus on just a local network but more broadly to any network o= n the E2E path. Jason, my point was really about comparing the additional information obtained by resolvers at different locations when processing different kinds of DNS requests. I consider three kinds of resolvers: local (typically managed by ISP), off path (like the various x.x.x.x), and near the server (e.g. a Cloudflare server when processing requests for domains served by Cloudflare's CDN). I also consider two kinds of requests: A or AAAA, and HTTPSRV used to obtain ESNI data. For A/AAAA queries, the results are: 1) Local resolvers do not gain any additional information that is not available on-path already 2) Off-path resolvers gain information that IP address X is querying fronting server F at time T 3) Server side resolvers do not gain any additional information that is not available from the servers already. For HTTPSRV queries, the results are: 1) Local resolvers do gain information that IP address X may be interested in hidden server H, and can correlate that with later traffic to fronting server F 2) Off path resolvers do gain information that IP address X may be interested in hidden server H, but cannot correlate that with later traffic if they do not also process the later A/AAAA queries 3) Server side resolvers do not gain any additional information that is not available from the fronting servers already. As Patrick wrote, local resolvers typically have information correlating the IP address with the user's identity. Off path resolvers and server side resolvers may or may not have that information. Off path resolvers could obtain it if they correlate their logs with tracking data from advertisement systems. Server side resolvers could obtain that information from the locally served web sites. -- Christian Huitema --------------076EF8641320FF6906E0ED4E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

On 11/27/2019 12:45 AM, Livingood, Jason wrote:

On 11/24/19, 9:03 PM, "Add on behalf of Christian Huitema" <add-bounces@ietf.org on behalf of huitema@huitema.net> wrote:

   We can consider three actors: the local network provider, the DNS

    resolver, and the web hoster.and that the Each of them will receive some
    information about the transaction:


* The local network will see the IP addresses of server and client, and

    the name of the fronting server in the "public" SNI. (The same
    information is available to all on path observers.)

[JL] As you note parenthetically this is true of any network along the end to end path between the client and the server. From a threat assessment standpoint those non-local network providers may be a greater risk (bumps in the wire), particularly as they are likely unknown to end users (such as transit networks or submarine link providers). So I would recommend you not focus on just a local network but more broadly to any network on the E2E path.

Jason, my point was really about comparing the additional information obtained by resolvers at different locations when processing different kinds of DNS requests. I consider three kinds of resolvers: local (typically managed by ISP), off path (like the various x.x.x.x), and near the server (e.g. a Cloudflare server when processing requests for domains served by Cloudflare's CDN). I also consider two kinds of requests: A or AAAA, and HTTPSRV used to obtain ESNI data.

For A/AAAA queries, the results are:

1) Local resolvers do not gain any additional information that is not available on-path already

2) Off-path resolvers gain information that IP address X is querying fronting server F at time T

3) Server side resolvers do not gain any additional information that is not available from the servers already.

For HTTPSRV queries, the results are:

1) Local resolvers do gain information that IP address X may be interested in hidden server H, and can correlate that with later traffic to fronting server F

2) Off path resolvers do gain information that IP address X may be interested in hidden server H, but cannot correlate that with later traffic if they do not also process the later A/AAAA queries

3) Server side resolvers do not gain any additional information that is not available from the fronting servers already.

As Patrick wrote, local resolvers typically have information correlating the IP address with the user's identity. Off path resolvers and server side resolvers may or may not have that information. Off path resolvers could obtain it if they correlate their logs with tracking data from advertisement systems. Server side resolvers could obtain that information from the locally served web sites.

-- Christian Huitema

--------------076EF8641320FF6906E0ED4E-- From nobody Fri Nov 29 05:56:17 2019 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 8F7E7120220 for ; Fri, 29 Nov 2019 05:56:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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=zrSm77Ur; dkim=pass (2048-bit key) header.d=comcast.com header.b=saXOJPC5; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=nrEMp3BY 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 m9sUTn-4P7as for ; Fri, 29 Nov 2019 05:56:12 -0800 (PST) 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 C1A6C1200E9 for ; Fri, 29 Nov 2019 05:56:12 -0800 (PST) Received: from pps.filterd (m0184891.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xATDmYTI020521 for ; Fri, 29 Nov 2019 08:56:12 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.com; h=from : to : cc : subject : date : message-id : content-type : mime-version; s=20190412; bh=ZDplZ/hxO1DGbAMZdLIvtRwCr9pz8YWgPXV7Zu+wZ/o=; b=zrSm77Ur8qUk5p9b/0fZpSvdnQzzIQYDIRDXEku3B921KiLiUREsBH9Z3yXiyEkg74bx fGqEPwsdKRQBxG/G0vUDI9xUY2/gzD/73Yo1h+tyyVR1mUE1bRhhF6ZHzfTH7c3EuLd1 IIOzR+lyD4uKbnrJ5bwn0o9KBs3w5Y8gqBTRXhvrRMGVOawhnaQu07OIOxYqoGR6uudq bS/70/GcT65oTdBh9JpTnwcbLwpcu4SmLQvWeSzoXEEzlVW4Ru3tXFCZzmE6VqYFmbO/ 654jl2ua3geSxhVu5DyrYGL9guyVL3YgjSTZDCCI5C0cFXOvlhYJFLUgKXKqFMHkpx1b nQ== Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) by mx0b-00143702.pphosted.com with ESMTP id 2whcx66pjf-103 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 29 Nov 2019 08:56:11 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1575035744; x=2438949344; 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=ZDplZ/hxO1DGbAMZdLIvtRwCr9pz8YWgPXV7Zu+wZ/o=; b=saXOJPC5tJjOaFNNJGBaqTJTjWdUjy6irpTs7MjcsYJOtdQB2WHU8HIBCnPcGQqF zYbMVjqMHozslP0+Z6oR+JRs1JK7GzNmalWFzYgbv7tyapNBe7Ek+Hcq+8w3ZLxT vjki6syShoK+t3r40lWIOQABq8fWliiRsQ46nxtAZhgoWyiVRfhiLcd4bK5iq4Ec MG51CnYSnwIApCeeLe9y5sDHnA7uytYSBMjNbZxdms0rWgFm1jBm9h8N73tzK5Wm lUpe2D67hYCkaKOO5lulNUcYKwatRg883iYVQUDWq9G+n8ECMY3ZJT7pYt+bmH9G z5OmagGZdkrpWMN4FWiTtQ==; X-AuditID: a2962c47-ac7ff70000015d6b-00-5de12360e6ef Received: from COPDCEX22.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 AD.26.23915.06321ED5; Fri, 29 Nov 2019 06:55:44 -0700 (MST) Received: from COPDCEX22.cable.comcast.com (147.191.124.153) by COPDCEX22.cable.comcast.com (147.191.124.153) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Nov 2019 06:56:09 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX22.cable.comcast.com (147.191.124.153) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 29 Nov 2019 06:56:09 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (104.47.41.56) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Nov 2019 08:56:08 -0500 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB3879.namprd11.prod.outlook.com (10.255.162.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.21; Fri, 29 Nov 2019 13:56:07 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a%7]) with mapi id 15.20.2474.023; Fri, 29 Nov 2019 13:56:07 +0000 From: "Livingood, Jason" To: Patrick McManus CC: Christian Huitema , "add@ietf.org" Thread-Topic: [Add] Not looking at DNS privacy in isolation Thread-Index: AQHVpry/rxEziq1T50S85OH2/hmRlg== Date: Fri, 29 Nov 2019 13:56:07 +0000 Message-ID: <2C53815C-D874-4299-A6AF-F433D063D061@cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-originating-ip: [71.225.154.72] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3000cd43-3b52-49a5-3bd8-08d774d3e233 x-ms-traffictypediagnostic: BY5PR11MB3879: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-forefront-prvs: 0236114672 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39860400002)(136003)(366004)(199004)(189003)(256004)(14444005)(606006)(26005)(6506007)(33656002)(53546011)(102836004)(71190400001)(71200400001)(5660300002)(66066001)(6116002)(3846002)(80792005)(8676002)(81156014)(81166006)(25786009)(8936002)(966005)(14454004)(2906002)(76116006)(6916009)(6246003)(66556008)(66476007)(64756008)(66446008)(229853002)(66946007)(7736002)(316002)(99286004)(2616005)(4326008)(91956017)(6486002)(58126008)(186003)(86362001)(236005)(6512007)(6436002)(54906003)(6306002)(54896002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB3879; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: BD2bKiyPhtgNkKCezPCmXBC72D2TP67OEE/VYYPnmq4eiGHKZ77UE6uS4HHKFyqYqmJ4k24C7+BX/rkxWmI0PV/oyrxFTr+bKyfc3xdQFwgSwtp/eKCNUwus9B3owKR62bMNOcKPXSGv43D6j2Z+hhjOoEWrD7eEdJbha2KLgzKoRaXffKUos3nNxyQhRjk64Wv8t4M8OoFYc40W0vjZXuQ76X2edsMCX1nD6E+8TCgldFdl2/eG/26zESkzQYXGxiJi9qRQcwPzb87Q4H2tWeWVXzIgE2kuOfQNb/R4fZGRAqxdQYpiTk5+794SQvmNGIlqqHA9tCDSecbLqxljESMwfWjknoDfshJ96qRiPfiFRFirTd8kOd75ZheS74bg7zz/t2j1eel/2PaqnyF/th5YhLOkb84uOpE/2saN9vFuqXldzCaAPmqrbGVHe4mJGCqDLh/S9xHjoWqcq9Zu1cwh2Nv/15GDg9ujrn33n9U= x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GrlV+b2f8iOyqK4OuEVqBGIx2GcOutkEVqVUVbbM2GhOQISEuJifa+lpsNHQSS3XQwD3N5C5q6SGnA6InPgpPTHJGfAZfJk5ZqGzWhkB+GwCfesAPi9JibXsynJoFV4ZLncT8fqC9VLMBICIAB/NRpJAb0CyYwFnhxDMdhdArCoFhxdNYEhzn2/kj9nOX+bwGwomdQNM8lpcf1qVi0N0ATBz8i2zEM1nhX3G4hAZZDFxNwpR3n5LbIrFQRZg8Yl7i6K3wSvq/MduhNG25CKT/NtEmehbMIzDV2wrh7Siplmsvmc6+s4O3LAg94cCY1CrEgUQYSSOAMAmH6HPieo58g== 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=XfsS/1CxHySTcBTZ2TKFHkOPaYB/AMDaENidwO53j20=; b=lCjDZU6EHcSv63N2ftFRjr9sfmxUQK5gCMFyvMWbcoqrTyVGcglK56SN6AOrMJ2hLwDoHUy3jbDYwk8CgNaF/lz1CD9L7qJ2iB41jN0bG0IcU70JipSJnKFdCgR88TPGNva59YYpoeWTBYaCqMF3fA8pngjfEMXVDXrTE2SMNjoTgu7nE8IUbEqkP5XL2UqbqyEylEXuvRKE8EYf4B0fBXCtA17UYsC/GYVQrgdsJGlWG5BwkDgFXnl4Y3ZdqLimcerz/PmtUtZdtDv5cZxJpRwACwZsoe36wTVljpO+1Z2zzvBbUskDAEFIZaL10dfrr9R6j2MuZQtLKh4vFZNRhQ== 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=XfsS/1CxHySTcBTZ2TKFHkOPaYB/AMDaENidwO53j20=; b=nrEMp3BY5ZcwC9z+F8llkkOT05FrwGsW8WHAu/icelzwGRbITO8LubPv59xk9OIvl2+X79VAD+sA/5377+2ANWLNHWVz3vHWKT9LLrfYg+teQvGqc5eI2MHAU35QswiW2phI0SEHbEAD+qZT9vwcsGVloN9C2MVSsM6v0Ozzzho= x-ms-exchange-crosstenant-network-message-id: 3000cd43-3b52-49a5-3bd8-08d774d3e233 x-ms-exchange-crosstenant-originalarrivaltime: 29 Nov 2019 13:56:07.6435 (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: KAqQ/m0KegSaN7MbEAJo9MzZqNBmPKNTt9v7MrvPGqZB0xkmbTwEeNj7dWfjeiyyZco11FKg1iC+WUZYOWPJeBGZ5Cv8hYNsn+5x6DqMJAo= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB3879 x-originatororg: cable.comcast.com Content-Type: multipart/alternative; boundary="_000_2C53815CD8744299A6AFF433D063D061cablecomcastcom_" MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA22SbUhTURjHO/febVdpcF2pT++6yEpqNjETsygwlCyyoj5UI694dOYyu7Nw BbWitK5FmWY5lZVKiDol7UXFxJc+WBYzm6ZD0fViyAoGIhb0tu1eQcjz6fe/53f+8Jx7aFJR L11Kp2dmYy6T1SmlvlQSV1a4MWm1Q7NpamRJ1N/eemlU4aVSWdRkaR3aQca3XLWgePv911R8 VdVPIpE8YkQx2VoOs9mxOBVn6vF236D/VkwyTj3F4V0spzMcwDrMzq95zBSsSz+LubB5a8Lm 7UmyEVpL3y1J1rNDObzxj9SI8g7yyIcGJgImhvIIHvnSCqabgBLLNTF0Iaj+1SkRwgiCl/ZS MfQgaLbXSoVQRMCTD/eQED4iuD7BSzzNUiYSRh/aSA8vZkKh/fKEzMMksxvK39Z5nUVMNHyb bkCCsxUs9T2EwCqwmpu8PsWsgf5aK+VhORMLrR3T3rOICYCZ13WE0BkI9s9mQpiIgao2Kymw P0x++uP1/ZkwGOFfyISzKVDJV4h+MAzW9CGBV0C/OV/kvTD8uFp0QsF695LYmQFXXLzohMDU F5v4fTmY3rd7rwiYQQl0dl52b9DuWzkB3we2C85KqLnpoGb98aHn0ttIbZozgsBp0G9/JzN5 R/aDVyWfKZO7iWTWQ0NrmKAEQ1G+QybwOrhaVi5yPBQ1jqK5zgNE1yC5OjJcpd68SRURodqi bkTuV1xRvCGuGbmsmi7E0Ei5UL6IdmgUEvas3nDS/fNpUrlYnlw+plHIU1jDOcydOs6d0WF9 F1pGU8pA+cUxs0bBpLHZOAPjLMzN7hK0z1IjykzkbzVXTzbpJD0WQ8CP9PHcG6crO9bGweFt PQZXc/+auGM2ouQO3fUjOmun0mKZtn2kF6xydhQ/9VPmnteqC5yhy0OmLc+U+wYSHAUxxkc5 FS1tQb0zR9ft+cp3X3jjHBqO/G3Ish1B9gnzve77zgSXM3b/ynfa24QqOtA/XEnptaw6lOT0 7D+yEJK7wQMAAA== X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-29_04:2019-11-29,2019-11-29 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] Not looking at DNS privacy in isolation 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, 29 Nov 2019 13:56:16 -0000 --_000_2C53815CD8744299A6AFF433D063D061cablecomcastcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmW0gbm90IGFyZ3VpbmcgdGhhdCB0aGUgbG9jYWwgbmV0d29yayBub3QgYmUgY29uc2lkZXJl ZCBhIHBvdGVudGlhbCB0aHJlYXQuIFJhdGhlciwgdGhhdCBhbnkgbmV0d29yayBhbG9uZyB0aGUg RTJFIHBhdGggYmUgY29uc2lkZXJlZCBhIHBvdGVudGlhbCB0aHJlYXQgc2luY2UgdGhlIGxhc3Qg aG9wIG5ldHdvcmsgaXMgbm90IHRoZSBvbmx5IG9uZSBhYmxlIHRvIHN1cnZlaWwvYmxvY2svbW9k aWZ5IEROUyB0cmFmZmljLg0KDQpKTA0KDQpGcm9tOiBQYXRyaWNrIE1jTWFudXMgPG1jbWFudXNA ZHVja3NvbmcuY29tPg0KRGF0ZTogVHVlc2RheSwgTm92ZW1iZXIgMjYsIDIwMTkgYXQgMjowMiBQ TQ0KVG86ICJMaXZpbmdvb2QsIEphc29uIiA8SmFzb25fTGl2aW5nb29kQGNhYmxlLmNvbWNhc3Qu Y29tPg0KQ2M6IENocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PiwgImFkZEBp ZXRmLm9yZyIgPGFkZEBpZXRmLm9yZz4NClN1YmplY3Q6IFtFWFRFUk5BTF0gUmU6IFtBZGRdIE5v dCBsb29raW5nIGF0IEROUyBwcml2YWN5IGluIGlzb2xhdGlvbg0KDQpvdG9oIHRoZSBsb2NhbCBu ZXR3b3JrIGlzIHByb2JhYmx5IHJlc3BvbnNpYmxlIGZvciB0aGUgSVAgYXNzaWdubWVudCBhbmQs IGVzcGVjaWFsbHkgd2hlbiBrbm93biB0byB0aGUgZW5kIHVzZXIsIGlzIGNhcGFibGUgb2YgbWFw cGluZyB0aGF0IGRpcmVjdGx5IHRvIHJlYWwtbGlmZSBpZGVudGl0eSBhbmQgb3RoZXIgYml0cyBv ZiBwcm9maWxlIGxpbmtlZCB0byB0aGF0IGlkZW50aXR5LiBUaGlzIGdpdmVzIHRoZW0gYSBzb21l d2hhdCB1bmlxdWUgdGhyZWF0IGF0dHJpYnV0ZSB0byBiZSBjb25zaWRlcmVkLg0KDQotUA0KDQoN Ck9uIFR1ZSwgTm92IDI2LCAyMDE5IGF0IDExOjQ1IEFNIExpdmluZ29vZCwgSmFzb24gPEphc29u X0xpdmluZ29vZEBjb21jYXN0LmNvbTxtYWlsdG86SmFzb25fTGl2aW5nb29kQGNvbWNhc3QuY29t Pj4gd3JvdGU6DQpPbiAxMS8yNC8xOSwgOTowMyBQTSwgIkFkZCBvbiBiZWhhbGYgb2YgQ2hyaXN0 aWFuIEh1aXRlbWEiIDxhZGQtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86YWRkLWJvdW5jZXNAaWV0 Zi5vcmc+IG9uIGJlaGFsZiBvZiBodWl0ZW1hQGh1aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1 aXRlbWEubmV0Pj4gd3JvdGU6DQo+ICAgIFdlIGNhbiBjb25zaWRlciB0aHJlZSBhY3RvcnM6IHRo ZSBsb2NhbCBuZXR3b3JrIHByb3ZpZGVyLCB0aGUgRE5TDQogICAgcmVzb2x2ZXIsIGFuZCB0aGUg d2ViIGhvc3Rlci5hbmQgdGhhdCB0aGUgRWFjaCBvZiB0aGVtIHdpbGwgcmVjZWl2ZSBzb21lDQog ICAgaW5mb3JtYXRpb24gYWJvdXQgdGhlIHRyYW5zYWN0aW9uOg0KDQo+ICogVGhlIGxvY2FsIG5l dHdvcmsgd2lsbCBzZWUgdGhlIElQIGFkZHJlc3NlcyBvZiBzZXJ2ZXIgYW5kIGNsaWVudCwgYW5k DQogICAgdGhlIG5hbWUgb2YgdGhlIGZyb250aW5nIHNlcnZlciBpbiB0aGUgInB1YmxpYyIgU05J LiAoVGhlIHNhbWUNCiAgICBpbmZvcm1hdGlvbiBpcyBhdmFpbGFibGUgdG8gYWxsIG9uIHBhdGgg b2JzZXJ2ZXJzLikNCg0KW0pMXSBBcyB5b3Ugbm90ZSBwYXJlbnRoZXRpY2FsbHkgdGhpcyBpcyB0 cnVlIG9mIGFueSBuZXR3b3JrIGFsb25nIHRoZSBlbmQgdG8gZW5kIHBhdGggYmV0d2VlbiB0aGUg Y2xpZW50IGFuZCB0aGUgc2VydmVyLiBGcm9tIGEgdGhyZWF0IGFzc2Vzc21lbnQgc3RhbmRwb2lu dCB0aG9zZSBub24tbG9jYWwgbmV0d29yayBwcm92aWRlcnMgbWF5IGJlIGEgZ3JlYXRlciByaXNr IChidW1wcyBpbiB0aGUgd2lyZSksIHBhcnRpY3VsYXJseSBhcyB0aGV5IGFyZSBsaWtlbHkgdW5r bm93biB0byBlbmQgdXNlcnMgKHN1Y2ggYXMgdHJhbnNpdCBuZXR3b3JrcyBvciBzdWJtYXJpbmUg bGluayBwcm92aWRlcnMpLiBTbyBJIHdvdWxkIHJlY29tbWVuZCB5b3Ugbm90IGZvY3VzIG9uIGp1 c3QgYSBsb2NhbCBuZXR3b3JrIGJ1dCBtb3JlIGJyb2FkbHkgdG8gYW55IG5ldHdvcmsgb24gdGhl IEUyRSBwYXRoLg0KDQoNCi0tDQpBZGQgbWFpbGluZyBsaXN0DQpBZGRAaWV0Zi5vcmc8bWFpbHRv OkFkZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYWRk PGh0dHBzOi8vdXJsZGVmZW5zZS5jb20vdjMvX19odHRwczovd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vYWRkX187IXJ4X0w3NUlUZ09RIVFLOGdFd05kWUZsSXJIaHNiWkVTUHlzbjJ5UTBv LVVtYWNGQ19oRmZjRk44VWs5alRIYkg2b1VNYkhiYVM5ekpSNnEtMVEkPg0K --_000_2C53815CD8744299A6AFF433D063D061cablecomcastcom_ Content-Type: text/html; charset="utf-8" Content-ID: <9F4B3D696F304D4D8DE08772E724864C@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4gXChCb2R5IENTXCkiOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30N Ci8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxNC4wcHQiPknigJltIG5vdCBhcmd1aW5nIHRoYXQgdGhlIGxvY2FsIG5ldHdv cmsgbm90IGJlIGNvbnNpZGVyZWQgYSBwb3RlbnRpYWwgdGhyZWF0LiBSYXRoZXIsIHRoYXQgYW55 IG5ldHdvcmsgYWxvbmcgdGhlIEUyRSBwYXRoIGJlIGNvbnNpZGVyZWQgYSBwb3RlbnRpYWwgdGhy ZWF0IHNpbmNlIHRoZSBsYXN0IGhvcCBuZXR3b3JrIGlzIG5vdCB0aGUgb25seSBvbmUgYWJsZQ0K IHRvIHN1cnZlaWwvYmxvY2svbW9kaWZ5IEROUyB0cmFmZmljLiA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjE0LjBwdCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPkpMPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNC4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29s aWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5G cm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNr Ij5QYXRyaWNrIE1jTWFudXMgJmx0O21jbWFudXNAZHVja3NvbmcuY29tJmd0Ozxicj4NCjxiPkRh dGU6IDwvYj5UdWVzZGF5LCBOb3ZlbWJlciAyNiwgMjAxOSBhdCAyOjAyIFBNPGJyPg0KPGI+VG86 IDwvYj4mcXVvdDtMaXZpbmdvb2QsIEphc29uJnF1b3Q7ICZsdDtKYXNvbl9MaXZpbmdvb2RAY2Fi bGUuY29tY2FzdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6IDwvYj5DaHJpc3RpYW4gSHVpdGVtYSAmbHQ7 aHVpdGVtYUBodWl0ZW1hLm5ldCZndDssICZxdW90O2FkZEBpZXRmLm9yZyZxdW90OyAmbHQ7YWRk QGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bRVhURVJOQUxdIFJlOiBbQWRkXSBO b3QgbG9va2luZyBhdCBETlMgcHJpdmFjeSBpbiBpc29sYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm90b2ggdGhlIGxvY2Fs IG5ldHdvcmsgaXMgcHJvYmFibHkgcmVzcG9uc2libGUgZm9yIHRoZSBJUCBhc3NpZ25tZW50IGFu ZCwgZXNwZWNpYWxseSB3aGVuIGtub3duIHRvIHRoZSBlbmQgdXNlciwgaXMgY2FwYWJsZSBvZiBt YXBwaW5nIHRoYXQgZGlyZWN0bHkgdG8gcmVhbC1saWZlIGlkZW50aXR5IGFuZCBvdGhlciBiaXRz IG9mIHByb2ZpbGUgbGlua2VkIHRvIHRoYXQgaWRlbnRpdHkuIFRoaXMgZ2l2ZXMgdGhlbQ0KIGEg c29tZXdoYXQgdW5pcXVlIHRocmVhdCBhdHRyaWJ1dGUgdG8gYmUgY29uc2lkZXJlZC4gPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tUDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgTm92IDI2 LCAyMDE5IGF0IDExOjQ1IEFNIExpdmluZ29vZCwgSmFzb24gJmx0OzxhIGhyZWY9Im1haWx0bzpK YXNvbl9MaXZpbmdvb2RAY29tY2FzdC5jb20iPkphc29uX0xpdmluZ29vZEBjb21jYXN0LmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAw aW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5PbiAxMS8yNC8xOSwg OTowMyBQTSwgJnF1b3Q7QWRkIG9uIGJlaGFsZiBvZiBDaHJpc3RpYW4gSHVpdGVtYSZxdW90OyAm bHQ7PGEgaHJlZj0ibWFpbHRvOmFkZC1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ YWRkLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmh1 aXRlbWFAaHVpdGVtYS5uZXQiIHRhcmdldD0iX2JsYW5rIj5odWl0ZW1hQGh1aXRlbWEubmV0PC9h PiZndDsgd3JvdGU6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgV2UgY2FuIGNvbnNpZGVyIHRocmVl IGFjdG9yczogdGhlIGxvY2FsIG5ldHdvcmsgcHJvdmlkZXIsIHRoZSBETlM8YnI+DQombmJzcDsg Jm5ic3A7IHJlc29sdmVyLCBhbmQgdGhlIHdlYiBob3N0ZXIuYW5kIHRoYXQgdGhlIEVhY2ggb2Yg dGhlbSB3aWxsIHJlY2VpdmUgc29tZTxicj4NCiZuYnNwOyAmbmJzcDsgaW5mb3JtYXRpb24gYWJv dXQgdGhlIHRyYW5zYWN0aW9uOjxicj4NCjxicj4NCiZndDsgKiBUaGUgbG9jYWwgbmV0d29yayB3 aWxsIHNlZSB0aGUgSVAgYWRkcmVzc2VzIG9mIHNlcnZlciBhbmQgY2xpZW50LCBhbmQ8YnI+DQom bmJzcDsgJm5ic3A7IHRoZSBuYW1lIG9mIHRoZSBmcm9udGluZyBzZXJ2ZXIgaW4gdGhlICZxdW90 O3B1YmxpYyZxdW90OyBTTkkuIChUaGUgc2FtZTxicj4NCiZuYnNwOyAmbmJzcDsgaW5mb3JtYXRp b24gaXMgYXZhaWxhYmxlIHRvIGFsbCBvbiBwYXRoIG9ic2VydmVycy4pPGJyPg0KPGJyPg0KW0pM XSBBcyB5b3Ugbm90ZSBwYXJlbnRoZXRpY2FsbHkgdGhpcyBpcyB0cnVlIG9mIGFueSBuZXR3b3Jr IGFsb25nIHRoZSBlbmQgdG8gZW5kIHBhdGggYmV0d2VlbiB0aGUgY2xpZW50IGFuZCB0aGUgc2Vy dmVyLiBGcm9tIGEgdGhyZWF0IGFzc2Vzc21lbnQgc3RhbmRwb2ludCB0aG9zZSBub24tbG9jYWwg bmV0d29yayBwcm92aWRlcnMgbWF5IGJlIGEgZ3JlYXRlciByaXNrIChidW1wcyBpbiB0aGUgd2ly ZSksIHBhcnRpY3VsYXJseSBhcyB0aGV5IGFyZQ0KIGxpa2VseSB1bmtub3duIHRvIGVuZCB1c2Vy cyAoc3VjaCBhcyB0cmFuc2l0IG5ldHdvcmtzIG9yIHN1Ym1hcmluZSBsaW5rIHByb3ZpZGVycyku IFNvIEkgd291bGQgcmVjb21tZW5kIHlvdSBub3QgZm9jdXMgb24ganVzdCBhIGxvY2FsIG5ldHdv cmsgYnV0IG1vcmUgYnJvYWRseSB0byBhbnkgbmV0d29yayBvbiB0aGUgRTJFIHBhdGguPGJyPg0K PGJyPg0KPGJyPg0KLS0gPGJyPg0KQWRkIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0 bzpBZGRAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5BZGRAaWV0Zi5vcmc8L2E+PGJyPg0KPGEg aHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLmNvbS92My9fX2h0dHBzOi93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9hZGRfXzshcnhfTDc1SVRnT1EhUUs4Z0V3TmRZRmxJckhoc2JaRVNQeXNu MnlRMG8tVW1hY0ZDX2hGZmNGTjhVazlqVEhiSDZvVU1iSGJhUzl6SlI2cS0xUSQiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2FkZDwvYT48bzpw PjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0 bWw+DQo= --_000_2C53815CD8744299A6AFF433D063D061cablecomcastcom_-- From nobody Fri Nov 29 06:00:36 2019 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 B34211200E9 for ; Fri, 29 Nov 2019 06:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-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=dKP6ajdT; dkim=pass (2048-bit key) header.d=comcast.com header.b=nGQAUF6I; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=comcastcorp.onmicrosoft.com header.b=qFIYxVnB 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 rKLTFdQOZIg0 for ; Fri, 29 Nov 2019 06:00:32 -0800 (PST) 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 F2DCF12011D for ; Fri, 29 Nov 2019 06:00:31 -0800 (PST) Received: from pps.filterd (m0184891.ppops.net [127.0.0.1]) by mx0b-00143702.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id xATDmYQa020232 for ; Fri, 29 Nov 2019 09:00:31 -0500 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=nLXs8qSTietBPpdQuADlq3XC8YQxAr00nfEHi3YgQE8=; b=dKP6ajdTwW4xIa1MKQw7WvJUyb/r4D2WW2ukB8oWhVK/JTSYeDAje/pICqe7UYxfTGax LUWuUtPatV1bwIxpT9F5iexGWojBbiofvF4DbsbVk68HBfHA+/e+DSbwVMqg5fii4S0H d0yP5182TOhbLH3QcNI+/sV0f6TT4ZPzgrCEmdFp7/bCQKbnwtFjPAF/j8vttJWeEg1t OQhr3q6G3pjeptpRy7zQzJLvDlT1pgGliZ8OIoXHuozEwpof48D1UP2DvUkVSsQFlZZA IqgLBsa5tuDZLLkAK+AuadnunrO/Iy7JV9nXhvOl/TbgSOHuklkUyDQUyp7yHXFhnuSk pw== Received: from copdcmhout01.cable.comcast.com (copdcmhout01.cable.comcast.com [162.150.44.71]) by mx0b-00143702.pphosted.com with ESMTP id 2whcx66q69-45 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Fri, 29 Nov 2019 09:00:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; d=comcast.com; s=20190412; c=relaxed/simple; q=dns/txt; i=@comcast.com; t=1575036004; x=2438949604; 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=nLXs8qSTietBPpdQuADlq3XC8YQxAr00nfEHi3YgQE8=; b=nGQAUF6IrGHh8HU0fjaSJqv42rwf+zoPqOxPO/l+udUrTEY1pmraOzS9RqgrX0KM KnAi7UhRSoZ4YiLsrROyiiIXBtxcqznJJLfv8G4m3vVPfyM0APGWG4JmGSusm7zO mxXdtt6yRXBJwano0Vzrj8FA3IzAlgCKU76mhKKyZn+2S8rqDHZLQy+Wta8mfghe k/OhYuHd3p/JEHH4EYQTwiOG2XOvl4d/JUXrdpfy3GbSXBtUQt8sLWHJPGBnqIPk ylc3DXy6DH21yCsvI0lKxF84SVlD3i024p5HTkpMz3bKfvG8jg5ZpzXlJKB05YUG OQSrs3dHEsE9AN/zkVyBFg==; X-AuditID: a2962c47-ac7ff70000015d6b-32-5de124649385 Received: from COPDCEXC38.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 49.56.23915.46421ED5; Fri, 29 Nov 2019 07:00:04 -0700 (MST) Received: from COPDCEX10.cable.comcast.com (147.191.124.141) by COPDCEXC38.cable.comcast.com (147.191.125.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Fri, 29 Nov 2019 07:00:29 -0700 Received: from COPDCEXEDGE01.cable.comcast.com (96.114.158.213) by COPDCEX10.cable.comcast.com (147.191.124.141) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 29 Nov 2019 07:00:29 -0700 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (104.47.41.56) by webmail.comcast.com (96.114.158.213) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Nov 2019 09:00:19 -0500 Received: from BY5PR11MB4403.namprd11.prod.outlook.com (52.132.252.96) by BY5PR11MB3879.namprd11.prod.outlook.com (10.255.162.209) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.21; Fri, 29 Nov 2019 14:00:18 +0000 Received: from BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a]) by BY5PR11MB4403.namprd11.prod.outlook.com ([fe80::c15e:699c:749e:790a%7]) with mapi id 15.20.2474.023; Fri, 29 Nov 2019 14:00:18 +0000 From: "Livingood, Jason" To: Christian Huitema , "add@ietf.org" Thread-Topic: [Add] Not looking at DNS privacy in isolation Thread-Index: AQHVpr1ULxPfo1shBEqtZwVBSAXcrw== Date: Fri, 29 Nov 2019 14:00:17 +0000 Message-ID: <39FC0356-A265-4730-AE86-C8C6AE5F1D4B@cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1f.0.191110 x-originating-ip: [71.225.154.72] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 491efffb-904c-49d8-e7c1-08d774d4778d x-ms-traffictypediagnostic: BY5PR11MB3879: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0236114672 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(396003)(39860400002)(136003)(366004)(199004)(189003)(256004)(26005)(6506007)(4744005)(33656002)(102836004)(71190400001)(71200400001)(5660300002)(66066001)(6116002)(3846002)(80792005)(2501003)(8676002)(81156014)(81166006)(25786009)(8936002)(14454004)(2906002)(76116006)(6246003)(66556008)(66476007)(64756008)(66446008)(229853002)(66946007)(7736002)(305945005)(316002)(99286004)(2616005)(91956017)(6486002)(110136005)(58126008)(186003)(86362001)(6512007)(6436002)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY5PR11MB3879; H:BY5PR11MB4403.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cable.comcast.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yDfHngeR/9jR/ZpfbNHlQXkW6SbQuwweHiMXU+D9++94x+p1J8+QZDHeqGTaGh3afHyJgxbj8RhLPoBUWJ6orPUT57jywhnSl2Q6eMbDMQ1JZzYBb61QAjZakIEMNlDlzvVp+AWll/pf2yUi9qlCAKTg1vjj1IkHINv0kqJLYVZUgYwe+ultAIZpYsOmt+h4JSo7vVRjYlm47zXC2qoSwYLxRCqQl1kLt/o+tWPl5ZrkmauR/FKrpz969CAp1pW1BWnabkkkgv5hBPY7R3+QzGTcm7CIQms2Svb6hK9wtV2Y23zvc9zkPZbsSwAYAFAxtf3TN3a7KU5sULkGDQxHxpxOnfhV8CyR1ukn8pLw4c56pOoAW7vWhve+ixTWpzgAdJOgf7GV2oyvT+3NPQAActRSbNJ1HmJXuZsnmQ0lgB2UyreYqTSdZIbrfgTjFFh1 x-ms-exchange-transport-forked: True arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T7o0PDcSqHZjKE8uxQUkwGTabdeozAH2epq9UrLMy7j2ugdf3QfngQudlSm7kE+7/I80A1jjtPL7cK/hkLkiOQ6guzfx58tmnzsZPQh7UIwjq0vvd+K1BGmBEi7w8KmNYN7ddWjcpjXqDBC5aSTzpFVY1CWbyXbWfDLWhlK0X9zaa4qml2LM3YD2EsrOdDIiGpq+IkNIY35Hsb7ClTf0H+smdxQKuLg0Setik8mxZEqdmSIj4gXgbHUfLYHPnCwaoFNH9qIdFa8dqr9uUrepHDGBUQUofzcFKQ/GLPNF298aMwxOudhDGItEs74XDP0o6bxNeyWPvhh06HcCxwJHQQ== 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=j0BIW5QnOxmkEqmAgODviXlV0UUBtlt/q33DU1dArnE=; b=EQNya671Av4fb+jLAxGDPRCMxoSZRMeh5Ex1r6Re4Fhe5fO+EsAVY9kSFTJWl6b6yRSIVeWosqQ6lHwHLXjlAfDRKTpaOAB60aqgGUoUQoQsohYMZzGQEFzMPbWYIhzceXrUNmWc+ljjODDZGdvkxJ3/NkzH1ru8ZTvxtgn196haBOZvJQc4wEwGnnfDBXNI6eSyWx3w/NtZZ1eDBZGuDw/YKythKNsMDlCCTULbB4psqhcYo4alFyxuHhxvIQYseptC1BJruM+CwEcwUhZ6FjhZHqGheBkO1S7Ih218ZnxFoLF3au+1REKbeM6iIzgSebq3WcoUBLa6+paUrcgURw== 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=j0BIW5QnOxmkEqmAgODviXlV0UUBtlt/q33DU1dArnE=; b=qFIYxVnBsFcqtBaJwfS3EEB16tk3HwpILrz0BHt0Kuvbmnztz2/mEVyx9FeShwSUuMKpfe1t+ZjLyesq3IxyjkBJDr9EbkhssqfOTas3hPU9tFPejo8n7I1z/1jzB55cXBxbOnGcOxqOWiwKa+9nYEMH7fPb0erjykYDMGDwMxQ= x-ms-exchange-crosstenant-network-message-id: 491efffb-904c-49d8-e7c1-08d774d4778d x-ms-exchange-crosstenant-originalarrivaltime: 29 Nov 2019 14:00:17.9994 (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: tyGtehbou90PyK/N8xkbiQ9l4A/BxTQS41PtIFdNK8K2BaN9SzexB9GR+oEEq+6d3X3Ywpea936yYjQORmplpeFmXOJbxyJgTZ/6SybSXxE= x-ms-exchange-transport-crosstenantheadersstamped: BY5PR11MB3879 x-originatororg: cable.comcast.com Content-Type: text/plain; charset="utf-8" Content-ID: <33FCE9757E7433478F9407F5367CC955@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Forward X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrPKsWRmVeSWpSXmKPExsWSUDRnsm6KysNYg/eTJC3+n17HZjG5cTa7 A5PHrRmnWDyWLPnJFMAU1cBoU5JRlJpY4pKalppXnGrHpYABbJJS0/KLUl0Ti3Iqg1JzUhOx KwOpTEnNySxLLdLHaow+VnMSupgyLi7exFxwjr3i1M6vTA2MW9i7GDk5JARMJN7+nsDcxcjF ISRwhEli/vr7UE4zk0T7xxksEM4dRommo/dZIZwTjBI/1k2GcqYwSWx+dIEVZJiQwCNGiZ1r BEFsNgEzibsLrzCD2CICXhLXW36DLRQWsJJ483U9I0TcWmLtuhNMELaexK3evWxdjBwcLAKq Ej235UHCvAIuEldfrwQbwyggJvH91BqwcmYBcYlbT+YzQfwgILFkz3lmCFtU4uXjf2DniAro S9zp2ssO0ZsisbhrEVS9osS1VRcYIWxZiUvzu6FsX4nl375B2VoS56c2Qs3Mljj6fxGUrSZx 400HlC0jMevyPnA4SAgsZpXYvfI/M8j9QgJZEm+v2kHUyEms6n3IAlP/4MZ2Noj6x8wSd9tW sUxgNJqF5J9ZQO3MApoS63fpQ4Q9JN7cfcgCYStKTOl+yD4LHCyCEidnPmFZwMi6ipHX0MxI z9DUQM/ERM/ccBMjMFkumqbjvoPxw/nYQ4wCHIxKPLzCHA9jhVgTy4orcw8xSnAwK4nwXlcC CvGmJFZWpRblxxeV5qQWH2KU5mBREuetvz8/VkggPbEkNTs1tSC1CCbLxMEp1cDIIKpiOOVY eHXiwjb3a5/3y0jE/yo2Pa+ooJV1uFP96tE0XSX3V7EvXicVLp5yMePUw+awGylBtb2KjyO9 9lzVOfBG7NbvuH9FN6KsBGcJTTa/+KPM9EjPzD8iBwNr3X8uOpn472IWu53GDa4Ht85k+THb zU9YHjvfcNKtKSyqi1fXyFzvrzRQYinOSDTUYi4qTgQAT6UoFJIDAAA= X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,18.0.572 definitions=2019-11-29_04:2019-11-29,2019-11-29 signatures=0 X-Proofpoint-Spam-Reason: safe Archived-At: Subject: Re: [Add] Not looking at DNS privacy in isolation 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, 29 Nov 2019 14:00:34 -0000 PiBBcyBQYXRyaWNrIHdyb3RlLCBsb2NhbCByZXNvbHZlcnMgdHlwaWNhbGx5IGhhdmUgaW5mb3Jt YXRpb24gY29ycmVsYXRpbmcgdGhlIElQIGFkZHJlc3Mgd2l0aCB0aGUgdXNlcidzIGlkZW50aXR5 LiBPZmYgcGF0aCByZXNvbHZlcnMgYW5kIHNlcnZlciBzaWRlIHJlc29sdmVycyBtYXkgb3IgbWF5 IG5vdCBoYXZlIHRoYXQgaW5mb3JtYXRpb24uIE9mZiBwYXRoIHJlc29sdmVycyBjb3VsZCBvYnRh aW4gaXQgaWYgdGhleSBjb3JyZWxhdGUgdGhlaXIgbG9ncyB3aXRoIHRyYWNraW5nIGRhdGEgZnJv bSBhZHZlcnRpc2VtZW50IHN5c3RlbXMuIFNlcnZlciBzaWRlIHJlc29sdmVycyBjb3VsZCBvYnRh aW4gdGhhdCBpbmZvcm1hdGlvbiBmcm9tIHRoZSBsb2NhbGx5IHNlcnZlZCB3ZWIgc2l0ZXMuDQoN CltKTF0gVGhlIGFiaWxpdHkgdG8gbGluayB0byBzb3VyY2UgSVAgYWRkcmVzcyBhbHNvIGV4aXN0 cyBmb3Igb3RoZXIgdHlwZXMgb2YgRE5TIG9wZXJhdG9ycyAodGhhdCBkbyBtb3JlIHRoYW4gRE5T KSBmcm9tIHJlbGF0ZWQvbGlua2FibGUgbm9uLUROUyBkYXRhc2V0cyAtIGFzIHlvdSBub3RlLiBJ IHN1cHBvc2UgbXkgb25seSBwb2ludCB3YXMgdGhhdCBhcyBwb3RlbnRpYWwgdGhyZWF0cyBhcmUg Y29uc2lkZXJlZCwgaXRzIGJlc3QgdG8gdGFrZSBhbiBleHBhbnNpdmUgdmlldyAoaXQgc2VlbXMg d2UgZ2VuZXJhbGx5IGFncmVlKS4NCg0KDQo= From nobody Fri Nov 29 10:19:16 2019 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 10713120058 for ; Fri, 29 Nov 2019 10:19:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 pNljm20WixC9 for ; Fri, 29 Nov 2019 10:19:12 -0800 (PST) Received: from nwk-aaemail-lapp03.apple.com (nwk-aaemail-lapp03.apple.com [17.151.62.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 2593712003F for ; Fri, 29 Nov 2019 10:19:12 -0800 (PST) Received: from pps.filterd (nwk-aaemail-lapp03.apple.com [127.0.0.1]) by nwk-aaemail-lapp03.apple.com (8.16.0.27/8.16.0.27) with SMTP id xATIH9oJ063719; Fri, 29 Nov 2019 10:19:08 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=RgQTyYP4tf1QZ0me7e1qXThxbIqbDI65xS2pfp9ZgMY=; b=SdrMXEy/8AinHRpLx36O/EdsEM2LT4NNLxC1/Cdt6xouA9VUFJA9lqTrPYavS6m1jYZt d4+FpYJx0SL12NeMlJHmznPFzLyxn4656ym49OwgBB6+4PEk9m3DTk58vmWkHO/qy52h Pj/jTAYrFycN1UsmKrA3BcbdzTrWAzh2FvHK3RaUBhulTeEGPnOQ+Ovd6Z8lIkCckYbh JcP2tz44JpSYGpJunaCk+NdvdntJ1rZMr7SyjVBlu53Fa8kVd8Aqx1vKiygvSix1MBIB 8ZGDycIa7+Aj6j//BxTxm7NTNkHoqBEJbhhw8LYyd9xXHzRzAPhC7tzgDE65z6+7dZn2 Cw== Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by nwk-aaemail-lapp03.apple.com with ESMTP id 2wfnvr4wp6-6 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 29 Nov 2019 10:19:07 -0800 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0Q1Q001CYTJPY210@ma1-mtap-s03.corp.apple.com>; Fri, 29 Nov 2019 10:19:01 -0800 (PST) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q1Q00F00TA1S400@nwk-mmpp-sz10.apple.com>; Fri, 29 Nov 2019 10:19:01 -0800 (PST) X-Va-A: X-Va-T-CD: 59cc6daf9acf7189bc5757ef88e94935 X-Va-E-CD: 437a9c953c5ac0e4083996215757c247 X-Va-R-CD: bf3209f7745b3c03be71427325f6a7b2 X-Va-CD: 0 X-Va-ID: f75e0231-c713-4005-aa88-a081f3cf6db9 X-V-A: X-V-T-CD: 59cc6daf9acf7189bc5757ef88e94935 X-V-E-CD: 437a9c953c5ac0e4083996215757c247 X-V-R-CD: bf3209f7745b3c03be71427325f6a7b2 X-V-CD: 0 X-V-ID: 3fb89b3b-4c40-4932-b798-641fbf2892a7 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-11-29_06:,, signatures=0 Received: from [17.234.36.246] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q1Q00GDCTJOUC40@nwk-mmpp-sz10.apple.com>; Fri, 29 Nov 2019 10:19:01 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Message-id: <4DC9ED82-111A-4157-B3B1-CCFDDD23CC01@apple.com> Content-type: multipart/alternative; boundary="Apple-Mail=_DAEE3A6C-A3F6-4A51-BA29-69ABF6D4BA0B" MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Date: Fri, 29 Nov 2019 10:18:51 -0800 In-reply-to: <2C53815C-D874-4299-A6AF-F433D063D061@cable.comcast.com> Cc: Patrick McManus , "add@ietf.org" , Christian Huitema To: "Livingood, Jason" References: <2C53815C-D874-4299-A6AF-F433D063D061@cable.comcast.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-11-29_06:, , signatures=0 Archived-At: Subject: Re: [Add] Not looking at DNS privacy in isolation 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, 29 Nov 2019 18:19:14 -0000 --Apple-Mail=_DAEE3A6C-A3F6-4A51-BA29-69ABF6D4BA0B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 That's definitely true! A local network is only one of the many places = along a path that can perform surveillance, etc. To Patrick's point, however, any entity that has a special relationship = with the client, either by knowing more identity information or seeing a = broader scope of traffic, can perform such a role more effectively. That = can be a local network, a VPN resolver, or even a public resolver that = can strongly correlate a connection from a client with a connection that = has signed into some account, etc. Once the contents of queries and SNI values are encrypted, the number of = entities along a path that can easily correlate cleartext names with = client identifiers is reduced. Someone can look at the traffic that is = generated by a recursive resolver, but that is generally a large enough = anonymity set to be less useful for surveillance. Best, Tommy > On Nov 29, 2019, at 5:56 AM, Livingood, Jason = wrote: >=20 > I=E2=80=99m not arguing that the local network not be considered a = potential threat. Rather, that any network along the E2E path be = considered a potential threat since the last hop network is not the only = one able to surveil/block/modify DNS traffic.=20 > =20 > JL > =20 > From: Patrick McManus > > Date: Tuesday, November 26, 2019 at 2:02 PM > To: "Livingood, Jason" > > Cc: Christian Huitema >, "add@ietf.org " = > > Subject: [EXTERNAL] Re: [Add] Not looking at DNS privacy in isolation > =20 > otoh the local network is probably responsible for the IP assignment = and, especially when known to the end user, is capable of mapping that = directly to real-life identity and other bits of profile linked to that = identity. This gives them a somewhat unique threat attribute to be = considered.=20 > =20 > -P > =20 > =20 > On Tue, Nov 26, 2019 at 11:45 AM Livingood, Jason = > = wrote: >> On 11/24/19, 9:03 PM, "Add on behalf of Christian Huitema" = on behalf = ofhuitema@huitema.net > wrote: >> > We can consider three actors: the local network provider, the = DNS >> resolver, and the web hoster.and that the Each of them will = receive some >> information about the transaction: >>=20 >> > * The local network will see the IP addresses of server and client, = and >> the name of the fronting server in the "public" SNI. (The same >> information is available to all on path observers.) >>=20 >> [JL] As you note parenthetically this is true of any network along = the end to end path between the client and the server. =46rom a threat = assessment standpoint those non-local network providers may be a greater = risk (bumps in the wire), particularly as they are likely unknown to end = users (such as transit networks or submarine link providers). So I would = recommend you not focus on just a local network but more broadly to any = network on the E2E path. >>=20 >>=20 >> --=20 >> Add mailing list >> Add@ietf.org >> https://www.ietf.org/mailman/listinfo/add = --=20 > Add mailing list > Add@ietf.org > https://www.ietf.org/mailman/listinfo/add = --Apple-Mail=_DAEE3A6C-A3F6-4A51-BA29-69ABF6D4BA0B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 That's definitely true! A local network is only one of the = many places along a path that can perform surveillance, etc.

To Patrick's point, = however, any entity that has a special relationship with the client, = either by knowing more identity information or seeing a broader scope of = traffic, can perform such a role more effectively. That can be a local = network, a VPN resolver, or even a public resolver that can strongly = correlate a connection from a client with a connection that has signed = into some account, etc.

Once the contents of queries and SNI values are encrypted, = the number of entities along a path that can easily correlate cleartext = names with client identifiers is reduced. Someone can look at the = traffic that is generated by a recursive resolver, but that is generally = a large enough anonymity set to be less useful for = surveillance.

Best,
Tommy

On Nov = 29, 2019, at 5:56 AM, Livingood, Jason <Jason_Livingood@comcast.com> wrote:

I=E2=80=99m not arguing that the = local network not be considered a potential threat. Rather, that any = network along the E2E path be considered a potential threat since the = last hop network is not the only one able to surveil/block/modify DNS = traffic. 
 
JL
 
From: Patrick McManus <mcmanus@ducksong.com>
Date: Tuesday, November 26, = 2019 at 2:02 PM
To: "Livingood, Jason" = <Jason_Livingood@cable.comcast.com>
Cc: Christian Huitema = <huitema@huitema.net>, "add@ietf.org" <add@ietf.org>
Subject: [EXTERNAL] Re: [Add] = Not looking at DNS privacy in isolation
 
otoh the local network is probably = responsible for the IP assignment and, especially when known to the end = user, is capable of mapping that directly to real-life identity and = other bits of profile linked to that identity. This gives them a = somewhat unique threat attribute to be considered. 
 
-P
 
 
On Tue, Nov 26, 2019 at = 11:45 AM Livingood, Jason <Jason_Livingood@comcast.com> wrote:

On = 11/24/19, 9:03 PM, "Add on behalf of Christian Huitema" <add-bounces@ietf.org on behalf ofhuitema@huitema.net> wrote:
>  =   We can consider three actors: the local network provider, the = DNS
    resolver, and the web hoster.and that = the Each of them will receive some
    = information about the transaction:

> * = The local network will see the IP addresses of server and client, and
    the name of the fronting server in the "public" = SNI. (The same
    information is available to = all on path observers.)

[JL] As you note = parenthetically this is true of any network along the end to end path = between the client and the server. =46rom a threat assessment standpoint = those non-local network providers may be a greater risk (bumps in the = wire), particularly as they are likely unknown to end users (such as = transit networks or submarine link providers). So I would recommend you = not focus on just a local network but more broadly to any network on the = E2E path.


-- 
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

= --Apple-Mail=_DAEE3A6C-A3F6-4A51-BA29-69ABF6D4BA0B--