From nobody Mon Jul 2 01:33:15 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 063AB130E41 for ; Mon, 2 Jul 2018 01:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=h3oIZDiS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=fj2eVnKs Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhGyn7OvI3fq for ; Mon, 2 Jul 2018 01:33:10 -0700 (PDT) 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 65CDD130E4B for ; Mon, 2 Jul 2018 01:33:10 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id C002821B62 for ; Mon, 2 Jul 2018 04:33:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 02 Jul 2018 04:33:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Oisji/ iHoA9WAr6eqPPVXreSkLTUTvcG6vC2p6E805c=; b=h3oIZDiStu8UaCRd13f1ke MbOwpGHCMrECRTJfzlj2yUPD0Z+eiI9y1Wd0lzLV1UCNCnuRlAVe67tKfZPKmx23 cW6G7pAzu4CpPuZsOuGqUka6LBGePwr6hf7Z2zTKvSI04t5kvZekDwcBgzSihlte CwSdeN8PZVhcXGfwIRo2v/mXycwuuJ61+7kamdGgCYQ4uyJdCISMQ37iapk7Xqqc fiSRdw02oLujuCEChojyBi89WkCHD7yIOMKwM52EGHBrE67Wb+NZRgkFD43m8ENv +HUkI7N9p/E88o3Hi47iNa8ZBu4HzPDwj0w3VaChynYBbCSnnQvbYAEorSo2Z9iw == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Oisji/iHoA9WAr6eqPPVXreSkLTUTvcG6vC2p6E80 5c=; b=fj2eVnKsc7sJDzRR3/3vMgYd0UOQjg7xEOtUrxulp8+pxK8xVTYoLOWP3 bczMxqlRwop5YZneQ+aMyBtQGPY7TWnSqA77QZhzmCj/tz68TqcZ1iuXNzJvWtnQ TaxH7ReIcFnvZ7NvexB+MlbKaM3jHTOA3qDAl2jRx8jU4bI6lR0t8euw+sWoCN1h 3zCYoWjVHLnD9JSsSiT27kQuADyg/saBo8XKp5NzPUsx73RkLEdbjy/AApXggIXX Fb5CHRw1l+ji00Q7fyz0lEerCzSxXqjoi68OwwFAB9mVpziah56daZjX9/0gd5Cq hXz1tGdSlPgR5zAppIViEKiWvyVNQ== X-ME-Proxy: X-ME-Sender: Received: from attitudadjuster.localdomain (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 5A13CE405A for ; Mon, 2 Jul 2018 04:33:08 -0400 (EDT) From: Mark Nottingham Content-Type: multipart/alternative; boundary="Apple-Mail=_6E873C70-6A95-464C-95E0-1AB5556FE509" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: References: <153052025806.28235.18289214974586034235.idtracker@ietfa.amsl.com> To: driu@ietf.org Date: Mon, 2 Jul 2018 18:33:05 +1000 X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Driu] Fwd: New Version Notification for draft-nottingham-doh-digests-00.txt X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Jul 2018 08:33:14 -0000 --Apple-Mail=_6E873C70-6A95-464C-95E0-1AB5556FE509 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi DRIU, I wrote some thoughts down; please treat them as very preliminary. Cheers, > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-nottingham-doh-digests-00.txt > Date: 2 July 2018 at 6:30:58 pm AEST > To: "Mark Nottingham" >=20 >=20 > A new version of I-D, draft-nottingham-doh-digests-00.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. >=20 > Name: draft-nottingham-doh-digests > Revision: 00 > Title: DOH Digests > Document date: 2018-07-02 > Group: Individual Submission > Pages: 6 > URL: = https://www.ietf.org/internet-drafts/draft-nottingham-doh-digests-00.txt > Status: = https://datatracker.ietf.org/doc/draft-nottingham-doh-digests/ > Htmlized: = https://tools.ietf.org/html/draft-nottingham-doh-digests-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-nottingham-doh-digests >=20 >=20 > Abstract: > The lack of flexible configuration and selection mechanisms for DOH > servers is identified as suboptimal for privacy and performance in > some applications. >=20 > This document makes a straw-man proposal for an improvement. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_6E873C70-6A95-464C-95E0-1AB5556FE509 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = DRIU,

I wrote some = thoughts down; please treat them as very preliminary.

Cheers,



Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-nottingham-doh-digests-00.txt
Date: = 2 July 2018 at 6:30:58 pm = AEST
To: = "Mark Nottingham" <mnot@mnot.net>

A new version of I-D, draft-nottingham-doh-digests-00.txt
has been successfully submitted by Mark Nottingham and posted = to the
IETF repository.

Name: = = draft-nottingham-doh-digests
Revision: 00
Title:= = DOH Digests
Document date: = 2018-07-02
Group: Individual Submission
Pages:= = 6
URL: =            https://www.ietf.org/internet-drafts/draft-nottingham-doh-diges= ts-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-nottingham-doh-digests/<= /a>
Htmlized:       https://tools.ietf.org/html/draft-nottingham-doh-digests-00=
Htmlized:       https://datatracker.ietf.org/doc/html/draft-nottingham-doh-dige= sts


Abstract:
  The lack of flexible configuration and selection = mechanisms for DOH
  servers is identified as = suboptimal for privacy and performance in
=   some applications.

=   This document makes a straw-man proposal for an = improvement.




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


--
Mark Nottingham  =  https://www.mnot.net/

= --Apple-Mail=_6E873C70-6A95-464C-95E0-1AB5556FE509-- From nobody Mon Jul 2 18:09:15 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CC12131481 for ; Mon, 2 Jul 2018 18:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 9ch9_hfZkM1s for ; Mon, 2 Jul 2018 18:09:00 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD9D6131208 for ; Mon, 2 Jul 2018 18:08:59 -0700 (PDT) Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 854D4279 for ; Mon, 2 Jul 2018 21:08:09 -0400 (EDT) From: Tom Pusateri Content-Type: multipart/alternative; boundary="Apple-Mail=_F63465EC-E83C-4B93-9069-00B7A992D8B4" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Message-Id: <8354E402-C699-46FB-AC95-99BA7AAF03A1@bangj.com> References: <153056107621.16040.1439553172883571734.idtracker@ietfa.amsl.com> To: driu@ietf.org Date: Mon, 2 Jul 2018 21:08:58 -0400 X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 01:09:13 -0000 --Apple-Mail=_F63465EC-E83C-4B93-9069-00B7A992D8B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I renamed the DHCPv6 DNS Discovery draft and submitted it. There are no = other changes from the early version referenced on Github. Thanks, Tom > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-pusateri-dhc-dns-driu-00.txt > Date: July 2, 2018 at 3:51:16 PM EDT > To: "Willem Toorop" , "Tom Pusateri" = >=20 >=20 > A new version of I-D, draft-pusateri-dhc-dns-driu-00.txt > has been successfully submitted by Tom Pusateri and posted to the > IETF repository. >=20 > Name: draft-pusateri-dhc-dns-driu > Revision: 00 > Title: DHCPv6 Options for private DNS Discovery > Document date: 2018-07-02 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/internet-drafts/draft-pusateri-dhc-dns-driu-00.txt > Status: = https://datatracker.ietf.org/doc/draft-pusateri-dhc-dns-driu/ > Htmlized: = https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-pusateri-dhc-dns-driu >=20 >=20 > Abstract: > This draft provides a series of DHCPv6 options for a DHCPv6 client = to > request from a DHCPv6 server to aid in configuring DNS servers that > support private requests/responses. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_F63465EC-E83C-4B93-9069-00B7A992D8B4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = renamed the DHCPv6 DNS Discovery draft and submitted it. There are no = other changes from the early version referenced on Github.

Thanks,
Tom

Begin = forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-pusateri-dhc-dns-driu-00.txt
Date: = July 2, 2018 at 3:51:16 PM = EDT
To: = "Willem Toorop" <willem@nlnetlabs.nl>, "Tom Pusateri" <pusateri@bangj.com>


A new version = of I-D, draft-pusateri-dhc-dns-driu-00.txt
has been = successfully submitted by Tom Pusateri and posted to the
IETF repository.

Name: = draft-pusateri-dhc-dns-driu
Revision: 00
Title:= = DHCPv6 Options for private DNS Discovery
Document = date: = 2018-07-02
Group: Individual Submission
Pages:= = 12
URL: =            https://www.ietf.org/internet-drafts/draft-pusateri-dhc-dns-dri= u-00.txt
Status: =         https://datatracker.ietf.org/doc/draft-pusateri-dhc-dns-driu/
Htmlized:       https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00<= br class=3D"">Htmlized:       https://datatracker.ietf.org/doc/html/draft-pusateri-dhc-dns-dr= iu


Abstract:
  This draft provides a series of DHCPv6 options = for a DHCPv6 client to
  request from a DHCPv6 = server to aid in configuring DNS servers that
=   support private requests/responses.




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


= --Apple-Mail=_F63465EC-E83C-4B93-9069-00B7A992D8B4-- From nobody Tue Jul 3 09:09:33 2018 Return-Path: X-Original-To: driu@ietf.org Delivered-To: driu@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E0267130EDC; Tue, 3 Jul 2018 09:00:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: warren@kumari.net, driu@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.81.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <153063361891.4893.9424628126698461397.idtracker@ietfa.amsl.com> Date: Tue, 03 Jul 2018 09:00:18 -0700 Archived-At: X-Mailman-Approved-At: Tue, 03 Jul 2018 09:06:32 -0700 Subject: [Driu] driu - Requested session has been scheduled for IETF 102 X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.26 List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Jul 2018 16:00:31 -0000 Dear Liz Flynn, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. driu Session 1 (1:30 requested) Thursday, 19 July 2018, Afternoon Session II 1550-1750 Room Name: Viger size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/102/sessions/driu.ics Request Information: --------------------------------------------------------- Working Group Name: DNS Resolver Identification and Use Area Name: Operations and Management Area Session Requester: Liz Flynn Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: dnsop dprive doh rfcplusplus saag secdispatch People who must be present: Paul E. Hoffman Warren Kumari Resources Requested: Special Requests: rfcplusplus is also in the conflict list --------------------------------------------------------- From nobody Thu Jul 5 10:39:36 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA1CD130F14 for ; Thu, 5 Jul 2018 10:39:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 0f8mvx2Rr3Sa for ; Thu, 5 Jul 2018 10:39:32 -0700 (PDT) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 21EAE130F0D for ; Thu, 5 Jul 2018 10:39:31 -0700 (PDT) Received: by mail-lf0-x230.google.com with SMTP id i15-v6so7637375lfc.2 for ; Thu, 05 Jul 2018 10:39:31 -0700 (PDT) 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=FFhr3J674e9IisHIetBHa9CypuXbave0B4A5nEA1/Rg=; b=jJBCBHtcl2b9XsvXkaqEJVk5XsEmNEXm3iimQY87zeJM5Oj4DyipqkPrEWEOchV399 G30DMlPg9kJ22euo10i5b6jBMLi2M3UL9Feqt0eJD4kx52sdKjKlj5BfJMSK9iinQ1wr S2jkM1Wb41HRjxr6pwbKxj0xT6emvnN9x21IT9L9LzLKpPlgIMgYkpyur6xTOT49Lj3q Y2SaivBz/q7p1296twCak/nVBFePmvUgMXeQw8xsPH2fpGvqfOfCy+YVNMsq2H9FEhoK Jl4hbqbxz+430IMB/AdQxpinQNbq2ILffasxQwRmmEcTDZdnj5MLjkCFIPbVGwXmLWSz cDOQ== 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=FFhr3J674e9IisHIetBHa9CypuXbave0B4A5nEA1/Rg=; b=YXL7C3sqJrkiLiWHi1kvZXaBH1UzU5Vpqaun4llEOOxW7m05NhdTW89vhi0wqtWM3g ZsVIFq9O1rkznNN/Tqm2d8rY9tWp7+AbR2PZXI4teZhrN8L9QcMRwVr6GkZO+S4MKQ3g q6d6OdrsJGz/tdC9Y7YUiBuvUFNr0Zf/AuTKI9L3ZBf/TtyBu+WdRwUQKxTGgpgsKO3p NHccdJ8qGdGx6D5gZhvHsFxmvfN6x5XlA5StuPBqHLAZZZWOxFVXfiX23WmmlyTUeBDK XDPf26PvMzDy3200B4ujwhA84PSPmFORIeAw8XV0Dx9FfWnCSaGfm2lPb/NS5bMCKfJ4 6gAw== X-Gm-Message-State: APt69E1lQ0GO65WafZqolt8VWqzcgdf00Dq0njOG7NdEZ9d1VJATi0g3 tSTfj52wTpxJ0JbO573OtNsASO0xAPi6HEGCMgc05mNr X-Google-Smtp-Source: AAOMgpc/eJAhzB1lUkDLWS3bNftX5/ohBEd3d913FOWjV4KQ8S/84JTe3uc3gsnw/ED+iNuR7eq+iLs/jP3J1YRtzyg= X-Received: by 2002:a19:b2c7:: with SMTP id t68-v6mr4884216lfk.132.1530812370207; Thu, 05 Jul 2018 10:39:30 -0700 (PDT) MIME-Version: 1.0 References: <153056107621.16040.1439553172883571734.idtracker@ietfa.amsl.com> <8354E402-C699-46FB-AC95-99BA7AAF03A1@bangj.com> In-Reply-To: <8354E402-C699-46FB-AC95-99BA7AAF03A1@bangj.com> From: Bob Harold Date: Thu, 5 Jul 2018 13:39:18 -0400 Message-ID: To: pusateri@bangj.com Cc: driu@ietf.org Content-Type: multipart/alternative; boundary="0000000000008b5dac0570440747" Archived-At: Subject: Re: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 17:39:36 -0000 --0000000000008b5dac0570440747 Content-Type: text/plain; charset="UTF-8" On Mon, Jul 2, 2018 at 9:09 PM Tom Pusateri wrote: > I renamed the DHCPv6 DNS Discovery draft and submitted it. There are no > other changes from the early version referenced on Github. > > Thanks, > Tom > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for > draft-pusateri-dhc-dns-driu-00.txt* > *Date: *July 2, 2018 at 3:51:16 PM EDT > *To: *"Willem Toorop" , "Tom Pusateri" < > pusateri@bangj.com> > > > A new version of I-D, draft-pusateri-dhc-dns-driu-00.txt > has been successfully submitted by Tom Pusateri and posted to the > IETF repository. > > Name: draft-pusateri-dhc-dns-driu > Revision: 00 > Title: DHCPv6 Options for private DNS Discovery > Document date: 2018-07-02 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-pusateri-dhc-dns-driu-00.txt > Status: > https://datatracker.ietf.org/doc/draft-pusateri-dhc-dns-driu/ > Htmlized: https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-pusateri-dhc-dns-driu > > > Abstract: > This draft provides a series of DHCPv6 options for a DHCPv6 client to > request from a DHCPv6 server to aid in configuring DNS servers that > support private requests/responses. > > ... > DRIU mailing list > DRIU@ietf.org > https://www.ietf.org/mailman/listinfo/driu ------- I have concern: 3. DHCPv6 Encapsulating Options "There is no order implied by the order of options sent or received. It is up to the receiving client to determine which order to use the DNS server configurations." Let's not wait for some non-standard way to decide the order. Please add 'priority' (and possibly 'weight') fields to the "OPTION_DNS_TLS" now, like in MX and SRV records. ------- And a question: Appendix A. ISC DHCPv6 Configuration Example "option tls.adn code 228 = domain-list; option tls.adn "dns.quad9.net";" Why is this defined as a list, but only a single domain is configured. And the text (in 1. Introduction) indicates only one domain is allowed per option. Is there a single domain format that should be used? -- Bob Harold --0000000000008b5dac0570440747 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Mon, Ju= l 2, 2018 at 9:09 PM Tom Pusateri <pusateri@bangj.com> wrote:
=
I renamed = the DHCPv6 DNS Discovery draft and submitted it. There are no other changes= from the early version referenced on Github.

Thanks,
Tom

Begin forwarded= message:

Subject: <= /b>New Version Notification for draft-pusateri-dhc-dns-d= riu-00.txt
Date= : July 2, 2018 at 3:51:16 PM EDT
= To: "Willem Toor= op" <wille= m@nlnetlabs.nl>, "Tom Pusateri" <pusateri@bangj.com>


A new version of I-D, draft-pusateri-dhc-dns-driu-00.tx= t
has been successfully submitted by Tom Pusateri and posted to the
I= ETF repository.

Name: draft-pusater= i-dhc-dns-driu
Revision: 00
Title: DHCPv6 Options for private DNS Discovery
Document date: 2018-07-02
Group: Indivi= dual Submission
Pages: 12
URL: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://www.ietf.org/internet-drafts/draft-pusateri-dhc-dns-= driu-00.txt
Status: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= https://datatracker.ietf.org/doc/draft-pusateri-dhc-dns-dr= iu/
Htmlized: =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0http= s://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00
Htmlized: =C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0https://datatracker.i= etf.org/doc/html/draft-pusateri-dhc-dns-driu


Abstract:
= =C2=A0=C2=A0This draft provides a series of DHCPv6 options for a DHCPv6 cli= ent to
=C2=A0=C2=A0request from a DHCPv6 server to aid in configuring D= NS servers that
=C2=A0=C2=A0support private requests/responses.
...=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> DRIU mailing list
DRIU@ietf.org
https://www.ietf.org/mailman/listinfo/driu

-------
I have concern:

=
3. DHCPv6 Encapsulating Options

"There is no order
= implied by the order of options sent or received. It is up to the
re= ceiving client to determine which order to use the DNS server
configu= rations."

Let's not wait for some non-standard way to decid= e the order. Please add 'priority' (and possibly 'weight')= fields to the "OPTION_DNS_TLS" now, like in MX and SRV records.<= br>
-------
And a question:

--0000000000008b5dac0570440747-- From nobody Thu Jul 5 11:02:22 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4B6130F04 for ; Thu, 5 Jul 2018 11:02:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 sYkNYILJ3Xce for ; Thu, 5 Jul 2018 11:02:18 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C4B130EE8 for ; Thu, 5 Jul 2018 11:02:17 -0700 (PDT) Received: from butte-480.mountain2sea.com (69-77-155-155.static.skybest.com [69.77.155.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 2039E646; Thu, 5 Jul 2018 14:01:17 -0400 (EDT) From: Tom Pusateri Message-Id: <0AF05538-82F2-4F7E-892B-98E211CA596F@bangj.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_F1620B92-181C-4B78-AB20-DAE701CBC638" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 5 Jul 2018 14:02:15 -0400 In-Reply-To: Cc: driu@ietf.org To: Bob Harold References: <153056107621.16040.1439553172883571734.idtracker@ietfa.amsl.com> <8354E402-C699-46FB-AC95-99BA7AAF03A1@bangj.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 18:02:20 -0000 --Apple-Mail=_F1620B92-181C-4B78-AB20-DAE701CBC638 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 5, 2018, at 1:39 PM, Bob Harold wrote: >=20 > I have concern: >=20 > 3. DHCPv6 Encapsulating Options >=20 > "There is no order > implied by the order of options sent or received. It is up to the > receiving client to determine which order to use the DNS server > configurations." >=20 > Let's not wait for some non-standard way to decide the order. Please = add 'priority' (and possibly 'weight') fields to the "OPTION_DNS_TLS" = now, like in MX and SRV records. >=20 Willem has said that from experience with Stubby, that the client should = determine the order it uses the discovered DNS servers. The network = operator advertising the list doesn=E2=80=99t necessarily have real time = data to determine response times, delays, etc. I=E2=80=99m happy to = discuss this more. Why should the network operator dictate this? > ------- > And a question: >=20 > Appendix A. ISC DHCPv6 Configuration Example >=20 > "option tls.adn code 228 =3D domain-list; >=20 > option tls.adn "dns.quad9.net ";" >=20 > Why is this defined as a list, but only a single domain is configured. = And the text (in 1. Introduction) indicates only one domain is allowed = per option. Is there a single domain format that should be used? Yeah, this is a bug in the ISC config file. I will fix the example. Thanks, Tom --Apple-Mail=_F1620B92-181C-4B78-AB20-DAE701CBC638 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 5, 2018, at 1:39 PM, Bob Harold <rharolde@umich.edu> = wrote:

I have concern:

3. DHCPv6 Encapsulating Options

"There is no order
implied by the order of = options sent or received. It is up to the
receiving client = to determine which order to use the DNS server
configurations."

Let's not wait = for some non-standard way to decide the order. Please add 'priority' = (and possibly 'weight') fields to the "OPTION_DNS_TLS" now, like in MX = and SRV records.


Willem has = said that from experience with Stubby, that the client should determine = the order it uses the discovered DNS servers. The network operator = advertising the list doesn=E2=80=99t necessarily have real time data to = determine response times, delays, etc. I=E2=80=99m happy to discuss this = more. Why should the network operator dictate this?

-------
And a question:

Appendix A. ISC DHCPv6 Configuration Example

"option tls.adn code 228 =3D domain-list;

option tls.adn "dns.quad9.net";"

Why is this = defined as a list, but only a single domain is configured. And the text = (in 1. Introduction) indicates only one domain is allowed per option. Is = there a single domain format that should be used?

Yeah, this is a bug in the ISC config file. I will = fix the example.

Thanks,
Tom



= --Apple-Mail=_F1620B92-181C-4B78-AB20-DAE701CBC638-- From nobody Thu Jul 5 11:49:51 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41D15130F06 for ; Thu, 5 Jul 2018 11:49:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 nVu9bytNL0Cm for ; Thu, 5 Jul 2018 11:49:45 -0700 (PDT) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 A5607130F44 for ; Thu, 5 Jul 2018 11:49:45 -0700 (PDT) Received: by mail-lf0-x234.google.com with SMTP id y127-v6so7776203lfc.8 for ; Thu, 05 Jul 2018 11:49:45 -0700 (PDT) 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=NirSPtRhQ8basMKaRhSokExN3pkt4KaND9PuLNTZi0Y=; b=egR596ACE3lfPEYY4kX1lR5K8gEGTR5VU5rpHqAQOZvG5ha+m0L2g52b3iN6YTjJA4 F/PHdBY1qO2cvMSFjlCzXDYUjlyTpwdQNUrKmpz/KpI91uM7SSf4VtkCqbSuX1O2lKTr u1bzNBvnmMe+4GKXn6Aedx/UAgaYelGQViep/XWtPFNbTT+z0M9wdCVBiOUuV0oeuXD6 F1WvSs9cBhQp7kL4cVQOgPGI+pe9TqS1BmAm2TLKHVjbFWCXNfSEwJwH8LmxVHvr28aq 0t5gQHAIqPsD+AaC97BvZSwKBWxVxuyebaWYWV+N6ctLNnaz/y2+QNNQAz+8NfrK0ey5 NLIw== 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=NirSPtRhQ8basMKaRhSokExN3pkt4KaND9PuLNTZi0Y=; b=d3vJ5CjoQCuaaqr+pWoGDRNLSTk/tXg2YARYR0UV3e2T9hvHJtF09bArROdBKvG58Y ox9MOwJAqUYX7cXvNm4jnhUwyIeTRc5s8GIQ0LbZB9Ac/0RGiodzWu6u6E+p91Eq9QdV tBrypNmIeaaB+kM61tOw/ExCyS4lEv/5+Wsj+cy9TxqdQN8x0Xx6wq6NFtdzeAiHNWTW gcq95QuG5laP9kcN6S2KeEWEvN7amWTPzMP8VAxNIr9zBxWZONX07n9zh3K1KI/yd/2o +k4zISrGWDo0FKMLoMk/88a8kaOhlD54ZllBdney82zLH/4Id48VOPtS1PrHXP7lF+pX vT0g== X-Gm-Message-State: APt69E0j1h6ZQCpr8vnoyc1dEHyWgCQjmKtrZ0S6AGC4JpI2FYIO2SK7 4C4p2yGGnjXKINyJTLZGfYVjb4GhVyMjK91gGFvZKw== X-Google-Smtp-Source: AAOMgpfURi5DLduf/cDs8D3hYK+89Zwrio480h4LDRxIitFeyFUg0/19It0biSkB8UDXBNHWZ94o0YTzWguMliK6GUw= X-Received: by 2002:a19:b2c7:: with SMTP id t68-v6mr5015988lfk.132.1530816583676; Thu, 05 Jul 2018 11:49:43 -0700 (PDT) MIME-Version: 1.0 References: <153056107621.16040.1439553172883571734.idtracker@ietfa.amsl.com> <8354E402-C699-46FB-AC95-99BA7AAF03A1@bangj.com> <0AF05538-82F2-4F7E-892B-98E211CA596F@bangj.com> In-Reply-To: <0AF05538-82F2-4F7E-892B-98E211CA596F@bangj.com> From: Bob Harold Date: Thu, 5 Jul 2018 14:49:31 -0400 Message-ID: To: pusateri@bangj.com Cc: driu@ietf.org Content-Type: multipart/alternative; boundary="000000000000afc9b00570450240" Archived-At: Subject: Re: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 18:49:50 -0000 --000000000000afc9b00570450240 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 5, 2018 at 2:02 PM Tom Pusateri wrote: > > > On Jul 5, 2018, at 1:39 PM, Bob Harold wrote: > > I have concern: > > 3. DHCPv6 Encapsulating Options > > "There is no order > implied by the order of options sent or received. It is up to the > receiving client to determine which order to use the DNS server > configurations." > > Let's not wait for some non-standard way to decide the order. Please add > 'priority' (and possibly 'weight') fields to the "OPTION_DNS_TLS" now, li= ke > in MX and SRV records. > > > Willem has said that from experience with Stubby, that the client should > determine the order it uses the discovered DNS servers. The network > operator advertising the list doesn=E2=80=99t necessarily have real time = data to > determine response times, delays, etc. I=E2=80=99m happy to discuss this = more. Why > should the network operator dictate this? > > I would think that the network operator, who can set the option per subnet, would have a better idea where the subnet is, than a client machine that roams from place to place and usually does not know where it is located. If the operator lists more than one server, there is likely to be a need to designate primary vs backup in some cases. If the client knows better, it can certainly have its own list, and ignore or append what the network recommends. But the network knows better what will be faster or even reachable from a given subnet, in my opinion. (I run the DHCP servers at my location, so I am probably biased.) --=20 Bob Harold > ------- > And a question: > > Appendix A. ISC DHCPv6 Configuration Example > > "option tls.adn code 228 =3D domain-list; > > option tls.adn "dns.quad9.net";" > > Why is this defined as a list, but only a single domain is configured. An= d > the text (in 1. Introduction) indicates only one domain is allowed per > option. Is there a single domain format that should be used? > > > Yeah, this is a bug in the ISC config file. I will fix the example. > > Thanks, > Tom > > --000000000000afc9b00570450240 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Ju= l 5, 2018 at 2:02 PM Tom Pusateri <pusateri@bangj.com> wrote:
=

<= br>
On Jul 5, 2018, at 1:39 PM, Bob Harold &l= t;rharolde@umich.ed= u> wrote:

I have concern:

3. DHCPv6 Encapsulating O= ptions

"There is no order
implied by the order of options se= nt or received. It is up to the
receiving client to determine which orde= r to use the DNS server
configurations."

Let's not wait = for some non-standard way to decide the order. Please add 'priority'= ; (and possibly 'weight') fields to the "OPTION_DNS_TLS" = now, like in MX and SRV records.


<= /div>Willem has said that from experience with Stubby, that the client shou= ld determine the order it uses the discovered DNS servers. The network oper= ator advertising the list doesn=E2=80=99t necessarily have real time data t= o determine response times, delays, etc. I=E2=80=99m happy to discuss this = more. Why should the network operator dictate this?

I would think that the network operator, who can set t= he option per subnet, would have a better idea where the subnet is, than a = client machine that roams from place to place and usually does not know whe= re it is located.=C2=A0 If the operator lists more than one server, there i= s likely to be a need to designate primary vs backup in some cases.=C2=A0 I= f the client knows better, it can certainly have its own list, and ignore o= r append what the network recommends.=C2=A0 But the network knows better wh= at will be faster or even reachable from a given subnet, in my opinion.=C2= =A0 (I run the DHCP servers at my location, so I am probably biased.)
=

--=C2=A0
Bob Harold
=C2=A0
-------
And a question:

Appendix A. = ISC DHCPv6 Configuration Example

"option tls.adn code 228 =3D d= omain-list;

option tls.adn "dns.quad9.net";"

Why is this defined = as a list, but only a single domain is configured. And the text (in 1. Intr= oduction) indicates only one domain is allowed per option. Is there a singl= e domain format that should be used?

Yeah,= this is a bug in the ISC config file. I will fix the example.
Thanks,
Tom

<= /div>
--000000000000afc9b00570450240-- From nobody Thu Jul 5 12:31:54 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC4CE130E01 for ; Thu, 5 Jul 2018 12:31:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 ZWmaNupHdoUV for ; Thu, 5 Jul 2018 12:31:50 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA0201294D0 for ; Thu, 5 Jul 2018 12:31:49 -0700 (PDT) Received: from butte-480.attlocal.net (104-176-180-232.lightspeed.chrlnc.sbcglobal.net [104.176.180.232]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 35D5765E; Thu, 5 Jul 2018 15:30:48 -0400 (EDT) From: Tom Pusateri Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_F20E4ABC-B58A-4C29-A699-A3C951F7886E" Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Date: Thu, 5 Jul 2018 15:31:45 -0400 In-Reply-To: Cc: driu@ietf.org To: Bob Harold References: <153056107621.16040.1439553172883571734.idtracker@ietfa.amsl.com> <8354E402-C699-46FB-AC95-99BA7AAF03A1@bangj.com> <0AF05538-82F2-4F7E-892B-98E211CA596F@bangj.com> X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 19:31:52 -0000 --Apple-Mail=_F20E4ABC-B58A-4C29-A699-A3C951F7886E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jul 5, 2018, at 2:49 PM, Bob Harold wrote: >=20 >=20 > On Thu, Jul 5, 2018 at 2:02 PM Tom Pusateri > wrote: >=20 >=20 >> On Jul 5, 2018, at 1:39 PM, Bob Harold > wrote: >>=20 >> I have concern: >>=20 >> 3. DHCPv6 Encapsulating Options >>=20 >> "There is no order >> implied by the order of options sent or received. It is up to the >> receiving client to determine which order to use the DNS server >> configurations." >>=20 >> Let's not wait for some non-standard way to decide the order. Please = add 'priority' (and possibly 'weight') fields to the "OPTION_DNS_TLS" = now, like in MX and SRV records. >>=20 >=20 > Willem has said that from experience with Stubby, that the client = should determine the order it uses the discovered DNS servers. The = network operator advertising the list doesn=E2=80=99t necessarily have = real time data to determine response times, delays, etc. I=E2=80=99m = happy to discuss this more. Why should the network operator dictate = this? >=20 > I would think that the network operator, who can set the option per = subnet, would have a better idea where the subnet is, than a client = machine that roams from place to place and usually does not know where = it is located. If the operator lists more than one server, there is = likely to be a need to designate primary vs backup in some cases. If = the client knows better, it can certainly have its own list, and ignore = or append what the network recommends. But the network knows better = what will be faster or even reachable from a given subnet, in my = opinion. (I run the DHCP servers at my location, so I am probably = biased.) Since the option is probably only refreshed once per day on average, the = list is fairly static. Assuming that an on subnet server will respond = faster than a server several hops away is a bad assumption. It depends = on many factors and these will change constantly depending on the number = of clients, the number of TLS connections the server can manage, number = of switches and congestion at the network level including APs, etc. = Since these conditions change at the sub-second level, having the client = figure out which server responds best seems more flexible. If all the servers in the list should respond, does the network operator = care which one is used? Once you get past the access point, is there = typically congestion in the wired network you=E2=80=99re trying to = avoid? I=E2=80=99ll put this on my slides to discuss in Montr=C3=A9al. Thanks, Tom =20 --Apple-Mail=_F20E4ABC-B58A-4C29-A699-A3C951F7886E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jul 5, 2018, at 2:49 PM, Bob Harold <rharolde@umich.edu> = wrote:


On Thu, Jul 5, 2018 = at 2:02 PM Tom Pusateri <pusateri@bangj.com> wrote:


On Jul 5, 2018, at 1:39 PM, Bob = Harold <rharolde@umich.edu> wrote:

I have concern:

3. DHCPv6 Encapsulating Options

"There is no order
implied by = the order of options sent or received. It is up to the
receiving client to determine which order to use the DNS = server
configurations."

Let's = not wait for some non-standard way to decide the order. Please add = 'priority' (and possibly 'weight') fields to the "OPTION_DNS_TLS" now, = like in MX and SRV records.


Willem has said that from experience with Stubby, that = the client should determine the order it uses the discovered DNS = servers. The network operator advertising the list doesn=E2=80=99t = necessarily have real time data to determine response times, delays, = etc. I=E2=80=99m happy to discuss this more. Why should the network = operator dictate this?

I would think that = the network operator, who can set the option per subnet, would have a = better idea where the subnet is, than a client machine that roams from = place to place and usually does not know where it is located.  If = the operator lists more than one server, there is likely to be a need to = designate primary vs backup in some cases.  If the client knows = better, it can certainly have its own list, and ignore or append what = the network recommends.  But the network knows better what will be = faster or even reachable from a given subnet, in my opinion.  (I = run the DHCP servers at my location, so I am probably = biased.)

Since the option is probably only refreshed once = per day on average, the list is fairly static. Assuming that an on = subnet server will respond faster than a server several hops away is a = bad assumption. It depends on many factors and these will change = constantly depending on the number of clients, the number of TLS = connections the server can manage, number of switches and congestion at = the network level including APs, etc. Since these conditions change at = the sub-second level, having the client figure out which server responds = best seems more flexible.

If all the = servers in the list should respond, does the network operator care which = one is used? Once you get past the access point, is there typically = congestion in the wired network you=E2=80=99re trying to = avoid?

I=E2=80=99ll put this on my = slides to discuss in Montr=C3=A9al.

Thanks,
Tom

 

= --Apple-Mail=_F20E4ABC-B58A-4C29-A699-A3C951F7886E-- From nobody Thu Jul 5 12:57:37 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 968E8130F6D for ; Thu, 5 Jul 2018 12:57:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 OZ5qKwH5760A for ; Thu, 5 Jul 2018 12:57:32 -0700 (PDT) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (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 6B091130EA8 for ; Thu, 5 Jul 2018 12:57:32 -0700 (PDT) Received: by mail-lf0-x243.google.com with SMTP id n96-v6so7940181lfi.1 for ; Thu, 05 Jul 2018 12:57:32 -0700 (PDT) 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=UayZ6ULY3Q0aWFyAKp32dsm9EWPZCDhs0q4e7gbCb+M=; b=JHTgtOHo9yBzoQ0KS6qaS8PVm+yXNHtS9zEtqiE1pqB5PHaHW655iPxTho5/gjpWFV vew+SU71bVGcSeMUGY55wz2WybOXpZtsPylGtpduFA/ZUtEsuGa9rZACga1DYrg3hNRW RmKCP8HuoqyzX9KB4zWOMwMBb3sAJlhUaDokMuNe2ayTrkOFjsNBnbobhJGhTCTWuPgs 0oj6AacMGUQbQu+z3w+JDDP7STo6uGpo7bJqqXL83/vvs8wsNmO08r//omwFlV8uHIVh lQvkSuQdNDP4walI1EnTE2F1T1MQLG3pcp5qIGvT9CdnzCTRPZZQWKhnKBFR7FgMSJ2O cdTw== 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=UayZ6ULY3Q0aWFyAKp32dsm9EWPZCDhs0q4e7gbCb+M=; b=sXjlucbH8lYOmL1/FSIMsAXbfte2T6Z8QvYb65gOX+pgZ6shszod2Ksxic5w8ag4O+ iSahPtjyzJzFNzNU9Oh1A9Lmxi0M0D8pOSwaGvS4gC/WdB17B/FIbDSqJAsfw8DlRVBd JfPFwxgYN/IWjDCvJuqoxf2MSqDMH+HyV1b9wVBpgktIQkuGbhXdgugyTZfoPapP1PFy /IcrY4aEKbVVuPtI8+db2hx8W1KuPqwAuCR8w20Ck/xKN6VKfM5DbNM2NY3SjceRYD6F jNppH+tlxjMCaZxHBnIHJHopyqdjBk8CK+P3aU4FJe8MTXR23ZHdTxXzC7Lpa19PIXVf PPDw== X-Gm-Message-State: APt69E18hy8OST7AC5smVL28AnQgOa1pwnpDxiMkasZm2+jviwerupCl XfdDHWdoxQqgsrziTPN9+Ofx/YdV0gi6Qn6YmHaKcw== X-Google-Smtp-Source: AAOMgpdR1vo33s5srvCxGgs/ZM7zRBLiXwrfjJgLx4+uzGOf4v1oeNW3xNO5ToeNhSsAIGEykcICUQDUHz29cxOR5UM= X-Received: by 2002:a19:4344:: with SMTP id m4-v6mr5635511lfj.111.1530820650562; Thu, 05 Jul 2018 12:57:30 -0700 (PDT) MIME-Version: 1.0 References: <153056107621.16040.1439553172883571734.idtracker@ietfa.amsl.com> <8354E402-C699-46FB-AC95-99BA7AAF03A1@bangj.com> <0AF05538-82F2-4F7E-892B-98E211CA596F@bangj.com> In-Reply-To: From: Bob Harold Date: Thu, 5 Jul 2018 15:57:19 -0400 Message-ID: To: pusateri@bangj.com Cc: driu@ietf.org Content-Type: multipart/alternative; boundary="000000000000178713057045f53d" Archived-At: Subject: Re: [Driu] Fwd: New Version Notification for draft-pusateri-dhc-dns-driu-00.txt X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 19:57:36 -0000 --000000000000178713057045f53d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jul 5, 2018 at 3:31 PM Tom Pusateri wrote: > > > On Jul 5, 2018, at 2:49 PM, Bob Harold wrote: > > > On Thu, Jul 5, 2018 at 2:02 PM Tom Pusateri wrote: > >> >> >> On Jul 5, 2018, at 1:39 PM, Bob Harold wrote: >> >> I have concern: >> >> 3. DHCPv6 Encapsulating Options >> >> "There is no order >> implied by the order of options sent or received. It is up to the >> receiving client to determine which order to use the DNS server >> configurations." >> >> Let's not wait for some non-standard way to decide the order. Please add >> 'priority' (and possibly 'weight') fields to the "OPTION_DNS_TLS" now, l= ike >> in MX and SRV records. >> >> >> Willem has said that from experience with Stubby, that the client should >> determine the order it uses the discovered DNS servers. The network >> operator advertising the list doesn=E2=80=99t necessarily have real time= data to >> determine response times, delays, etc. I=E2=80=99m happy to discuss this= more. Why >> should the network operator dictate this? >> >> I would think that the network operator, who can set the option per > subnet, would have a better idea where the subnet is, than a client machi= ne > that roams from place to place and usually does not know where it is > located. If the operator lists more than one server, there is likely to = be > a need to designate primary vs backup in some cases. If the client knows > better, it can certainly have its own list, and ignore or append what the > network recommends. But the network knows better what will be faster or > even reachable from a given subnet, in my opinion. (I run the DHCP serve= rs > at my location, so I am probably biased.) > > > Since the option is probably only refreshed once per day on average, the > list is fairly static. Assuming that an on subnet server will respond > faster than a server several hops away is a bad assumption. It depends on > many factors and these will change constantly depending on the number of > clients, the number of TLS connections the server can manage, number of > switches and congestion at the network level including APs, etc. Since > these conditions change at the sub-second level, having the client figure > out which server responds best seems more flexible. > > If all the servers in the list should respond, does the network operator > care which one is used? Once you get past the access point, is there > typically congestion in the wired network you=E2=80=99re trying to avoid? > > I=E2=80=99ll put this on my slides to discuss in Montr=C3=A9al. > > Thanks, > Tom > > Thanks for the discussion. If the client tries them all from time to tim= e and picks the fastest, that is probably best. I was assuming that most clients would be fairly simple-minded and use the first one, and only try the next if the first failed. For simple clients, an order might be helpful. (Some IOT devices have very limited computing power.) I would be interested in what others think. Sorry I cannot attend Montreal= . --=20 Bob Harold --000000000000178713057045f53d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Thu, Ju= l 5, 2018 at 3:31 PM Tom Pusateri <pusateri@bangj.com> wrote:
=

<= br>
On Jul 5, 2018, at 2:49 PM, Bob Harold &l= t;rharolde@umich.ed= u> wrote:

<= div dir=3D"ltr">
On Thu, Jul 5, 2018 at 2:02 PM Tom Pusateri <pusateri@bangj.com> wrote:
=


On Jul 5, 2018, at 1:39 = PM, Bob Harold <= rharolde@umich.edu> wrote:

I have= concern:

3. DHCPv= 6 Encapsulating Options

"There is no order
implied by the or= der of options sent or received. It is up to the
receiving client to det= ermine which order to use the DNS server
configurations."

Le= t's not wait for some non-standard way to decide the order. Please add = 'priority' (and possibly 'weight') fields to the "OPTI= ON_DNS_TLS" now, like in MX and SRV records.


Willem has said that from experience with Stubby, tha= t the client should determine the order it uses the discovered DNS servers.= The network operator advertising the list doesn=E2=80=99t necessarily have= real time data to determine response times, delays, etc. I=E2=80=99m happy= to discuss this more. Why should the network operator dictate this?
<= div>
I would think that the network operat= or, who can set the option per subnet, would have a better idea where the s= ubnet is, than a client machine that roams from place to place and usually = does not know where it is located.=C2=A0 If the operator lists more than on= e server, there is likely to be a need to designate primary vs backup in so= me cases.=C2=A0 If the client knows better, it can certainly have its own l= ist, and ignore or append what the network recommends.=C2=A0 But the networ= k knows better what will be faster or even reachable from a given subnet, i= n my opinion.=C2=A0 (I run the DHCP servers at my location, so I am probabl= y biased.)

Since the opt= ion is probably only refreshed once per day on average, the list is fairly = static. Assuming that an on subnet server will respond faster than a server= several hops away is a bad assumption. It depends on many factors and thes= e will change constantly depending on the number of clients, the number of = TLS connections the server can manage, number of switches and congestion at= the network level including APs, etc. Since these conditions change at the= sub-second level, having the client figure out which server responds best = seems more flexible.

If all the servers in the lis= t should respond, does the network operator care which one is used? Once yo= u get past the access point, is there typically congestion in the wired net= work you=E2=80=99re trying to avoid?

I=E2=80=99ll = put this on my slides to discuss in Montr=C3=A9al.

Thanks,
Tom

Thanks f= or the discussion.=C2=A0 If the client tries them all from time to time and= picks the fastest, that is probably best.=C2=A0 I was assuming that most c= lients would be fairly simple-minded and use the first one, and only try th= e next if the first failed.=C2=A0 For simple clients, an order might be hel= pful.=C2=A0 (Some IOT devices have very limited computing power.)

I would be interested in what others think.=C2=A0 Sorry I c= annot attend Montreal.

--=C2=A0
Bob Haro= ld

--000000000000178713057045f53d-- From nobody Mon Jul 9 19:49:32 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C89F71310EA; Mon, 9 Jul 2018 19:49:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 KfgTZYcMkAzA; Mon, 9 Jul 2018 19:49:26 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id C47081310ED; Mon, 9 Jul 2018 19:49:26 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id 12C9D3A050; Mon, 9 Jul 2018 22:49:26 -0400 (EDT) Received: by mail-oi0-f52.google.com with SMTP id s198-v6so39781256oih.11; Mon, 09 Jul 2018 19:49:26 -0700 (PDT) X-Gm-Message-State: APt69E2PXvlg6nvwDBpXKzTjDwTSUXUG7RfATuebEoj3vkoeWPjTvBSj Oq0QBsXOLls+aPF0ebOh18/SGd1pPPeQv5zPViw= X-Google-Smtp-Source: AAOMgpffJRnEVtif8+cFsl4FKNUPJTA+LEwMl/QGr0LUV51oilorMcOyIo28iD/WwBekvMa9HXZF6rHRmAZdoRXM9qY= X-Received: by 2002:aca:e80c:: with SMTP id f12-v6mr27287137oih.38.1531190965716; Mon, 09 Jul 2018 19:49:25 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 19:49:25 -0700 (PDT) From: Patrick McManus Date: Mon, 9 Jul 2018 22:49:25 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Ben Schwartz , Daniel Kahn Gillmor , DoH WG , driu@ietf.org, HTTP Working Group , dnsop Content-Type: multipart/alternative; boundary="000000000000984e2405709c2d48" Archived-At: Subject: [Driu] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 02:49:29 -0000 --000000000000984e2405709c2d48 Content-Type: text/plain; charset="UTF-8" Hi All, I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in Montreal. We have often talked about the benefits and concerns of DNS information obtained from sources that are, shall we say, less globally trusted than a recursive a resolver. The central use case is DoH when pushed from an endpoint that isn't a recursive resolver but there have been other proposals. For example www.example.com pushes you a AAAA record for img1.example.com. Should you use it? What if it is for img1.img-example.com ? Do the relationship between these domains matter? What kind of relationship (i.e. it could be a domain relationship, or in the context of a browser it might be a first-party tab like relationship, etc..)? What are the implications of poison? Trackers? Privacy of requests never made? Speed? Competitive shenanigans or DoS attacks? This was out of scope for DoH. *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to 17:30 on Monday July 16th.* This is a meeting of interested folks looking to see if we can agree on next steps - we're not going to work out the details (nor should a side meeting try and do so). so we'll have a tight agenda that I suggest organizaing as follows: 1] What forms of transport could be in scope? HTTP/2 push is one such vector, but I've heard others. Spray paint for example. 2] What needs to be considered when using such data? (signatures? scope? etc?) 3] Who are the stakeholders for 1 + 2? 4] Is there enough interest to explore further? Next steps as output I hope you can come! -Patrick --000000000000984e2405709c2d48 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

I am organizing an ad-hoc Side = Meeting regarding 'Resolverless DNS' in Montreal.

We have often talked about the benefits and concerns of DNS informa= tion obtained from sources that are, shall we say, less globally trusted th= an a recursive a resolver. The central use case is DoH when pushed from an = endpoint that isn't a recursive resolver but there have been other prop= osals.

For example www.example.com pushes you a AAAA record for img1.example.com. Sho= uld you use it? What if it is for img1.img-example.com ? Do the relationship between the= se domains matter? What kind of relationship (i.e. it could be a domain rel= ationship, or in the context of a browser it might be a first-party tab lik= e relationship, etc..)? What are the implications of poison? Trackers? Priv= acy of requests never made? Speed? Competitive shenanigans or DoS attacks?<= /div>

This was out of scope for DoH.

We'll do the meeting over 1 hour in the Dorchester room from 1= 6:30 to 17:30 on Monday July 16th.

This is a m= eeting of interested folks looking to see if we can agree on next steps - w= e're not going to work out the details (nor should a side meeting try a= nd do so). so we'll have a tight agenda that I suggest organizaing as f= ollows:

1] What forms of transport could be in sco= pe? HTTP/2 push is one such vector, but I've heard others. Spray paint = for example.

2] What needs to be considered wh= en using such data? (signatures? scope? etc?)

3] W= ho are the stakeholders for 1 + 2?

4] Is there eno= ugh interest to explore further? Next steps as output

I hope you can come!

-Patrick
--000000000000984e2405709c2d48-- From nobody Mon Jul 9 19:55:43 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFA8E130EBC for ; Mon, 9 Jul 2018 19:55:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 oCrJtXxHuzKk for ; Mon, 9 Jul 2018 19:55:30 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BC45131070 for ; Mon, 9 Jul 2018 19:55:27 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id e13-v6so18954527iof.6 for ; Mon, 09 Jul 2018 19:55:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=hbievmt9Qg7XZ30HuxATmXkHzWVEzkLqH9rZb5dQaWY=; b=dmDee0ECsiSDTlMlZXMB3DVvrtMwOg5fTOJuRP3Tsru/mUDK2ySoKCeVRwywzIhi7g qHMqc0ccmIJSdpOTdGZgUPI5m5njuX1vkm4/MbKXrWgLjLHjoAod8DLYqLJ/uH+rL1Em epOk0jEyurphBXZFpQQcb9ZPYhcdHIe3uQS/Lq4tYLXM+Re5q7iEh06ZxAmybLjP0E6E HqyutDF6Wd6TaneB0GkUOrjpCzDUxnnfmfER7xAHe8lHO7JH+cIzcz54hBmtak4fl/W/ jcktKZFcyr7bKn0GOyNt24iJV9daa9REm/p+D6dREqhz0ZvvgMeHZ+jUSc70/bpThTWK sioQ== 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=hbievmt9Qg7XZ30HuxATmXkHzWVEzkLqH9rZb5dQaWY=; b=VKHktk/gHrA0vzX0MD/tWNym75rgdyYgsc4/ge49vr4lUJLU1aBhFQsZvkeS6kOsSo CuChS8q2YCuYjtBRdCSlfM7aCAx2Y0cT23Nie12rKrjSrYS66YsLaPqC/me7s5fW1O+2 unjMbfyBaH3qhZBnhVhi7JqFbfKK7NERKB2fkTLHe78HPDVHDBHySv+AiMH37noR/g6i AIkPAYbnPDgmQ4jpQ3TnYbds5RA534CrM/rJNUh30WBAEmGkt+SUW9PLBFFOrdgqGrwQ U2UgPaQ0yK/CsTGNluDSMIpByc5neJFt7/uaaGWjjFLyceBjuuoGiznqXpaOT4DFICpN KOGg== X-Gm-Message-State: AOUpUlGFCayNzPIW8aKE/gEkt7jHWo5wMMiEINoX7jrmXGabnDHZN6Hw n4IdRHYCmcUecDfxCOzilSQ6bz+DV+vWa417dNruDw== X-Google-Smtp-Source: AAOMgpfm/h7ZdeoqmxrYYxAWCOXsIvKIGk4JFbHfLfmOHCkBjLjTVygxCjcid55AXYB8biALia3Ea8UdDK1IGs9q1qk= X-Received: by 2002:a6b:9d0b:: with SMTP id g11-v6mr20108924ioe.85.1531191326640; Mon, 09 Jul 2018 19:55:26 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ted Lemon Date: Mon, 9 Jul 2018 22:55:16 -0400 Message-ID: To: Patrick McManus Cc: Ben Schwartz , Daniel Kahn Gillmor , DoH WG , HTTP Working Group , dnsop , driu@ietf.org Content-Type: multipart/alternative; boundary="0000000000001ba40005709c43ea" Archived-At: Subject: Re: [Driu] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 02:55:32 -0000 --0000000000001ba40005709c43ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This sounds an awful lot like an unapproved bof. The reason we don=E2=80=99= t do those is that they tend to make it hard for people to participate. Why isn=E2=80=99t this in scope for dnsop? On Mon, Jul 9, 2018 at 10:49 PM Patrick McManus wrote: > Hi All, > > I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in > Montreal. > > We have often talked about the benefits and concerns of DNS information > obtained from sources that are, shall we say, less globally trusted than = a > recursive a resolver. The central use case is DoH when pushed from an > endpoint that isn't a recursive resolver but there have been other > proposals. > > For example www.example.com pushes you a AAAA record for img1.example.com= . > Should you use it? What if it is for img1.img-example.com ? Do the > relationship between these domains matter? What kind of relationship (i.e= . > it could be a domain relationship, or in the context of a browser it migh= t > be a first-party tab like relationship, etc..)? What are the implications > of poison? Trackers? Privacy of requests never made? Speed? Competitive > shenanigans or DoS attacks? > > This was out of scope for DoH. > > *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to > 17:30 on Monday July 16th.* > > This is a meeting of interested folks looking to see if we can agree on > next steps - we're not going to work out the details (nor should a side > meeting try and do so). so we'll have a tight agenda that I suggest > organizaing as follows: > > 1] What forms of transport could be in scope? HTTP/2 push is one such > vector, but I've heard others. Spray paint for example. > > 2] What needs to be considered when using such data? (signatures? scope? > etc?) > > 3] Who are the stakeholders for 1 + 2? > > 4] Is there enough interest to explore further? Next steps as output > > I hope you can come! > > -Patrick > > _______________________________________________ > DRIU mailing list > DRIU@ietf.org > https://www.ietf.org/mailman/listinfo/driu > --0000000000001ba40005709c43ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This sounds an awful lot like an unapproved bof. The= reason we don=E2=80=99t do those is that they tend to make it hard for peo= ple to participate. Why isn=E2=80=99t this in scope for dnsop?
<= div>
On Mon, Jul 9, 2018 at = 10:49 PM Patrick McManus <pmcman= us@mozilla.com> wrote:
Hi All,

I am organizing an ad-hoc Side Meeti= ng regarding 'Resolverless DNS' in Montreal.

We have often talked about the benefits and concerns of DNS information = obtained from sources that are, shall we say, less globally trusted than a = recursive a resolver. The central use case is DoH when pushed from an endpo= int that isn't a recursive resolver but there have been other proposals= .

For example www.example.com pushes you a AAAA record for img1.example.com. Should= you use it? What if it is for img1.img-example.com ? Do the relationship between these = domains matter? What kind of relationship (i.e. it could be a domain relati= onship, or in the context of a browser it might be a first-party tab like r= elationship, etc..)? What are the implications of poison? Trackers? Privacy= of requests never made? Speed? Competitive shenanigans or DoS attacks?

This was out of scope for DoH.

We'll do the meeting over 1 hour in the Dorchester room from 16:3= 0 to 17:30 on Monday July 16th.

This is a meet= ing of interested folks looking to see if we can agree on next steps - we&#= 39;re not going to work out the details (nor should a side meeting try and = do so). so we'll have a tight agenda that I suggest organizaing as foll= ows:

1] What forms of transport could be in scope?= HTTP/2 push is one such vector, but I've heard others. Spray paint for= example.

2] What needs to be considered when = using such data? (signatures? scope? etc?)

3] Who = are the stakeholders for 1 + 2?

4] Is there enough= interest to explore further? Next steps as output

=
I hope you can come!

-Patrick

<= /div>
_______________________________________________
DRIU mailing list
DRIU@ietf.org
https://www.ietf.org/mailman/listinfo/driu
--0000000000001ba40005709c43ea-- From nobody Mon Jul 9 20:06:33 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D4561310ED; Mon, 9 Jul 2018 20:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 UVkKhTlb8Yda; Mon, 9 Jul 2018 20:06:29 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 58EC0130E43; Mon, 9 Jul 2018 20:06:29 -0700 (PDT) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by linode64.ducksong.com (Postfix) with ESMTPSA id C712D3A054; Mon, 9 Jul 2018 23:06:27 -0400 (EDT) Received: by mail-oi0-f42.google.com with SMTP id 13-v6so39883001ois.1; Mon, 09 Jul 2018 20:06:27 -0700 (PDT) X-Gm-Message-State: APt69E2Es9uwiBG8S9Q+I887+w1CIJMQIp9YumyDb+0R1LyWLbHaHYA0 XFYvJvGWvSrdM+OLFvq7PaOVfFFOZjLDS/5Gh0I= X-Google-Smtp-Source: AAOMgpf9TbJJx9QCkXtfqJ2zqOOPvxS7P/NWR5Teg1n7rNi7h5h7Ejnfu5sm5V61DUD0Qi/zdsBIpROuWjGuwEoKQ5M= X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr24109264oib.155.1531191987416; Mon, 09 Jul 2018 20:06:27 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Mon, 9 Jul 2018 20:06:26 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Mon, 9 Jul 2018 23:06:26 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Ted Lemon Cc: Patrick McManus , Ben Schwartz , Daniel Kahn Gillmor , DoH WG , HTTP Working Group , dnsop , driu@ietf.org Content-Type: multipart/alternative; boundary="0000000000007e3a0705709c6a62" Archived-At: Subject: Re: [Driu] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 03:06:32 -0000 --0000000000007e3a0705709c6a62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable this is essentially a bar bof - though lacking in a bar and I'm fond of more professional terms so I call it a side meeting. It has no standing. If you're interested then please come, if you're not or are conflicted then you're missing anything process wise. Someday it might graduate to becoming a bof - but I would never put a bof forward that didn't have a proposal I was comfortable with. This is indeed a side meeting for anyone interested to see if there is a shared vision for what such a proposal might look like. Its not in scope for any wg as there isn't a proposal. Its quite possible that it might have multiple outcomes which are in scope for multiple application groups; I've tried to cc the likely suspects here. But that is presupposing outcomes. -P On Mon, Jul 9, 2018 at 10:55 PM, Ted Lemon wrote: > This sounds an awful lot like an unapproved bof. The reason we don=E2=80= =99t do > those is that they tend to make it hard for people to participate. Why > isn=E2=80=99t this in scope for dnsop? > > On Mon, Jul 9, 2018 at 10:49 PM Patrick McManus > wrote: > >> Hi All, >> >> I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in >> Montreal. >> >> We have often talked about the benefits and concerns of DNS information >> obtained from sources that are, shall we say, less globally trusted than= a >> recursive a resolver. The central use case is DoH when pushed from an >> endpoint that isn't a recursive resolver but there have been other >> proposals. >> >> For example www.example.com pushes you a AAAA record for img1.example.co= m. >> Should you use it? What if it is for img1.img-example.com ? Do the >> relationship between these domains matter? What kind of relationship (i.= e. >> it could be a domain relationship, or in the context of a browser it mig= ht >> be a first-party tab like relationship, etc..)? What are the implication= s >> of poison? Trackers? Privacy of requests never made? Speed? Competitive >> shenanigans or DoS attacks? >> >> This was out of scope for DoH. >> >> *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to >> 17:30 on Monday July 16th.* >> >> This is a meeting of interested folks looking to see if we can agree on >> next steps - we're not going to work out the details (nor should a side >> meeting try and do so). so we'll have a tight agenda that I suggest >> organizaing as follows: >> >> 1] What forms of transport could be in scope? HTTP/2 push is one such >> vector, but I've heard others. Spray paint for example. >> >> 2] What needs to be considered when using such data? (signatures? scope? >> etc?) >> >> 3] Who are the stakeholders for 1 + 2? >> >> 4] Is there enough interest to explore further? Next steps as output >> >> I hope you can come! >> >> -Patrick >> >> _______________________________________________ >> DRIU mailing list >> DRIU@ietf.org >> https://www.ietf.org/mailman/listinfo/driu >> > --0000000000007e3a0705709c6a62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
this is essentially a bar bof - though lacking in a b= ar and I'm fond of more professional terms so I call it a side meeting.= It has no standing. If you're interested then please come, if you'= re not or are conflicted then you're missing anything process wise.
=

Someday it might graduate to becoming a bof - but= I would never put a bof forward that didn't have a proposal I was comf= ortable with. This is indeed a side meeting for anyone interested to see if= there is a shared vision for what such a proposal might look like.

Its not in scope for any wg as there isn't a prop= osal. Its quite possible that it might have multiple outcomes which are in = scope for multiple application groups; I've tried to cc the likely susp= ects here.=C2=A0 But that is presupposing outcomes.

-P


On Mon, Jul 9, 2018 at 10:55 PM, Ted Lemon <me= llon@fugue.com> wrote:
This sounds an awful lot like an unapproved bof. The rea= son we don=E2=80=99t do those is that they tend to make it hard for people = to participate. Why isn=E2=80=99t this in scope for dnsop?
=
On M= on, Jul 9, 2018 at 10:49 PM Patrick McManus <pmcmanus@mozilla.com> wrote:
Hi All,

I am organizing an ad-hoc Side Meeting = regarding 'Resolverless DNS' in Montreal.

= We have often talked about the benefits and concerns of DNS information obt= ained from sources that are, shall we say, less globally trusted than a rec= ursive a resolver. The central use case is DoH when pushed from an endpoint= that isn't a recursive resolver but there have been other proposals.

For example www.example.com pushes you a AAAA record for img1.example.com. Should you = use it? What if it is for img1.img-example.com ? Do the relationship between these domai= ns matter? What kind of relationship (i.e. it could be a domain relationshi= p, or in the context of a browser it might be a first-party tab like relati= onship, etc..)? What are the implications of poison? Trackers? Privacy of r= equests never made? Speed? Competitive shenanigans or DoS attacks?

This was out of scope for DoH.

We'll do the meeting over 1 hour in the Dorchester room from 16:30 to = 17:30 on Monday July 16th.

This is a meeting o= f interested folks looking to see if we can agree on next steps - we're= not going to work out the details (nor should a side meeting try and do so= ). so we'll have a tight agenda that I suggest organizaing as follows:<= /div>

1] What forms of transport could be in scope? HTTP= /2 push is one such vector, but I've heard others. Spray paint for exam= ple.

2] What needs to be considered when using= such data? (signatures? scope? etc?)

3] Who are t= he stakeholders for 1 + 2?

4] Is there enough inte= rest to explore further? Next steps as output

= I hope you can come!

-Patrick

_______________________________________________
DRIU mailing list
DRIU@ietf.org
https://www.ietf.org/mailman/listinfo/driu

--0000000000007e3a0705709c6a62-- From nobody Tue Jul 10 06:28:48 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA995130E78; Tue, 10 Jul 2018 06:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 1xmSoNHA8IMm; Tue, 10 Jul 2018 06:28:45 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id D00B9130E9D; Tue, 10 Jul 2018 06:28:44 -0700 (PDT) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3CE153A026; Tue, 10 Jul 2018 09:28:44 -0400 (EDT) Received: by mail-oi0-f42.google.com with SMTP id 13-v6so42582469ois.1; Tue, 10 Jul 2018 06:28:44 -0700 (PDT) X-Gm-Message-State: APt69E0Nlcy1MzoSORNP8Klhwp7uC6qp5oWnCV4sweEEegwLbD871MfH MSqagI/3L4hPCSVaaUAH3tiOqLfMTjcQLF0tRKY= X-Google-Smtp-Source: AAOMgpddJX+GMF9Ubh/Zt1sdM63rBsPA9+JKqAhpZLIYNEQVNnQuiubsN33mHDdXkyhF+FDwBIwvRq7pjNf5tQlUYqo= X-Received: by 2002:aca:e7c8:: with SMTP id e191-v6mr25581825oih.132.1531229323894; Tue, 10 Jul 2018 06:28:43 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 06:28:43 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Tue, 10 Jul 2018 09:28:43 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Philip Homburg Cc: dnsop , Patrick McManus , DoH WG , driu@ietf.org, HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000ebce400570a51bea" Archived-At: Subject: Re: [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 13:28:47 -0000 --000000000000ebce400570a51bea Content-Type: text/plain; charset="UTF-8" > Assuming that in the context of DoH reply size is not an issue, is seems to > me that this use case is already solved by DNSSEC. Just push all required > signatures, key material and DS records that allow the receiving side to > validate the additional information. > > that validates its a valid dns record. And maybe that's the whole answer - at which point we still need to write that down along with the scope of where its valid. otoh - maybe its not the same valid dns record another resolver might want you to use. perhaps you have a stronger trust relationship with that other resolver. hmm. otoh - maybe an unsigned record is ok in an https context where DNS isn't the https security model. this is the kind of stuff that I expect is in scope for discussion. > Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC no. --000000000000ebce400570a51bea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Assuming that in the context of DoH reply size is not an issue, is s= eems to
me that this use case is already solved by DNSSEC. Just push all required signatures, key material and DS records that allow the receiving side to validate the additional information.


that validates its a valid dns record.= And maybe that's the whole answer - at which point we still need to wr= ite that down along with the scope of where its valid.

otoh - maybe its not the same valid dns record another resolver mi= ght want you to use. perhaps you have a stronger trust relationship with th= at other resolver. hmm.

otoh - maybe an unsigned r= ecord is ok in an https context where DNS isn't the https security mode= l.

this is the kind of stuff that I expect is in s= cope for discussion.
=C2=A0
Are you trying to re-invent DNSSEC for people who don't want to deploy<= br> DNSSEC

no.
--000000000000ebce400570a51bea-- From nobody Tue Jul 10 06:47:13 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5599A130E9D; Tue, 10 Jul 2018 06:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665] 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 msQvTJNPOF3A; Tue, 10 Jul 2018 06:46:57 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id C8AA41277CC; Tue, 10 Jul 2018 06:46:57 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by linode64.ducksong.com (Postfix) with ESMTPSA id 5A9E03A055; Tue, 10 Jul 2018 09:46:57 -0400 (EDT) Received: by mail-oi0-f50.google.com with SMTP id w126-v6so42666313oie.7; Tue, 10 Jul 2018 06:46:57 -0700 (PDT) X-Gm-Message-State: APt69E3vq4QYc1ndaKNEzvprDSM7Y3Aifv4WBx20l5bS64vtZ2MX2Vqu xGiKV7lUnR7PAH8/GOGl2IrIuu/lxoPGirS7aek= X-Google-Smtp-Source: AAOMgpep4y/uhziPfTS7snWkI8Ic4YLMQ/M2ytR5I71voqRVfo0Tk3ZNpruzQR2pc4VAgiHq4Gp2pEJDor+qs/2eB0k= X-Received: by 2002:aca:e7c8:: with SMTP id e191-v6mr25653367oih.132.1531230417018; Tue, 10 Jul 2018 06:46:57 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 06:46:56 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Tue, 10 Jul 2018 09:46:56 -0400 X-Gmail-Original-Message-ID: Message-ID: To: manu tman Cc: Patrick McManus , Ben Schwartz , Daniel Kahn Gillmor , DoH WG , HTTP Working Group , dnsop , driu@ietf.org Content-Type: multipart/alternative; boundary="00000000000013681f0570a55d5c" Archived-At: Subject: Re: [Driu] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 13:47:00 -0000 --00000000000013681f0570a55d5c Content-Type: text/plain; charset="UTF-8" probably not (whatever is available will be adhoc) - its a side meeting (aka bar bof) meant to take advantage of whomever is there. It has no process value. I'll make an effort to take minutes and report out though. On Tue, Jul 10, 2018 at 9:42 AM, manu tman wrote: > > > On Mon, Jul 9, 2018 at 7:49 PM Patrick McManus > wrote: > >> >> *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to >> 17:30 on Monday July 16th.* >> > > Will it be recorded and will there be everything set for remote > participants? > > Manu > --00000000000013681f0570a55d5c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
probably not (whatever is available will be adhoc) - = its a side meeting (aka bar bof) meant to take advantage of whomever is the= re. It has no process value.

I'll make an effo= rt to take minutes and report out though.


On Tue, Jul 10, 2018 at = 9:42 AM, manu tman <chantr4@gmail.com> wrote:


On Mon, Jul 9, 2018 at 7:49 PM Patrick McManu= s <pmcmanus@mo= zilla.com> wrote:

We'll do the meeting over 1 hour in the Dorchester= room from 16:30 to 17:30 on Monday July 16th.
=

Will it be recorded an= d will there be everything set for remote participants?

Manu

--00000000000013681f0570a55d5c-- From nobody Tue Jul 10 07:03:26 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC30130E9F; Tue, 10 Jul 2018 07:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (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 1qDFlKBAAVtP; Tue, 10 Jul 2018 07:03:10 -0700 (PDT) Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (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 F1B29130E8C; Tue, 10 Jul 2018 07:03:09 -0700 (PDT) Received: by mail-wr1-x434.google.com with SMTP id a3-v6so5521821wrt.2; Tue, 10 Jul 2018 07:03:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UBghc4tka6ONj6OZRTSQMjTHhWawF0VRGtuU0L0GCUE=; b=DRkqxf33Xk8Czrc5gZbOocBf2goTWCnXkpOdhfVEwhIA97Qm2oIrQzRRwy5SSckfCU jESICt289qorRQs8ZTTUTZ8jMrWSuAlfqNqWjdcnq5UxG+oFuWSl2cYtqsTO2R5/3kaK tTcBFBq0trpW0Pf0vZZ/JahPudyGL3raPtEtdIS6dtOlodAzfcP5BiSixvd9RW7zcxcm BBmtPMqzt5iS5zuxwLbnHmPVNssnqUwETDZQwykbffPTjOIfdTjCbvw4DUEM/8wiqHEn luGZ/IVeKMJQiKsBEMG7f1YS+YXhH6K1WOgAAsmAaw8cEEIiGBBxs02d0gwj4m7hdYUi KZxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UBghc4tka6ONj6OZRTSQMjTHhWawF0VRGtuU0L0GCUE=; b=X9oBImGQRPIyQIm+96j8OgWUVSCZnykhuAm7XPTAhuIVTX+Xhgoe2BZX3tt48jFiWf R5EryXwTzZkDSTmWXD8FEgLNDpHTxbhXrTo/DdZ770ajMryV9d+oiEq47EZcnLJu5ryh YSkqTYqsDQp+PFcUWeF/X6kQwJ23+af8thhiExHZY1s6vCjDCKH3cvjV12wpANji7lbX AnnqZE1BlLUcuHhSdjzdJnWlEsY0oZkx/YC1ALEu5/D6JdIYBVPHDG2F8K4ko81gxFsc kYN42pXbbqiFauq57+yh/i/QfQfi33HbDQqU3CBdP/twjli/9HH7xqzzU0/2oNCxrY1E fUqg== X-Gm-Message-State: AOUpUlGlyFrArOVmFQpSKVniZv3dbRqycZJvx31aNhcaqhUOXINADYHw BzxU068uxkB2sn9DVcti4N0b20l7YwC3Gha972s= X-Google-Smtp-Source: AAOMgpc4ZHdjYs/R+jOVTlPcTioXZlycl/ALApiVPyT8XiYe0HwD+mVVwQ5b84vxyROo9GQNf+iLFSVk8qrf5HKBCrQ= X-Received: by 2002:adf:e34d:: with SMTP id n13-v6mr10166512wrj.158.1531231388542; Tue, 10 Jul 2018 07:03:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:a414:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 07:03:08 -0700 (PDT) In-Reply-To: References: From: Tim Wicinski Date: Tue, 10 Jul 2018 10:03:08 -0400 Message-ID: To: Philip Homburg Cc: dnsop , HTTP Working Group , DoH WG , Patrick McManus , driu@ietf.org Content-Type: multipart/alternative; boundary="000000000000fbaa1e0570a59615" Archived-At: Subject: Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 14:03:13 -0000 --000000000000fbaa1e0570a59615 Content-Type: text/plain; charset="UTF-8" > > "Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC?" My magic 8-ball says "signs point to Yes" On Tue, Jul 10, 2018 at 5:09 AM, Philip Homburg wrote: > >For example www.example.com pushes you a AAAA record for img1.example.com > . > >Should you use it? What if it is for img1.img-example.com ? Do the > >relationship between these domains matter? What kind of relationship (i.e. > >it could be a domain relationship, or in the context of a browser it might > >be a first-party tab like relationship, etc..)? What are the implications > >of poison? Trackers? Privacy of requests never made? Speed? Competitive > >shenanigans or DoS attacks? > > > >This was out of scope for DoH. > > Assuming that in the context of DoH reply size is not an issue, is seems to > me that this use case is already solved by DNSSEC. Just push all required > signatures, key material and DS records that allow the receiving side to > validate the additional information. > > Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC? > > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --000000000000fbaa1e0570a59615 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
"Are you trying to re-invent DNSSEC = for people who don't want to deploy
DNSSEC?"
<= br>
My magic 8-ball says "signs point to Yes"=C2=A0

On Tue, J= ul 10, 2018 at 5:09 AM, Philip Homburg <pch-dnsop-3@u-1.phicoh.co= m> wrote:
= >For example www.example.com pushes you a AAAA record for img1.example.co= m.
>Should you use it? What if it is for img1.img-example.com ? Do th= e
>relationship between these domains matter? What kind of relationship (i= .e.
>it could be a domain relationship, or in the context of a browser it mi= ght
>be a first-party tab like relationship, etc..)? What are the implicatio= ns
>of poison? Trackers? Privacy of requests never made? Speed? Competitive=
>shenanigans or DoS attacks?
>
>This was out of scope for DoH.

Assuming that in the context of DoH reply size is not an issue, is s= eems to
me that this use case is already solved by DNSSEC. Just push all required signatures, key material and DS records that allow the receiving side to validate the additional information.

Are you trying to re-invent DNSSEC for people who don't want to deploy<= br> DNSSEC?


_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh

--000000000000fbaa1e0570a59615-- From nobody Tue Jul 10 07:14:52 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB069130F28; Tue, 10 Jul 2018 01:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 64AC5L8Mql6n; Tue, 10 Jul 2018 01:42:10 -0700 (PDT) Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 70A84130F1C; Tue, 10 Jul 2018 01:42:10 -0700 (PDT) Received: from [192.168.43.179] (unknown [5.33.14.79]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id BACD7892B9; Tue, 10 Jul 2018 08:42:03 +0000 (UTC) Message-ID: <5B447154.5010307@redbarn.org> Date: Tue, 10 Jul 2018 10:41:56 +0200 From: Paul Vixie User-Agent: Postbox 5.0.25 (Windows/20180328) MIME-Version: 1.0 To: Patrick McManus CC: Ben Schwartz , Daniel Kahn Gillmor , DoH WG , driu@ietf.org, HTTP Working Group , dnsop References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 07:14:51 -0700 Subject: Re: [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 08:42:13 -0000 Patrick McManus wrote: > ... > > For example www.example.com pushes you a AAAA > record for img1.example.com . Should you use > it? no. sibling names might be delegation points. kashpureff taught us this in 1996 or so, and kaminsky reinforced that lesson in 2008. > What if it is for img1.img-example.com ? certainly not. -- P Vixie From nobody Tue Jul 10 07:14:58 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72413130E1D; Tue, 10 Jul 2018 02:09:22 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" 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, 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 N3Xv3bvsMMYr; Tue, 10 Jul 2018 02:09:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 EAE27130E14; Tue, 10 Jul 2018 02:09:19 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fcoe5-0000GuC; Tue, 10 Jul 2018 11:09:17 +0200 Message-Id: To: dnsop@ietf.org Cc: Patrick McManus Cc: DoH WG , driu@ietf.org, HTTP Working Group From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com In-reply-to: Your message of "Mon, 9 Jul 2018 22:49:25 -0400 ." Date: Tue, 10 Jul 2018 11:09:16 +0200 Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 07:14:51 -0700 Subject: Re: [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 09:09:23 -0000 >For example www.example.com pushes you a AAAA record for img1.example.com. >Should you use it? What if it is for img1.img-example.com ? Do the >relationship between these domains matter? What kind of relationship (i.e. >it could be a domain relationship, or in the context of a browser it might >be a first-party tab like relationship, etc..)? What are the implications >of poison? Trackers? Privacy of requests never made? Speed? Competitive >shenanigans or DoS attacks? > >This was out of scope for DoH. Assuming that in the context of DoH reply size is not an issue, is seems to me that this use case is already solved by DNSSEC. Just push all required signatures, key material and DS records that allow the receiving side to validate the additional information. Are you trying to re-invent DNSSEC for people who don't want to deploy DNSSEC? From nobody Tue Jul 10 07:15:02 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56864130FC4; Tue, 10 Jul 2018 06:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 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_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 n-k16YZ2Cvd7; Tue, 10 Jul 2018 06:42:26 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DE6D131158; Tue, 10 Jul 2018 06:42:26 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id y10-v6so5560663ioa.10; Tue, 10 Jul 2018 06:42:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0eOH/RC2GtAj1uACi5ZejTEKKv6YyfXsyGZ0W6kn+N4=; b=PAxuq8gThq8pFkFjn3QORolYQcYu4EFly2b7+8kM5XZC0US5lr1zM23oYZektoxiqb O5UmABa3p0fM/Pait5/8ftyTnMS33BNW1u1Ry/6o/zJiv8L+efAGemFXU4azUk75sghC PdGg0s/Rpoc5+2kTHdozY6aF2PPFBWY81GWjqkjHa4F5dNZL3VnXyzkM19jbsFpeX6Ym pFt9dFDNs+L9g0MpVJaNJT7YflFKuCMj36r7/LrlfaryvUfIshtFZzivWNtHCiNTngiK /xdQUGDheOfS9wuTgfSdVNiqEqsxXDtcbrF6HI/63HNMkRSyzTiFFuWXgOrzRyHlBqM9 xAmQ== 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=0eOH/RC2GtAj1uACi5ZejTEKKv6YyfXsyGZ0W6kn+N4=; b=qdZQzkDpiB88czNIGfYy08LbqaA3yEBq77BE8pNZPL9A6K5PQ4hSoukdotwQhOOiQn ocbrSaclpTLHjq5wvILcyvS2UZcb86Ehdw+vpmXPujC5/w8SAkpYlNZj8WP9U2vVCREt LiW1i6yB1so/PXqGw4Cw/eIcYHtIY4YbA7GKYeI9GL3eKMTLaPr8be341qdup/dbzYOQ 57wlwDhU/+L7uVxxfahh9MknlBtu2E/Zs/uopLZ1PmwsZsAaQCle2RH8EcUt0b9nE5DF OPy+FU1PfXIgDcBwjCp0CuyhQvE/NlLgssj1GNuVM9mpiMvrHtQG1qmndyd8tV6Za8yI RwNQ== X-Gm-Message-State: AOUpUlGGSn/FDxur5JPBATsm2+B1QPejENMZ/Pu+wfphfqCHAkyqJRFU ufny5LRQju6Fe3F+gr7N9Xe7U4uKGV/tyEJ20b4= X-Google-Smtp-Source: AAOMgpf0Foh/bqyHs38sz+/9xvflUrnd7dp0LS2osR6Er1WjAvNjy9W2NyXVM7ro73mn+m3cnnENoKgs4u8AtJujkIE= X-Received: by 2002:a6b:c90a:: with SMTP id z10-v6mr19948415iof.135.1531230145413; Tue, 10 Jul 2018 06:42:25 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: manu tman Date: Tue, 10 Jul 2018 06:42:14 -0700 Message-ID: To: Patrick McManus Cc: Ben Schwartz , Daniel Kahn Gillmor , DoH WG , HTTP Working Group , dnsop , driu@ietf.org Content-Type: multipart/alternative; boundary="000000000000e305a30570a54c7d" Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 07:14:51 -0700 Subject: Re: [Driu] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 13:42:34 -0000 --000000000000e305a30570a54c7d Content-Type: text/plain; charset="UTF-8" On Mon, Jul 9, 2018 at 7:49 PM Patrick McManus wrote: > > *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to > 17:30 on Monday July 16th.* > Will it be recorded and will there be everything set for remote participants? Manu --000000000000e305a30570a54c7d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon,= Jul 9, 2018 at 7:49 PM Patrick McManus <pmcmanus@mozilla.com> wrote:

We'll do the meeting over 1 hour= in the Dorchester room from 16:30 to 17:30 on Monday July 16th.
<= /div>

Will it be = recorded and will there be everything set for remote participants?

Manu
--000000000000e305a30570a54c7d-- From nobody Tue Jul 10 08:06:33 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30763130FCF; Tue, 10 Jul 2018 07:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1bROqm8coot4; Tue, 10 Jul 2018 07:59:11 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2AC81130FCD; Tue, 10 Jul 2018 07:59:11 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41Q5233w6dzDm5; Tue, 10 Jul 2018 16:59:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1531234747; bh=3/+32zpeEZ4nIxPZISHOvOY63QE9kAj2xJORSW0LWDk=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=DYHl77ahR6hvcHhlPlNCFNcvV0IoFhjGUo6rfBtfM6Uyc3W7f6C8gCkr2LIKHl8zA 31YR5O8N/DHHBYzPtDg50MnEviRXyP0ElpytTnwV8uOpEUWu2du1M5vmQ8N+cRHv8P jrsKZsTiUt8jTpgvtcjWn3uNDuFhugdhH8U9cl4w= 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 vL-UWlkEHvhP; Tue, 10 Jul 2018 16:59:06 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 10 Jul 2018 16:59:06 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 8717D39A6A8; Tue, 10 Jul 2018 10:59:05 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca 8717D39A6A8 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8080541682B5; Tue, 10 Jul 2018 10:59:05 -0400 (EDT) Date: Tue, 10 Jul 2018 10:59:05 -0400 (EDT) From: Paul Wouters To: Philip Homburg cc: dnsop@ietf.org, HTTP Working Group , DoH WG , Patrick McManus , driu@ietf.org In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 08:06:32 -0700 Subject: Re: [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 14:59:15 -0000 On Tue, 10 Jul 2018, Philip Homburg wrote: >> For example www.example.com pushes you a AAAA record for img1.example.com. >> Should you use it? What if it is for img1.img-example.com ? Do the >> relationship between these domains matter? What kind of relationship (i.e. >> it could be a domain relationship, or in the context of a browser it might >> be a first-party tab like relationship, etc..)? What are the implications >> of poison? Trackers? Privacy of requests never made? Speed? Competitive >> shenanigans or DoS attacks? >> >> This was out of scope for DoH. I'm also confused about what the scope is. If you connect over TLS to a site and it has links to other hostnames, I guess you trust it ? The TLS/trust mechanism has really no other way of certifying the content server over TLS, unless you want to object/webpage signing. Which is impossible in today's dynamic web state. > Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC? It seems more like an extension of the Public Suffix. Which domains can make claims about other domains. I'm not sure I see the connection with private DNS queries. Paul From nobody Tue Jul 10 08:19:46 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23DD8130FDB; Tue, 10 Jul 2018 08:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0wMBNtbPAd-Q; Tue, 10 Jul 2018 08:19:37 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E00E4130FE5; Tue, 10 Jul 2018 08:19:35 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41Q5Td07l5zDm5; Tue, 10 Jul 2018 17:19:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1531235973; bh=gH0uXzuqvfQnwfwAXQpXHYCcNJM8y9nIzygp41ElniQ=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=n8/KpKmsUW8YI4np3XFjkn6DRBNkHqgPwZ2VXlTGe+0X8dZNsNe1AolZObcXxrx7o YtTdImHDRmBc+VLl8J6PCs6EWZ8KROSb3D1oIzFGwxi4PcprYZn9apnEE4auioH1mO /Ih0WCV8KtsxWip9QNQV4nm7otULAah47jp7hI/g= 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 tZDyKNojmzR8; Tue, 10 Jul 2018 17:19:31 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 10 Jul 2018 17:19:30 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E256739A6A8; Tue, 10 Jul 2018 11:19:29 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca E256739A6A8 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D8CC441682B5; Tue, 10 Jul 2018 11:19:29 -0400 (EDT) Date: Tue, 10 Jul 2018 11:19:29 -0400 (EDT) From: Paul Wouters To: Adam Roach cc: Philip Homburg , Patrick McManus , dnsop@ietf.org, DoH WG , driu@ietf.org, HTTP Working Group In-Reply-To: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> Message-ID: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 15:19:40 -0000 On Tue, 10 Jul 2018, Adam Roach wrote: > On 7/10/18 9:59 AM, Paul Wouters wrote: >> It seems more like an extension of the Public Suffix. Which domains can >> make claims about other domains. > > Based on the conversation that took place in DoH in Singapore, I think it's > mostly *not* about this. The questions that have come up so far include: (a) > If the record that is pushed to me is DNSSEC signed, is that sufficient to > trust it? (b) If the record that is pushed to me is not DNS signed, but I'm > using it in a context that requires TLS (e.g., HTTPS), and the thing that I > connect to when I use the record can present a cert that proves its identity, > is that okay? I see. I guess I agree more now with the previous poster that this is more like yet another kind of "transparancy" workaround for not wanting to deploy dnssec :) I understand that having a WebPKI and a DANE PKI leads to an unwanted mixture of trust models. It might be useful to talk about that, especially in light of tls-dnssec-chain where it seems that some proposals result in a preventative block of a DANE PKI for no apparent other gain. Paul From nobody Tue Jul 10 08:28:00 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314C81311AB; Tue, 10 Jul 2018 08:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 6TQTeCGggPXs; Tue, 10 Jul 2018 08:09:47 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A4E1131184; Tue, 10 Jul 2018 08:09:47 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AF9fWg085359 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 10:09:44 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Paul Wouters , Philip Homburg Cc: driu@ietf.org, dnsop@ietf.org, DoH WG , HTTP Working Group , Patrick McManus References: From: Adam Roach Message-ID: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> Date: Tue, 10 Jul 2018 10:09:41 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 08:27:58 -0700 Subject: Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 15:09:57 -0000 [as an individual] On 7/10/18 9:59 AM, Paul Wouters wrote: > It seems more like an extension of the Public Suffix. Which domains can > make claims about other domains. Based on the conversation that took place in DoH in Singapore, I think it's mostly *not* about this. The questions that have come up so far include: (a) If the record that is pushed to me is DNSSEC signed, is that sufficient to trust it? (b) If the record that is pushed to me is not DNS signed, but I'm using it in a context that requires TLS (e.g., HTTPS), and the thing that I connect to when I use the record can present a cert that proves its identity, is that okay? There *might* be some useful discussion that includes applying the PSL to determine who can vouch for what, but I would expect this to be of significantly lower priority; and, given DBOUND's recent failure, I doubt there's useful IETF work to be done in that space, at least for the time being. /a From nobody Tue Jul 10 09:02:41 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32D1C131024 for ; Tue, 10 Jul 2018 08:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 CsYKb7SrTyEZ for ; Tue, 10 Jul 2018 08:30:22 -0700 (PDT) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 671AA131029 for ; Tue, 10 Jul 2018 08:30:22 -0700 (PDT) Received: by mail-wm0-x22f.google.com with SMTP id s13-v6so12937343wmc.1 for ; Tue, 10 Jul 2018 08:30:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s5CFesfgJ2jLxkVR4YFgJKgPtCEkMh/3dbdo3NUhL7M=; b=dj2qc5Q6MTrnCEann9BXMzgT25sJ9W50NIWcDX3BDmUctr6ran8rQ8gzmEGAimKr86 on8PBdICex5dniywQhT0UsUdM7RtzH3ttCM0QVcnkQBKJX9vKTphGu1HpvIHMuiVqZ1N /dUeWsginS+mJFnhAMFYJ40PBeUk/U3G2Xjus= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=s5CFesfgJ2jLxkVR4YFgJKgPtCEkMh/3dbdo3NUhL7M=; b=sbLYsvGYDLJT8YIdEMvGVc2vUM+iXgreMDa4K7FO8Nqr5nwF7T61FfzNgKqUw9HzHc mY4Xn+HswRTvpKNH8Mcyx3Fj1prdnwaVnFn2XGEX3rDkmO46G8X21yzQm676uT2pt4ES xDiysuQP8xLqumfpa2ONQE+O5UN+640Ws/l/3J3l1fErb/JfCQ2WK+k04YPXnjx0MgGk oyKj0a6vQh/dleKfBUN+5D0W7v9tyUCwbj/cwMpNVtXJsEjDHOg1e8z38BLKhh8izgMq 28stqUV4RkRw5ht10BMTOwzOgQGtEbCLj17kKvZPj6taVXcC4irbuta2UhGkcRf/rMxO A/9w== X-Gm-Message-State: APt69E3MEB1dHxk3E2UMUKaxbcH1Qx73cFD8y1yNpuO5+srtVrwNPNCH KW+UqExsI8uyD2l4268jbxbDLA== X-Google-Smtp-Source: AAOMgpdW45wVyAGV2TmCg6NS6o/7zU55P9wT7TtA3bVwyzl9bmgzwGXGAJfqKYN+8lU1zpdE+iGcfA== X-Received: by 2002:a1c:30d2:: with SMTP id w201-v6mr14180928wmw.47.1531236620778; Tue, 10 Jul 2018 08:30:20 -0700 (PDT) Received: from [10.0.1.165] (host165-120-47-210.range165-120.btcentralplus.com. [165.120.47.210]) by smtp.gmail.com with ESMTPSA id c10-v6sm17366203wrs.6.2018.07.10.08.30.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 10 Jul 2018 08:30:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Joe Abley X-Mailer: iPad Mail (15F79) In-Reply-To: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> Date: Tue, 10 Jul 2018 16:30:18 +0100 Cc: Paul Wouters , Philip Homburg , Patrick McManus , dnsop@ietf.org, DoH WG , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> To: Adam Roach Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 09:02:39 -0700 Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 15:30:26 -0000 On Jul 10, 2018, at 16:09, Adam Roach wrote: > [as an individual] >=20 >> On 7/10/18 9:59 AM, Paul Wouters wrote: >> It seems more like an extension of the Public Suffix. Which domains can >> make claims about other domains.=20 >=20 > Based on the conversation that took place in DoH in Singapore, I think it'= s mostly *not* about this. The questions that have come up so far include: (= a) If the record that is pushed to me is DNSSEC signed, is that sufficient t= o trust it? (b) If the record that is pushed to me is not DNS signed, but I'= m using it in a context that requires TLS (e.g., HTTPS), and the thing that I= connect to when I use the record can present a cert that proves its identit= y, is that okay? I think perhaps the people who have been having these conversations are not b= eing ambitious enough. The pressures in the enterprise DNS market are overwhelmingly driven by the n= eed to make web apps more reliable, load faster, and offer user-specific con= tent. There are other reasons to want DNS tricks, but the customers that pay= the big money are all concerned with HTTPS UX. Some of the decision points a= re in the DNS and some are in HTTP. The DNS is overwhelmingly involved at UX= session initiation, but after that the HTTP layer has (can have) a far rich= er set of data about the user and is able to separate user-blocking decision= -making from the flow of the UX which also affords extra time to make decisi= ons without the user becoming frustrated. [To illustrate the architectural lunacy of the status quo, consider the data= sets that are gathered through real-user-monitoring in browsers, served at t= he HTTP layer, that are subsequently used to steer DNS traffic used to retri= eve resources back at the HTTP layer. There's a whole layer of derived datas= ets relating to the DNS there that are being generated by the web and used b= y the web, but with a tangy sandwich filler of DNS that is just overhead.] It seems like it would be nice then, after the UX-blocking elements are load= ed and the user is already engaged, for subsequent lookups to be driven in H= TTP and client-side scripting and to be presented to the stack as bare addre= sses rather than DNS names. That avoids the dependency on the DNS after init= ial page load altogether and leaves all the performance engineering decision= s in the same place as the content decisions. There are problems with this approach today (certificate matching, for examp= le) but I don't think the problems necessarily relate to the DNS. Perhaps th= ey relate to a local-context naming system that doesn't exist outside a java= script sandbox. I see the attraction of shifting name resolution to DOH sinc= e it makes it look like everything is a web app, but collapsing the address s= election back to the extent that you can avoid name resolution at all seems l= ike a better end goal. So rather than resolverless operation, think about resolutionless or nameles= s, eliminating the DNS as unnecessary overhead. Perhaps I have misunderstood the whole problem space, of course :-) Joe From nobody Tue Jul 10 09:23:47 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58581130E4A; Tue, 10 Jul 2018 09:23:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 95QFJvmELtlu; Tue, 10 Jul 2018 09:23:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A743126CC7; Tue, 10 Jul 2018 09:23:29 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AGMtwP097444 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 11:22:57 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Joe Abley Cc: Paul Wouters , driu@ietf.org, dnsop@ietf.org, DoH WG , Patrick McManus , Philip Homburg , HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Adam Roach Message-ID: Date: Tue, 10 Jul 2018 11:22:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 16:23:32 -0000 On 7/10/18 10:30 AM, Joe Abley wrote: > On Jul 10, 2018, at 16:09, Adam Roach wrote: > >> [as an individual] >> >>> On 7/10/18 9:59 AM, Paul Wouters wrote: >>> It seems more like an extension of the Public Suffix. Which domains can >>> make claims about other domains. >> Based on the conversation that took place in DoH in Singapore, I think it's mostly *not* about this. The questions that have come up so far include: (a) If the record that is pushed to me is DNSSEC signed, is that sufficient to trust it? (b) If the record that is pushed to me is not DNS signed, but I'm using it in a context that requires TLS (e.g., HTTPS), and the thing that I connect to when I use the record can present a cert that proves its identity, is that okay? > I think perhaps the people who have been having these conversations are not being ambitious enough. > > The pressures in the enterprise DNS market are overwhelmingly driven by the need to make web apps more reliable, load faster, and offer user-specific content. There are other reasons to want DNS tricks, but the customers that pay the big money are all concerned with HTTPS UX. Some of the decision points are in the DNS and some are in HTTP. The DNS is overwhelmingly involved at UX session initiation, but after that the HTTP layer has (can have) a far richer set of data about the user and is able to separate user-blocking decision-making from the flow of the UX which also affords extra time to make decisions without the user becoming frustrated. > > [To illustrate the architectural lunacy of the status quo, consider the data sets that are gathered through real-user-monitoring in browsers, served at the HTTP layer, that are subsequently used to steer DNS traffic used to retrieve resources back at the HTTP layer. There's a whole layer of derived datasets relating to the DNS there that are being generated by the web and used by the web, but with a tangy sandwich filler of DNS that is just overhead.] > > It seems like it would be nice then, after the UX-blocking elements are loaded and the user is already engaged, for subsequent lookups to be driven in HTTP and client-side scripting and to be presented to the stack as bare addresses rather than DNS names. That avoids the dependency on the DNS after initial page load altogether and leaves all the performance engineering decisions in the same place as the content decisions. Basically, you're describing a solution space that could be realized as something like: But this is really equivalent in just about every important way to sending the normal along with a pushed DNS record that indicates that "example.com" resolves to "192.0.2.1" -- and this latter thing is (to my understanding, at least) in scope of the conversation that Patrick is proposing to have. Note: I'm not saying anything about the trust issues that arise in either case, and I'm not trying to gloss over the need to perform a really careful analysis; I'm just saying that what you're suggesting is definitely equivalent to one of the implied eventual outcomes of what is being proposed. /a From nobody Tue Jul 10 09:34:44 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9633D13101B for ; Tue, 10 Jul 2018 09:34:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=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=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 yvAeiDwy-3lB for ; Tue, 10 Jul 2018 09:34:41 -0700 (PDT) Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF672131010 for ; Tue, 10 Jul 2018 09:34:40 -0700 (PDT) Received: by mail-lj1-x233.google.com with SMTP id 1-v6so17183637ljv.9 for ; Tue, 10 Jul 2018 09:34:40 -0700 (PDT) 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=RhOwDeizS2p1sDwMvQJpECvp62XALlw/l7BD48f8O0Q=; b=IyH9v9MEpD3onkQOraCj1qlObMwPrP4rA3G0nIFK5gpGgsOfkOUvMGU8njqdifHky/ 8NT14mdS//rC2adaxFv+A4yWyWfhfWrgAUKtSpeZTpuTsIPIhpeEpJVcK2/j7W+8o2RH Whp9rf5a9MlCekbQJGxQV7Y3GcJBqOuQVVA5E= 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=RhOwDeizS2p1sDwMvQJpECvp62XALlw/l7BD48f8O0Q=; b=UvbG8/DTcm7f0SQ7AkONArqy2ilVHXTGFyR7cp2N8L2wSQBcQWeoCE0/m/4520PfJN fyFr6EIIUaKg6NfFpHWYKx3WXs8v19/yooxLl0jiuEwyknH6YGGNDPSqknyygu2Lom5v hoH2jvhtVXV0Zbfh8lI+3SbdeK3i+TCaZYVghIoczjlEI8BJlC75zePKOjq7qW53RuFU APc+Q3qMDXZxf0aHQOeK5uoIeAdCjiuOrYJtpajhu0m4qwfCj3Rl9L/9DnaxCSyRbmUq OK0BWCsxbI5U4NSQL2v1Bh3nNz7jQ3m0U0YVi6cm3NQ3Eq5PepbhdEhjKKZVVQTCI1wR BeCA== X-Gm-Message-State: APt69E111Z5yaABKB2AvtD79fnqs3p6qzUYqIwXyJy8BroDygGSDTekj ltPAf2gJv1XVSPd5CY+ervZT8vnyz6ne2EIMGyyDYQ== X-Google-Smtp-Source: AAOMgper5iC5ciWT5QSOvbIfNf6C6wptrj2+IxkwIumOQxfjmkMTjaAHuYnX5/TaPLQ3dJmbX3RViLPifzrbV9roP5Q= X-Received: by 2002:a2e:7815:: with SMTP id t21-v6mr9092751ljc.61.1531240479262; Tue, 10 Jul 2018 09:34:39 -0700 (PDT) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Tue, 10 Jul 2018 09:34:38 -0700 From: Joe Abley Mime-Version: 1.0 (1.0) References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> In-Reply-To: Date: Tue, 10 Jul 2018 09:34:38 -0700 Message-ID: To: Adam Roach Cc: DoH WG , driu@ietf.org, Philip Homburg , dnsop@ietf.org, Patrick McManus , Paul Wouters , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 16:34:44 -0000 On Jul 10, 2018, at 17:22, Adam Roach wrote: > Basically, you're describing a solution space that could be realized as s= omething like: > > Ok, interesting. I would suggest considering a richer scheme that accommodates address families and multiple addresses with priorities, but I see how that kind of thing would allow a client to do so certificate matching and resource retrieval without using the DNS. > But this is really equivalent in just about every important way to sendin= g the normal along with a pushe= d DNS record that indicates that "example.com" resolves to "192.0.2.1" -- a= nd this latter thing is (to my understanding, at least) in scope of the con= versation that Patrick is proposing to have. My question is why you would involve the DNS at all if all the performance-based resolution decisions can be made without it. You're just adding cost and complexity without benefit. > Note: I'm not saying anything about the trust issues that arise in either= case, and I'm not trying to gloss over the need to perform a really carefu= l analysis; Likewise. However, I think DNS protocol advice is probably more useful as input to the analysis if it's clear that the DNS is necessarily involved. Joe From nobody Tue Jul 10 09:42:31 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1557A131016 for ; Tue, 10 Jul 2018 09:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-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=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 5G3GM9oX1P4D for ; Tue, 10 Jul 2018 09:42:27 -0700 (PDT) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E25C12F1A5 for ; Tue, 10 Jul 2018 09:42:27 -0700 (PDT) Received: by mail-it0-x22d.google.com with SMTP id v71-v6so21708364itb.3 for ; Tue, 10 Jul 2018 09:42:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=68SDTK5YT/MU8mHuyvullKIGlLi4GxVmx9CuRJwFs9w=; b=FKty7O+cCbpyj1DKFWSyHK1r4ThoGd5ivfSPOkt6uwmZkjIviLF7EOCMe5UKH6aTke 6LLahAaev8zV+dlu8HNcxuHnGXVqNptOPuBeSBMtvOwF1W9tQc7ffDR7ZPYqX1Rk0c8r JYCnUn/+B3wjB6WtkBg1yLeindRi0ilp57mXWsnDk2fwi1/1H4rrXJNPAFktMVcpI6Nw fpuXZUNx7cCAhWrcX9+weRTEhQra6F42j65x1lsPtp4Pquf1EAvpcnACVNqMyZ8JaoLh BoJ7mloXe/CywbUZk9nF1rub/C921URHKUNoNBAqEGjCXnFkuppLlJY/sLhyKdUpckHc S+pA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=68SDTK5YT/MU8mHuyvullKIGlLi4GxVmx9CuRJwFs9w=; b=JAnbAhM22VeIZ2D2C7Kl2+iXrmH0DZZ9uvdZEuOnQlG4c08tphwLBr89OZRxQ+NNG9 m69j4f5iteNvxrNqnoVD6zwSlUQFP7jVvcq6usDKjHMykMpsDkn+nXx7H/yU74PPtIPT J/uS5wKu6UU5sIXi742SMXDceUkpAHojnbt8btSNuRfSMfakr7jm3whkGRwrBSnWLHuN 8CU38iCHlRsqihyf9DtFUKsKN8K2bLM2DsAzslLasv0As55967U3d8HgEaJscKzmPtIV yszKHd5yK0VcZbMvLvHtEFXJAycrtoXqjt3EmEsY/4M127XVJmg/VxeZgh5UPAkO3V9S F19w== X-Gm-Message-State: APt69E32c9Hja9yQGj0gFrAZP47uqB1TxNPNb7PKhsgcCp/FAhKZ1oDM rXDbdWD9IU+9QOz5KVGWeqLb+2TAq4PM/7XPXYhxoA== X-Google-Smtp-Source: AAOMgpf6z3DMBuvAVT7AYW1h39XcgfMKTCLyVLRWu/yNjkIqd4kv/r72Hw65iKKmpzN/HFMrBVLWRZvx42eTrv997qY= X-Received: by 2002:a02:b70b:: with SMTP id g11-v6mr21785562jam.34.1531240946430; Tue, 10 Jul 2018 09:42:26 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 09:41:46 -0700 (PDT) In-Reply-To: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Ted Lemon Date: Tue, 10 Jul 2018 12:41:46 -0400 Message-ID: To: Joe Abley Cc: Adam Roach , DoH WG , driu@ietf.org, dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000ad820b0570a7d050" Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 16:42:30 -0000 --000000000000ad820b0570a7d050 Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley wrote: > > But this is really equivalent in just about every important way to > sending the normal along with a > pushed DNS record that indicates that "example.com" resolves to > "192.0.2.1" -- and this latter thing is (to my understanding, at least) in > scope of the conversation that Patrick is proposing to have. > > My question is why you would involve the DNS at all if all the > performance-based resolution decisions can be made without it. You're > just adding cost and complexity without benefit The ip= modifier would be a great way to arrange for something to look like it came from a different source than its actual source. I'm sure there's an attack surface in there somewhere. --000000000000ad820b0570a7d050 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <jabley@hopc= ount.ca> wrote:
> But this i= s really equivalent in just about every important way to sending the normal= <img src=3D"https://example.com/img/f.jpg"> a= long with a pushed DNS record that indicates that "example.com" reso= lves to "192.0.2.1" -- and this latter thing is (to my understand= ing, at least) in scope of the conversation that Patrick is proposing to ha= ve.

My question is why you would involve the DNS at all if all the
performance-based resolution decisions can be made without it. You're just adding cost and complexity without benefit

=
The ip=3D modifier would be a great way to arrange for something to lo= ok like it came from a different source than its actual source. =C2=A0 I= 9;m sure there's an attack surface in there somewhere.
--000000000000ad820b0570a7d050-- From nobody Tue Jul 10 09:47:56 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB235131127 for ; Tue, 10 Jul 2018 09:47:41 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=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=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 a_VouCZDr5hy for ; Tue, 10 Jul 2018 09:47:40 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC48D131032 for ; Tue, 10 Jul 2018 09:47:37 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id b22-v6so6453832lfa.3 for ; Tue, 10 Jul 2018 09:47:37 -0700 (PDT) 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=6J6A+vP8PvPMWUyi3RHqDp0tRbsGRA+uorGsYvr/7TQ=; b=Frs75OXH1NAlA6UwE4eOCBrXm2WCxt7LVaPzbyscQVJUZH6aZGlXxODzbsB3wfUvJv GOsoKL1Kr5O62HtTa7BUaoWj2nQzB6RJqSLE0lfwbz0a6go9RJK40WinWOnDltnvzn+g LrORxDlHM4IxDBguur9691e3d+MKRIemskU9c= 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=6J6A+vP8PvPMWUyi3RHqDp0tRbsGRA+uorGsYvr/7TQ=; b=TUPty2J0f1xvUL4odMwh43FAhT3ZIw3792nE8H3qDca3P6hxEVtOxxTAd6JzUr5k66 ZlFUvP+klM1ChuaKyt6FKNb4CpGqGBARU6vdWijQ+bj/+5etLsTFZ/9clIZxIhEkO4IS ohb0aTFV71xaWewjRJcWkaSwrkj0EEhCvHKXil3je6TUMnhh4mhHnSY97RxlvUFEjemz khhFFkuLBfkMDcXwZv75JJ49MXvdOYit8ed+AxmG7u6F21rv0OMtkLnP9q/1/sfuu4KG xPi73UWN6+QHSJYWLGl4dCbXIvcoWz2c08WLGSueo6s4vr3jAO6Ug2HZaAFqsZaNNApT oQGg== X-Gm-Message-State: APt69E3MAcduR+ojxuv0TugpsvX/5K6EKWJGrMO1C/iXTEDnUTxThTqU IZtTyPj348ut/HGpQK1JPACXdAecO9eeIv9bdejMIA== X-Google-Smtp-Source: AAOMgpeX/jNQLA9S56MDTer5E/vlgm/Fubh4P0D2suiKOXjLvP/i4zyXAQwL5gEqzwq0qERS17kAVb4BcZe/kI1Xpe4= X-Received: by 2002:a19:1f4b:: with SMTP id f72-v6mr3314407lff.42.1531241256022; Tue, 10 Jul 2018 09:47:36 -0700 (PDT) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Tue, 10 Jul 2018 09:47:35 -0700 From: Joe Abley Mime-Version: 1.0 (1.0) References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> In-Reply-To: Date: Tue, 10 Jul 2018 09:47:35 -0700 Message-ID: To: Ted Lemon Cc: Adam Roach , DoH WG , driu@ietf.org, dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group Content-Type: multipart/alternative; boundary="00000000000021bd490570a7e349" Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 16:47:47 -0000 --00000000000021bd490570a7e349 Content-Type: text/plain; charset="UTF-8" On Jul 10, 2018, at 17:41, Ted Lemon wrote: On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley wrote: > > But this is really equivalent in just about every important way to > sending the normal along with a > pushed DNS record that indicates that "example.com" resolves to > "192.0.2.1" -- and this latter thing is (to my understanding, at least) in > scope of the conversation that Patrick is proposing to have. > > My question is why you would involve the DNS at all if all the > performance-based resolution decisions can be made without it. You're > just adding cost and complexity without benefit The ip= modifier would be a great way to arrange for something to look like it came from a different source than its actual source. I'm sure there's an attack surface in there somewhere. I'm haven't thought hard enough to say what vulnerability that would enable that wasn't already there using unsigned zones (because enterprise DNS tricks or some other reason) but you're probably right. Joe --00000000000021bd490570a7e349 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Jul 10, 2018, at 17:= 41, Ted Lemon <mellon@fugue.com&= gt; wrote:

On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <jabley@hopcount.ca&g= t; wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">> But this is really equi= valent in just about every important way to sending the normal <img src= =3D"https://example.com/img/f.jpg"> along with a = pushed DNS record that indicates that "example.com" resolves to &quo= t;192.0.2.1" -- and this latter thing is (to my understanding, at leas= t) in scope of the conversation that Patrick is proposing to have.

My question is why you would involve the DNS at all if all the
performance-based resolution decisions can be made without it. You're just adding cost and complexity without benefit

=
The ip=3D modifier would be a great way to arrange for something to lo= ok like it came from a different source than its actual source. =C2=A0 I= 9;m sure there's an attack surface in there somewhere.

I'm haven't thought hard enough to say = what vulnerability that would enable that wasn't already there using un= signed zones (because enterprise DNS tricks or some other reason) but you&#= 39;re probably right.


Joe
--00000000000021bd490570a7e349-- From nobody Tue Jul 10 10:03:32 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B39B813114C; Tue, 10 Jul 2018 10:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 JtihJTA2fqCQ; Tue, 10 Jul 2018 10:03:24 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17FD8131142; Tue, 10 Jul 2018 10:03:23 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AH2tmL004330 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 12:02:56 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Joe Abley Cc: DoH WG , driu@ietf.org, Philip Homburg , dnsop@ietf.org, Patrick McManus , Paul Wouters , HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Adam Roach Message-ID: Date: Tue, 10 Jul 2018 12:02:55 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:03:26 -0000 On 7/10/18 11:34 AM, Joe Abley wrote: > On Jul 10, 2018, at 17:22, Adam Roach wrote: > >> Basically, you're describing a solution space that could be realized as something like: >> >> > Ok, interesting. I would suggest considering a richer scheme that > accommodates address families and multiple addresses with priorities, > but I see how that kind of thing would allow a client to do so > certificate matching and resource retrieval without using the DNS. > >> But this is really equivalent in just about every important way to sending the normal along with a pushed DNS record that indicates that "example.com" resolves to "192.0.2.1" -- and this latter thing is (to my understanding, at least) in scope of the conversation that Patrick is proposing to have. > My question is why you would involve the DNS at all if all the > performance-based resolution decisions can be made without it. You're > just adding cost and complexity without benefit. In large part because DNS provides "a richer scheme that accommodates address families and multiple addresses with priorities". /a From nobody Tue Jul 10 10:06:21 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C3E0131142; Tue, 10 Jul 2018 10:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.878 X-Spam-Level: X-Spam-Status: No, score=-1.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 BbMY-Hgud_Ve; Tue, 10 Jul 2018 10:06:13 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89A6C13113E; Tue, 10 Jul 2018 10:06:13 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AH5jek004872 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 12:05:46 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Ted Lemon , Joe Abley Cc: DoH WG , driu@ietf.org, dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Adam Roach Message-ID: <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> Date: Tue, 10 Jul 2018 12:05:45 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BCF78CA0739BD930ABF88DE6" Content-Language: en-US Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:06:16 -0000 This is a multi-part message in MIME format. --------------BCF78CA0739BD930ABF88DE6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 7/10/18 11:41 AM, Ted Lemon wrote: > On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley > wrote: > > > But this is really equivalent in just about every important way to sending the normal src="https://example.com/img/f.jpg > "> along with a pushed DNS record > that indicates that "example.com " resolves to > "192.0.2.1" -- and this latter thing is (to my understanding, at > least) in scope of the conversation that Patrick is proposing to have. > > My question is why you would involve the DNS at all if all the > performance-based resolution decisions can be made without it. You're > just adding cost and complexity without benefit > > > The ip= modifier would be a great way to arrange for something to look > like it came from a different source than its actual source.   I'm > sure there's an attack surface in there somewhere. Keeping in mind that the certificate provided by whatever machine you reached would necessarily have to match the URL's origin, this is very much one of the questions that is being asked: is there? /a --------------BCF78CA0739BD930ABF88DE6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 7/10/18 11:41 AM, Ted Lemon wrote:
On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <jabley@hopcount.ca> wrote:
> But this is really equivalent in just about every important way to sending the normal <img src="https://example.com/img/f.jpg"> along with a pushed DNS record that indicates that "example.com" resolves to "192.0.2.1" -- and this latter thing is (to my understanding, at least) in scope of the conversation that Patrick is proposing to have.

My question is why you would involve the DNS at all if all the
performance-based resolution decisions can be made without it. You're
just adding cost and complexity without benefit

The ip= modifier would be a great way to arrange for something to look like it came from a different source than its actual source.   I'm sure there's an attack surface in there somewhere.


Keeping in mind that the certificate provided by whatever machine you reached would necessarily have to match the URL's origin, this is very much one of the questions that is being asked: is there?

/a

--------------BCF78CA0739BD930ABF88DE6-- From nobody Tue Jul 10 10:10:40 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B446131179 for ; Tue, 10 Jul 2018 10:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 3RRkZL1Dubdy for ; Tue, 10 Jul 2018 10:10:29 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E464131169 for ; Tue, 10 Jul 2018 10:10:29 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id v71-v6so21834081itb.3 for ; Tue, 10 Jul 2018 10:10:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RtdV3HVCVufDVCnq++2dHOceaWsMe1UFGNtOa00Lwjo=; b=jR5z/QXcPGTwzEoYnfKa8G6/yrPQ+SSA3mef+XV+mpfpnx8PSd1j0fxQjDtQc/jybT 9RskP7jjfTegFE4dPnmLiABjEqQndSfw0+NORmuU+OkeR3/49MdR9KGw2Rhfg7ZMjtpU TU7QDL1AVyxLJDiN2GTChqHM8M/TGfAu7K+ye18A983a7uZ93xg3UWATCxrZI6ikbSbi VCLczQjCT7/AeqUQYt8Tb7Hd8CTkmTINACM1r2l8zoLEHLHS3DcuErTJN1t73vjfw5pv F/72XkpISorNw9o/150/dsw5ef0wZHxz1yJ3rly8NxRf/7wir0bOiGURzfuB+eqyEurX +1qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RtdV3HVCVufDVCnq++2dHOceaWsMe1UFGNtOa00Lwjo=; b=EoQJYrcIRaBKY1hk1+T44+KkUxgOncpG1/611rPu7t09ZejQhfK5h/+zC3hUktGMsf qk9TZgRtIwVJDihKRNpsc7+PYCVjAFfKd/0tmNXlj6uWCdgA5AUvft55D5CngL0mhcxc bm80pGdB+rsxkt06HtEJ7ESpllS2A9+PZ2UkamO3+DjVzrEaOHm05Y5jGWMPI+1hZ1V6 YFQO7aXWaBsGJ8IPSviaIMYkU3rje+syn36Shv/tVnGcGfyWWaVwSxf/urcwIDul0sra N0oZwqqZ/6V8IY2id7Mlg+KIt6MkNDAu8laq8MuCO6R4R5MmqxLw0Eji3rTMoRUSdwhe Gz0Q== X-Gm-Message-State: APt69E3PRVeRoehrLBt5cWhksgR+i3TXvXkwAF6+F88TfOlH5f26qQku 1INuSgVl/6wHj3cjA2zzYNspBU77lAOoziDbNEJaJw== X-Google-Smtp-Source: AAOMgpdDByd6uGTOUoX5d/reHjvZIEsm+EVeQMfGHbScTDQ/wEgRolu9bVFgmCFJMCLSfsIhbM+6unYR0t3u30ScJxs= X-Received: by 2002:a02:4c9b:: with SMTP id q27-v6mr20659576jad.38.1531242628657; Tue, 10 Jul 2018 10:10:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:5f86:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 10:09:47 -0700 (PDT) In-Reply-To: <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> From: Ted Lemon Date: Tue, 10 Jul 2018 13:09:47 -0400 Message-ID: To: Adam Roach Cc: Joe Abley , DoH WG , driu@ietf.org, dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000f248aa0570a83488" Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:10:33 -0000 --000000000000f248aa0570a83488 Content-Type: text/plain; charset="UTF-8" I'm not suggesting that the attack surfaces couldn't be closed, and that does seem like it would be sufficient to close them. However, we've been burned by implementations not getting details like this right in the past, so that's why I brought it up. On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach wrote: > On 7/10/18 11:41 AM, Ted Lemon wrote: > > On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley wrote: > >> > But this is really equivalent in just about every important way to >> sending the normal along with >> a pushed DNS record that indicates that "example.com" resolves to >> "192.0.2.1" -- and this latter thing is (to my understanding, at least) in >> scope of the conversation that Patrick is proposing to have. >> >> My question is why you would involve the DNS at all if all the >> performance-based resolution decisions can be made without it. You're >> just adding cost and complexity without benefit > > > The ip= modifier would be a great way to arrange for something to look > like it came from a different source than its actual source. I'm sure > there's an attack surface in there somewhere. > > > Keeping in mind that the certificate provided by whatever machine you > reached would necessarily have to match the URL's origin, this is very much > one of the questions that is being asked: is there? > > /a > --000000000000f248aa0570a83488 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not suggesting that the attack surfaces couldn'= ;t be closed, and that does seem like it would be sufficient to close them.= =C2=A0 However, we've been burned by implementations not getting detai= ls like this right in the past, so that's why I brought it up.

On Tue, Jul 10, 2018= at 1:05 PM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 7/10/18 11:41 AM= , Ted Lemon wrote:
=20
On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley <jable= y@hopcount.ca> wrote:
> But this is really eq= uivalent in just about every important way to sending the normal <img src=3D"https://example.com/img/f.jpg&qu= ot;> along with a pushed DNS record that indicates that "example.c= om" resolves to "192.0.2.1" -- and this latter thing = is (to my understanding, at least) in scope of the conversation that Patrick is proposing to have.

My question is why you would involve the DNS at all if all the
performance-based resolution decisions can be made without it. You're
just adding cost and complexity without benefit

The ip=3D modifier would be a great way to arrange for something to look like it came from a different source than its actual source. =C2=A0 I'm sure there's an at= tack surface in there somewhere.


Keeping in mind that the certificate provided by whateve= r machine you reached would necessarily have to match the URL's origin, thi= s is very much one of the questions that is being asked: is there?

<= span class=3D"HOEnZb">

/a


--000000000000f248aa0570a83488-- From nobody Tue Jul 10 10:11:07 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 410251311B5; Tue, 10 Jul 2018 10:10:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 pd5Yo_xuezKc; Tue, 10 Jul 2018 10:10:38 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id B2C141311A6; Tue, 10 Jul 2018 10:10:38 -0700 (PDT) Received: from mail-oi0-f52.google.com (mail-oi0-f52.google.com [209.85.218.52]) by linode64.ducksong.com (Postfix) with ESMTPSA id 4E69C3A054; Tue, 10 Jul 2018 13:10:37 -0400 (EDT) Received: by mail-oi0-f52.google.com with SMTP id d189-v6so44008009oib.6; Tue, 10 Jul 2018 10:10:37 -0700 (PDT) X-Gm-Message-State: APt69E29hbkmQI8u8jt2VFu4z4O+anGFmOOEhMjFQOjSgFbrQInGRwWw NPFIheEuiGiS1o2+9we0/Rno5hvYHmV+9yBHCsw= X-Google-Smtp-Source: AAOMgpetPYvarAgMzytWSOGAzaYS4w4G0+9dAmWlEbTDFFifAbCRgeBtQrxk5XkXV6rFIFYv5O4h6SD/TywJVVVDKhQ= X-Received: by 2002:aca:5f0a:: with SMTP id t10-v6mr12880476oib.337.1531242637005; Tue, 10 Jul 2018 10:10:37 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 10:10:36 -0700 (PDT) In-Reply-To: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Patrick McManus Date: Tue, 10 Jul 2018 11:10:36 -0600 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: Joe Abley , DoH WG , driu@ietf.org, Philip Homburg , dnsop , Patrick McManus , Paul Wouters , HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000007199da0570a835c8" Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:10:52 -0000 --0000000000007199da0570a835c8 Content-Type: text/plain; charset="UTF-8" yes; and.. dns has always provided a point of indirection that is useful. dynamically rewriting markup might be infeasible.. and many fetch() like things are driven from script where the markup changes are not obvious or perhaps ill fitting.. and of course there are questions of cached content that might like to late bind. so lots to think about; but the markup example is very illustrative of a very conservative way of scoping things. perhaps too conservative. worth exploring. On Tue, Jul 10, 2018 at 11:02 AM, Adam Roach wrote: > On 7/10/18 11:34 AM, Joe Abley wrote: > >> On Jul 10, 2018, at 17:22, Adam Roach wrote: >> >> Basically, you're describing a solution space that could be realized as >>> something like: >>> >>> >>> >> Ok, interesting. I would suggest considering a richer scheme that >> accommodates address families and multiple addresses with priorities, >> but I see how that kind of thing would allow a client to do so >> certificate matching and resource retrieval without using the DNS. >> >> But this is really equivalent in just about every important way to >>> sending the normal along with >>> a pushed DNS record that indicates that "example.com" resolves to >>> "192.0.2.1" -- and this latter thing is (to my understanding, at least) in >>> scope of the conversation that Patrick is proposing to have. >>> >> My question is why you would involve the DNS at all if all the >> performance-based resolution decisions can be made without it. You're >> just adding cost and complexity without benefit. >> > > In large part because DNS provides "a richer scheme that accommodates > address families and multiple addresses with priorities". > > > /a > --0000000000007199da0570a835c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
yes; and.. dns has always provided a point of indirec= tion that is useful. dynamically rewriting markup might be infeasible.. and= many fetch() like things are driven from script where the markup changes a= re not obvious or perhaps ill fitting.. and of course there are questions o= f cached content that might like to late bind. so lots to think about; but = the markup example is very illustrative of a very conservative way of scopi= ng things. perhaps too conservative. worth exploring.

On Tue, Jul 10, 2018 at= 11:02 AM, Adam Roach <adam@nostrum.com> wrote:
On 7/10/18 11:34 AM, Joe Abley wrote:=
On Jul 10, 2018, at 17:22, Adam Roach <adam@nostrum.com> wrote:

Basically, you're describing a solution space that could be realized as= something like:

<img src=3D"https://example.com/img/f.jpg" ip=3D&= quot;192.0.2.1">
Ok, interesting. I would suggest considering a richer scheme that
accommodates address families and multiple addresses with priorities,
but I see how that kind of thing would allow a client to do so
certificate matching and resource retrieval without using the DNS.

But this is really equivalent in just about every important way to sending = the normal <img src=3D"https://example.com/img/f.jpg&q= uot;> along with a pushed DNS record that indicates that "example.com" resolves to "192.0.2.1" -- and this latter thing is (to m= y understanding, at least) in scope of the conversation that Patrick is pro= posing to have.
My question is why you would involve the DNS at all if all the
performance-based resolution decisions can be made without it. You're just adding cost and complexity without benefit.

 In large part because DNS provides "a richer scheme that accommodates = address families and multiple addresses with priorities".


/a

--0000000000007199da0570a835c8-- From nobody Tue Jul 10 10:32:37 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB97D131194; Tue, 10 Jul 2018 10:32:22 -0700 (PDT) X-Quarantine-ID: <9TF0ePKQLBHg> X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc" X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9TF0ePKQLBHg; Tue, 10 Jul 2018 10:32:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (stereo6-tun.hq.phicoh.net [IPv6:2001:888:1044:10:2a0:c9ff:fe9f:17a9]) (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 4DE37131188; Tue, 10 Jul 2018 10:32:20 -0700 (PDT) Received: from stereo.hq.phicoh.net (localhost [::ffff:127.0.0.1]) by stereo.hq.phicoh.net with esmtp (TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384) (Smail #157) id m1fcwUq-0000GvC; Tue, 10 Jul 2018 19:32:16 +0200 Message-Id: To: dnsop@ietf.org Cc: Ted Lemon Cc: DoH WG , driu@ietf.org, HTTP Working Group From: Philip Homburg Sender: pch-bCE2691D2@u-1.phicoh.com References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> In-reply-to: Your message of "Tue, 10 Jul 2018 12:41:46 -0400 ." Date: Tue, 10 Jul 2018 19:32:15 +0200 Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:32:24 -0000 >The ip= modifier would be a great way to arrange for something to look like >it came from a different source than its actual source. I'm sure there's >an attack surface in there somewhere. That's a rather fundamental issue. In the context of TLS, and a DNSSEC insecure zone, there are two realistic attack scenarios: - an attack on DNS that returns different addresses for a DNS lookup - a routing attack, that reroutes traffic. Both types of attacks are realistic and happen quite frequently. If we decide that TLS is strong enough to defend against these attacks, then there is no need to secure the DNS lookup, other than to reduce the risk of denial of service and for privacy reasons. Then such an ip= modifier would be fine, because the worst thing that can happen is denial of service. On the other hand, if we don't trust TLS, then we have a bit of a problem. Too many people using public resolvers. Route hijacks are quite easy, etc. From nobody Tue Jul 10 10:49:26 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754F5130F04; Tue, 10 Jul 2018 10:49:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 xOGYiv7ez31c; Tue, 10 Jul 2018 10:49:12 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E836B130E25; Tue, 10 Jul 2018 10:49:11 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AHn3N8012043 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 12:49:05 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Philip Homburg , dnsop@ietf.org Cc: DoH WG , Ted Lemon , driu@ietf.org, HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Adam Roach Message-ID: <711c1727-eb43-c90a-60ab-fa3580786c1d@nostrum.com> Date: Tue, 10 Jul 2018 12:49:03 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:49:14 -0000 On 7/10/18 12:32 PM, Philip Homburg wrote: > If we decide that TLS is strong enough to defend against these attacks, > then there is no need to secure the DNS lookup, other than to reduce > the risk of denial of service and for privacy reasons. Then such an ip= > modifier would be fine, because the worst thing that can happen is denial > of service. To be crystal clear, my mentioning of that hypothetical parameter was part of a thought experiment, not a proposal. /a From nobody Tue Jul 10 10:55:36 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 585AC13119F for ; Tue, 10 Jul 2018 10:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, UNPARSEABLE_RELAY=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=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 pjgWHjkFlgbn for ; Tue, 10 Jul 2018 10:55:16 -0700 (PDT) Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55E351311A3 for ; Tue, 10 Jul 2018 10:55:15 -0700 (PDT) Received: by mail-lf0-x22d.google.com with SMTP id u202-v6so19045224lff.9 for ; Tue, 10 Jul 2018 10:55:15 -0700 (PDT) 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=sF4IEOEnumrGo/yi2tqGj8F3dwK+tpMgwcqiDCKJKl4=; b=EljV0CzUdU62DwwA/LkkGrNLyDMgjvmg4JksfnuJDyYZ6d7gIsqpdC5N5KpqRVKAX2 wN2trsSDJYeA7GkMXC2mkw0bS37Ek+D+HCrsKYn25N27d0kQ7CSG2jb//ozbFYvK9Aen o4gMXQYb4OPo520J9mlRC2KgBqcZRfdETNBW4= 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=sF4IEOEnumrGo/yi2tqGj8F3dwK+tpMgwcqiDCKJKl4=; b=LZFp7W0BzJQfPHC6X23WJV+enGx0c1b7gvFBkX7600l+umZCyd24T+dc9ef2vT97wB a+Y1KHFUjbW1yJjjGHSitFq9LMvT71BIf8eDzR+Mcm/fBuyIxliL6j8YDQBIEBIrRcFD ydxBBC2nBnnQh5l9tVonDycFbg2L/MhTZVqOPfvIhavkotQJ5pK5GIXYhF/Su7iMP9lX fDtPNobsoqFAnD0XjSeNrHdnXk1pkY6YL3TL0Ht1f0rbViH2YN2r8oMZTilOJjltvBCp DSH2I76tVfinCrjvQ9KZms6Mf8ozm4Dug6RpAjhKENOgfyDlBpK4Dsnqyohc3ninroeg SRsQ== X-Gm-Message-State: APt69E2hY9lFDI/JYeBGVr+5UMqeWmoRYzCYpBo8pAs0fsYAl0nNTcaM rceR/g3XVjLk09SfpWFHxSgdjvzxagdlQ5ttr5UlWg== X-Google-Smtp-Source: AAOMgpf/9DI2sFOajwIAFlN0P4GAjsxAICfwuN8MqrD5JceBfw+f0+VnTTE8sVDIZrhSDgEcFyGi83OGdBtyG5OqTOo= X-Received: by 2002:a19:dd5c:: with SMTP id u89-v6mr3433424lfg.83.1531245313554; Tue, 10 Jul 2018 10:55:13 -0700 (PDT) Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Tue, 10 Jul 2018 10:55:12 -0700 From: Joe Abley Mime-Version: 1.0 (1.0) References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> In-Reply-To: Date: Tue, 10 Jul 2018 10:55:12 -0700 Message-ID: To: Adam Roach Cc: DoH WG , driu@ietf.org, Philip Homburg , dnsop@ietf.org, Patrick McManus , Paul Wouters , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:55:30 -0000 On Jul 10, 2018, at 18:02, Adam Roach wrote: > In large part because DNS provides "a richer scheme that accommodates address families and multiple addresses with priorities". *cups hand to ear* Was that the sound of a distant desire to specify use of SRV for HTTP? Joe From nobody Tue Jul 10 11:04:37 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7A21130DCE; Tue, 10 Jul 2018 11:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.879 X-Spam-Level: X-Spam-Status: No, score=-1.879 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, 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 EUDVnpcX1F59; Tue, 10 Jul 2018 11:04:29 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C4E8130EAA; Tue, 10 Jul 2018 11:04:29 -0700 (PDT) Received: from Svantevit.roach.at (cpe-70-122-154-80.tx.res.rr.com [70.122.154.80]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w6AI3sKm014543 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 10 Jul 2018 13:03:55 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-154-80.tx.res.rr.com [70.122.154.80] claimed to be Svantevit.roach.at To: Joe Abley Cc: DoH WG , driu@ietf.org, Philip Homburg , dnsop@ietf.org, Patrick McManus , Paul Wouters , HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: Adam Roach Message-ID: <3c8fd080-7f67-0e3c-7754-6bba99593873@nostrum.com> Date: Tue, 10 Jul 2018 13:03:54 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:04:33 -0000 On 7/10/18 12:55 PM, Joe Abley wrote: > On Jul 10, 2018, at 18:02, Adam Roach wrote: > >> In large part because DNS provides "a richer scheme that accommodates address families and multiple addresses with priorities". > *cups hand to ear* > > Was that the sound of a distant desire to specify use of SRV for HTTP? > Speaking personally (that is: this position may be at odds with any number of organizations I'm affiliated with), I've been sad for a very long time that SRV didn't take off as the entry point for doing all name/service resolution. Maintaining a service-to-port map in 2018 seems as quaint as if we were still having to manually set and de-conflict IRQ values on PC peripherals. This is way off-topic, though -- if you want to continue, find another venue and let me know (or we can find a time to commiserate over beers in Montreal if you prefer). /a From nobody Tue Jul 10 11:06:49 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1E51311AC; Tue, 10 Jul 2018 11:06:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UqvW2mI-7258; Tue, 10 Jul 2018 11:06:33 -0700 (PDT) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 383F3131197; Tue, 10 Jul 2018 11:06:28 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 41Q9BB1sRdzDxn; Tue, 10 Jul 2018 20:06:26 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1531245986; bh=ipe99PE1mtID2UiBeg7F2q4Oe/TvNf1WQj5tJNMExN8=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=b8Ag6jaxNY7S5SKl/3F1mGlD49olR02jzRGr90iIUfU/0PC8slGwA23DKFsD2X+5O 3zL3ztjvVc6RT4enU2a0avgFUJ+EEul938BqyOwjYdLe+NSJ4b/rrLlkR+/xP5ovEi 4Jn9iMw1FsJocI2fjECnj2tDeIwguzAN6OrmCGnk= 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 Z1WHnhGjpDV8; Tue, 10 Jul 2018 20:06:25 +0200 (CEST) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 10 Jul 2018 20:06:24 +0200 (CEST) Received: by bofh.nohats.ca (Postfix, from userid 1000) id F3A6941853B; Tue, 10 Jul 2018 14:06:22 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca F3A6941853B Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id EECCA40008AB; Tue, 10 Jul 2018 14:06:22 -0400 (EDT) Date: Tue, 10 Jul 2018 14:06:22 -0400 (EDT) From: Paul Wouters To: Ryan Sleevi cc: DoH WG , driu@ietf.org, dnsop WG , HTTP Working Group In-Reply-To: Message-ID: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> User-Agent: Alpine 2.21 (LRH 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:06:46 -0000 On Tue, 10 Jul 2018, Ryan Sleevi wrote: > That's why involving DNS is at least relevant to that discussion, especially given that publicly trusted certificates are themselves predicated on DNS. Further, > considering that the CA only has to validate a DNS once per 825-day period, and can issue unlimited 825-day certificates during that period, then the effective > extension of relying solely on certificates 1650 days minus a second.  This of course, is only an argument in favour of DANE depricating WebPKI, especially in light of the EV failures reducing webpki to only DNS already :) Paul > From nobody Tue Jul 10 11:07:12 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDE4130E2A; Tue, 10 Jul 2018 10:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_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 ijkJQZp9F8T7; Tue, 10 Jul 2018 10:43:40 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E600E130E25; Tue, 10 Jul 2018 10:43:39 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 475DB47A1C; Tue, 10 Jul 2018 13:43:38 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23364.61514.267429.409048@gro.dd.org> Date: Tue, 10 Jul 2018 13:43:38 -0400 From: Dave Lawrence To: Paul Vixie Cc: Patrick McManus , DoH WG , driu@ietf.org, Ben Schwartz , dnsop , HTTP Working Group , Daniel Kahn Gillmor In-Reply-To: <5B447154.5010307@redbarn.org> References: <5B447154.5010307@redbarn.org> Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 11:07:08 -0700 Subject: Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:43:42 -0000 Paul Vixie writes: > > For example www.example.com pushes you a AAAA > > record for img1.example.com . Should you use > > it? > > no. sibling names might be delegation points. kashpureff taught us this > in 1996 or so, and kaminsky reinforced that lesson in 2008. > > > What if it is for img1.img-example.com ? > > certainly not. In the large I agree with you, but I think there's more to it than that. If it pushed me DNSSEC records that I could verify myself from my own configured trust anchor, why can't I trust them then? From nobody Tue Jul 10 11:07:19 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2C13131017; Tue, 10 Jul 2018 10:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 Pf7cJMXCejwn; Tue, 10 Jul 2018 10:51:57 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E305B130F04; Tue, 10 Jul 2018 10:51:56 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 785576001608; Tue, 10 Jul 2018 10:51:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=RhhEoZ408ThwhoEVDri3uLd8KdA=; b= NcZ6oVC9iC0n/haNfPuiO056XcNWFnwSA1nBGp9uMDaxH3HDe3uK9SXCjXQPw2X+ QnfZ+PeRhmFI/nfLTKGNkw/rDFPz4jYXYnZKIyq4tpXNxYXomhQZ/8LCC9nN5toZ MdBDhm20eyjTavkTusJXb8v4JFPNslHTjiGuVwdaE3I= Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 533D16001602; Tue, 10 Jul 2018 10:51:55 -0700 (PDT) Received: by mail-it0-f42.google.com with SMTP id w16-v6so10403592ita.0; Tue, 10 Jul 2018 10:51:55 -0700 (PDT) X-Gm-Message-State: AOUpUlF0uDdKGztHj7e0ENyZG4abAUluV1xMFcLjpCeLvicrUV9tZx5P FzC/EZ05ulab+CvgvWbdelOMlgRIVtMA4zyohKk= X-Google-Smtp-Source: AAOMgpfuksUe3Ga9juzC5CUfobAyFAYv3gmOA6kuj2PLZqAxznoaKVgCcwYiLYtmDX0wdZMyFG3H8QfVpjwvaq4KoGE= X-Received: by 2002:a24:62d0:: with SMTP id d199-v6mr7502623itc.91.1531245114637; Tue, 10 Jul 2018 10:51:54 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:244:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 10:51:54 -0700 (PDT) In-Reply-To: <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> From: Ryan Sleevi Date: Tue, 10 Jul 2018 13:51:54 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Adam Roach Cc: Ted Lemon , Joe Abley , DoH WG , driu@ietf.org, dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000001f45cb0570a8c9ed" Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 11:07:07 -0700 Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:52:00 -0000 --0000000000001f45cb0570a8c9ed Content-Type: text/plain; charset="UTF-8" On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach wrote: > On 7/10/18 11:41 AM, Ted Lemon wrote: > > On Tue, Jul 10, 2018 at 12:34 PM, Joe Abley wrote: > >> > But this is really equivalent in just about every important way to >> sending the normal along with >> a pushed DNS record that indicates that "example.com" resolves to >> "192.0.2.1" -- and this latter thing is (to my understanding, at least) in >> scope of the conversation that Patrick is proposing to have. >> >> My question is why you would involve the DNS at all if all the >> performance-based resolution decisions can be made without it. You're >> just adding cost and complexity without benefit > > > The ip= modifier would be a great way to arrange for something to look > like it came from a different source than its actual source. I'm sure > there's an attack surface in there somewhere. > > > Keeping in mind that the certificate provided by whatever machine you > reached would necessarily have to match the URL's origin, this is very much > one of the questions that is being asked: is there? > > /a > Yes. Consider Site A (foo.example) and Site B (bar.example). Both point themselves to CDN 1, which then obtains a certificate for both their names in subjectAltNames. Site B then decides that CDN 1 is an unreliable partner, and goes CDN 2, updating DNS appropriately. This is the same problem in considering the HTTP/2 coalescing without doing DNS resolution (either because of poor security posture or by combining ORIGIN + Secondary Certificates). RFC 8336 briefly touches on this ( https://tools.ietf.org/html/rfc8336#section-4 ) but doesn't really explore the policy implications of the proposed or recommended mitigations. If you start with no mitigations, the net effect of both an ip= or a DNS-ignoring ORIGIN frame is to effectively treat the certificate as a 825-day DNS TTL. By framing the problem as "What's the worst that could happen if DNS entries had their TTLs ignored and were cached for 825 days", that might help explore things further. The suggestion of OCSP reduces that TTL to 7 days (effectively; due to Microsoft's contractual requirements on publicly trusted CAs), but that's still substantially longer. That's why involving DNS is at least relevant to that discussion, especially given that publicly trusted certificates are themselves predicated on DNS. Further, considering that the CA only has to validate a DNS once per 825-day period, and can issue unlimited 825-day certificates during that period, then the effective extension of relying solely on certificates 1650 days minus a second. --0000000000001f45cb0570a8c9ed Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 10, 2018 at 1:05 PM, Adam Roach <adam@nostrum.com> wrote:
=20 =20 =20
On 7/10/18 1= 1:41 AM, Ted Lemon wrote:
=20
On Tue, Jul 10, 2018 at 12:34= PM, Joe Abley <jabley@hopcount.ca> wrote:
> But this is really equivalent in just about every important way to sending the normal <img src=3D"https://example.com/img/f.jpg&qu= ot;> along with a pushed DNS record that indicates that "example.c= om" resolves to "192.0.2.1" -- and this latter thing = is (to my understanding, at least) in scope of the conversation that Patrick is proposing to have.

My question is why you w= ould involve the DNS at all if all the
performance-based resolution decisions can be made without it. You're
just adding cost and complexity without benefit

The ip=3D modifier would be a great way to arrange for something to look like it came from a different source than its actual source. =C2=A0 I'm sure there's an at= tack surface in there somewhere.


Keeping in mind that the certificate provided by whatever machine you reached would necessarily have to match the URL's origin, thi= s is very much one of the questions that is being asked: is there?

<= span class=3D"gmail-HOEnZb">

/a

Yes. Consider Site A (foo.example) and Site B (bar.examp= le). Both point themselves to CDN 1, which then obtains a certificate for b= oth their names in subjectAltNames. Site B then decides that CDN 1 is an un= reliable partner, and goes CDN 2, updating DNS appropriately.

This is the same pr= oblem in considering the HTTP/2 coalescing without doing DNS resolution (ei= ther because of poor security posture or by combining ORIGIN + Secondary Ce= rtificates). RFC 8336 briefly touches on this (=C2=A0https://tools.ietf.org/html/rfc8336#sec= tion-4 ) but doesn't really explore the policy implications of the = proposed or recommended mitigations.

If you start with no mitigations, the net ef= fect of both an ip=3D or a DNS-ignoring ORIGIN frame is to effectively trea= t the certificate as a 825-day DNS TTL. By framing the problem as "Wha= t's the worst that could happen if DNS entries had their TTLs ignored a= nd were cached for 825 days", that might help explore things further. = The suggestion of OCSP reduces that TTL to 7 days (effectively; due to Micr= osoft's contractual requirements on publicly trusted CAs), but that'= ;s still substantially longer.

That's why involving DNS is at least relevant = to that discussion, especially given that publicly trusted certificates are= themselves predicated on DNS. Further, considering that the CA only has to= validate a DNS once per 825-day period, and can issue unlimited 825-day ce= rtificates during that period, then the effective extension of relying sole= ly on certificates 1650 days minus a second.=C2=A0
--0000000000001f45cb0570a8c9ed-- From nobody Tue Jul 10 11:07:25 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDB90131127; Tue, 10 Jul 2018 10:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ClqI2j4IIiin; Tue, 10 Jul 2018 10:54:46 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D86130F04; Tue, 10 Jul 2018 10:54:46 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id A77A547A2B; Tue, 10 Jul 2018 13:54:45 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23364.62181.661312.974644@gro.dd.org> Date: Tue, 10 Jul 2018 13:54:45 -0400 From: Dave Lawrence To: Tim Wicinski Cc: Philip Homburg , driu@ietf.org, dnsop , DoH WG , HTTP Working Group , Patrick McManus In-Reply-To: References: Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 11:07:08 -0700 Subject: Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 17:54:49 -0000 Tim Wicinski writes: > "Are you trying to re-invent DNSSEC for people who don't want to deploy > DNSSEC?" > > My magic 8-ball says "signs point to Yes" I don't grok how y'all got "trying to re-invent DNSSEC" out of this, so this is sure to be an entertaining discussion. From nobody Tue Jul 10 11:08:37 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D947F131192; Tue, 10 Jul 2018 11:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 T_55XYLCj-aX; Tue, 10 Jul 2018 11:08:21 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B2C131184; Tue, 10 Jul 2018 11:08:21 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 7E7F447A42; Tue, 10 Jul 2018 14:08:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23364.62996.452097.286863@gro.dd.org> Date: Tue, 10 Jul 2018 14:08:20 -0400 From: Dave Lawrence To: Joe Abley Cc: Adam Roach , Paul Wouters , driu@ietf.org, dnsop@ietf.org, DoH WG , Patrick McManus , Philip Homburg , HTTP Working Group In-Reply-To: <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> Archived-At: Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:08:31 -0000 Joe Abley writes: >but collapsing the address selection back to the extent that you can > avoid name resolution at all seems like a better end goal. > > So rather than resolverless operation, think about resolutionless or > nameless, eliminating the DNS as unnecessary overhead. > > Perhaps I have misunderstood the whole problem space, of course :-) I believe you are spot-on. From nobody Tue Jul 10 11:11:16 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D7CD130EAA; Tue, 10 Jul 2018 11:11:08 -0700 (PDT) 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, 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 (2048-bit key) header.d=aclu.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 jS65edoFRZLQ; Tue, 10 Jul 2018 11:11:02 -0700 (PDT) Received: from dkim-ny.aclu.org (dkim-ny.aclu.org [38.109.115.175]) (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 D4345130DCE; Tue, 10 Jul 2018 11:11:01 -0700 (PDT) dkim-signature: v=1; a=rsa-sha256; d=aclu.org; s=hmailserver; c=relaxed/relaxed; q=dns/txt; h=From:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type:Content-Transfer-Encoding:In-Reply-To:References; bh=tLoYkAnIQGa8WxIRuDX37fx/3xBPYoWvVfFxtOfDW/I=; b=YyQzIdps+9s26TWujvtPnybpmjsk66qbj3D8GELCB6D43oTt43f2SvtIYOcBHk+KeZ+qQRfVV+3+UdRq4aH1ZaLTKS6IEkkK7xN2Yogbx9PrL0n1f9J+c0bRBHKEvuSoP1zHkTTOfUsfAt9fZTEfQvlNLxrSeI8uSNv16ltTPlHRHJxVEt3HAOj0RtCYbpIB1Qg/sdajN8QRY71Rijw4ggE0NJnufiyVvdxbdS3glRc1skjSzpK5TQ3h4H jSk/vYkn4+cfCIGwxiXlrv2G6KPN4r5Qc87UUwduCpTQAI/D9DcPcCVkxZsNUydNvHd4N6/eTm1SDyiFYCY8bnIekFgw== Received: from vtvsmtpout.vtv.aclu.org (nyvtv1s.vop.aclu.org [10.70.0.186]) by dkim-ny.aclu.org with ESMTPS (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256) ; Tue, 10 Jul 2018 14:10:50 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (localhost [127.0.0.1]) by nyvtv1.vop.aclu.org (Postfix) with ESMTPS id 958FE2E2B70; Tue, 10 Jul 2018 18:10:50 +0000 (UTC) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=dkgillmor@aclu.org; Received: from [127.0.0.1] (38.109.115.139) by BYAPR01MB3653.prod.exchangelabs.com (2603:10b6:a02:84::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.21; Tue, 10 Jul 2018 18:10:46 +0000 To: "Dave Lawrence" , "Paul Vixie" Cc: "Patrick McManus" , "DoH WG" , driu@ietf.org, "Ben Schwartz" , dnsop , HTTP Working Group References: <5B447154.5010307@redbarn.org> <23364.61514.267429.409048@gro.dd.org> From: "Daniel Kahn Gillmor" Openpgp: preference=signencrypt Autocrypt: addr=dkg@aclu.org; prefer-encrypt=mutual; keydata= mQINBEZhxjoBEACtXku9A/xHl58dAVmeiuPzFvB2K+8iqwDjEZRUH+1l8ZWG3Gb81uMsRPf5 PDJCJKRH0ATJYId3ynfdjxjOZC981OdbvRslX+pvIZOXMoK7nSzrvC7CYAyVRUDGikAK7YNj KDdRrQDzSwcuzQOm+BpabYcU7t0k7p/mD1t1P1yIio1WTA5HOlo5+I+rkWtwuIAJCVeIkZOY Lso2K8qY1Xy7VEdFXY+fltaeblEvLjJfOKkUnzEyeNfPAX0QwcGZuMrcBQiLj3KWNrKZNFf7 tzXC2wOVU7Vf0Xt7nuLppAKhHXMr5RbkBWOJFiaKtUqLBfMgfcIyRj3eIppMNgTcWQMcSLD+ L8eUW8MflPsZPnXG85z3an7NzvrEPQ0R/Fiu9Vk17YoHFvVi61YwSl9VA3fLMN6oDghCu5qb PgnyvDtc9tV9qmA4RnKmc9hiR1U3vtD1W7r36K2Zx11krpccZcmZUo1NN1Bjops91AdKqhJo DxW82MssRJ8fIbI6xi9wYgtAH2pLrKP8pW60vDqBxufyHYvethKnRrMh1QiOTG1yHkpN2n9e 9smjOgPBR94F0N2eDar+GSmy3JagZgH+VWXFpZO5u508RU5UGia58LPs7wjstSAOB+NSUs/Y lxxJZHKWYQ8tzPfUxKHEAczpaIC90k1FvoJPa2NPAndMkJrpNwARAQABuQINBEZhzy8BEAC3 Lukb8Fj331u9R7u4Pt0PqFWS1ARju2ooSq/13cYnpVAleaG0zJ1VI1uVtOR5b5Wmv9RgTCaJ W+Pfn3eP/O8+ULrorc5gbPw//7zMDpQN3AeHB5LYKrNv13m8P1dx/v17BaS78jmgfF/gh02b EqQDxb+D0O9G13GX0xR5MlPCG+hj6b7Exf9nqn3jTmKcdJxalpAFt4XZFyNg1PTV2yVWAq4h 7YsUQP1dg7PNi2T4jrsO9nFCl8OTtqveiT5gLDecXjpPWRx8clMB4plISITo8ICNYb6tiCH3 zwn25sTI9TfAL+4YUtqjY7U2/yB/QHmDMryc0A8PIeeVE+mmYDfVAk8kwuuXEVSTOBosP/BX wqeT6s2fdsuPXj/q/b9lruIMnoX6rPVCbax/Dw5bVMhsCRBZahWJIGkI/b87w2bUGfr7en8E mz2jSoKjpwFyQ8HbT84/+wLDh5bFOzAMxmHpN/S3LcibzFK5jqazASnZYx3sMJuZcQ+FTcja NcqlM1RF+CrQuYymVDG7Wn6Z/6N8lpqVFWWFvB2/UPNmf1fW0fIQjqZ6TcmNdVpxyTA/3RGZ gfuK5tcfrPiCCeOdZB2aA4As/Bd9d6Py7USPQFTvRwPVoC1vG1MF9Vgv0nqg99c3SI1mQhi5 +bff6gm31DPp6PVjQjwQqFa65Sg37tfmbQARAQABiQIlBBgBAgAPAhsMBQJPS7pfBQkOjYWr AAoJEMzS7ZTSFznpWWsP+wZ90xzlIPKzHKKJPVcz4mFbsTKwgvSfX/e2t0FM0z/gyOI9U1WD Cowa5X1zMuJX6OVaZkQSJ2p3+JyWRNwQfdisuF6lgB4UnGuxh2WlrDU7s15X7ljK0ylxo7lH G8FHegcztb69d5uTXq+KUcLxxzSYequjRhdsBNZvxATG9i23Y4WyLeneuRIugwHRSWL8T9p/ JWsQKqfMXhdZpbDl6pDrRGGhBY+6B78MxiHPDjgyuHKC3PMAyv7pkWKFuOXqZLwpJG2GTI+4 YKCTf559fk04b3OC/rj6rEek46wOhyL8VQxwLpmLO4mAwqxE46vKEJSPuZyIF76AU4vcM7lE 2Ag2/kZFKlzMqevevcT/mjUsU6U8jz8KP6ThKcx10V+z5LEWu+pXC05dhSfWXkq81uWw6WNZ APGStosAsx/uhxs7O8poqlzECauKjR3VK35spja/mloJiNRIxkvDJSd7TNQejO3p9SZSCzIt qYBvU13ILyBJtQMltj61Ii8pvr7k5ASgsQVa5Eq2ihxJHjA7ddQSF1P42JsBBPzs8nDIkCbl YYo4JGhMvdfbaZyxcAO7m2KHDa53AdZimswz/mwMvu6wKVja+77CGdQQaLSmpyI0HbjA+JrI HDRENVwkVJLxQzc4ODgE+OxpSGky5jjeyFggni+n2j8ZnMlN58tBQb5SuQINBFE/lkQBEADp A5aaDkUui1K7Y6xspi3RTqxpsS02J517ciYBsaCv+wx7HLYv/O3EJ1JLeBnEEM+llSN61a7h EPCujCKE0hG02PuEZP5wHnq6rgUL6olXyayulhyMUXBukymTZtqS60WnF09NYUxNK9XoMv4W PaHSGPlte87FJZ5lsf31a/2XQldHZvk+JG4Imv1079rgUcK/HWwDPBBhjrk/Om9nqH2IWPCd FA/t4gDqO+B9gBjHuw/T8hHsbRbHj74GuXzdsR1LmYmC7xUDrJynEhOKl1U8eEsVKSvev0EB bIYi2So/giRybMX0BMR+eY4JA+XprvLesVFfbdVXHnDPCq1rU2Tw14MuGy7h64sM9HbvUG/h F+Ojeo/Dz6jMx/tiU18pupXclRVP4JBzAlJ/0ySXy0mHOgcI/nAXW3te249+YUwwHZpjafaZ H9Dz+wIWOO1mbonNcV4AryJhh0UogXitIoaNHZpsQ0UEafKmO8uHxBE1DEy8fs173UiWLoYm knp/IbPlWx8wxZk4B1QrJsj43ldLYM3brpTpXBdEmm2k7fBo37tjNIPAIeZA4P6JTkakJ/ai cAyHvzLzCkIC4fBrpRpjh2LCxi2pZYXsVxSi+7Mn1nh/OnuatT5KguhurdoDxoFtHsEuw/iV idYoC35c7uewVPHCHq2sneXpWPGrR+zpewARAQABiQSkBBgBCgAPAhsCBQJUwBGuBQkFYa7q AonBvSAEGQEKAGYFAlE/lkRfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBn cC5maWZ0aGhvcnNlbWFuLm5ldEVCOTY5MTI4N0E3QURERTM3NTdEOTExRUE1MjQwMUIxMUJG REZBNUMACgkQpSQBsRv9+lx3lA//QWlgqZLtIr9JHLQXu678qkzRcul7SQgejeOUYR9MkVuF gWiZ6iZs28lUYWveI60xvTdFBgEyeq/qNnwHPtXRN5gLdycQT34zq0YSGLM6S6NOpkMy8gxr SB36mesC0Ok1RHT9GJ8HVTAQeiO7TxKkWIJhxM4rmcgLQ3NGu/8vysUZMO2FMERINh6FRjCM Q4Uu7lPMs9rfWQSUjEj8lZtzHe0Hty6B6IXT6gjDkYJ98K50DfQ/J3odCItbnRvPNzGGx59z aLTpeSAtC3JD9hejL0i1jJoIn6Nl4tv6O5RnkQircHclssIxZx5JiSWVNh6wx9Xgc499uhKg SOA6pQVpRU8+MrxknjM5bH0APTTLGzJGmlACPaY3smuxNwcR5Lp07geoCSBuEZ/9nKggep6b EHx65HI+iHB4FmWfeFlSa9KBQKIYhnGB+dNuslad+39LZhbiKM7mBHIxT9rlapJMlUulp/4V G+RtFwWJC4aGAG3lX7pFxsPunTZ9kzqkFNQpxQNFl1pF9LQ7JJCuhDQ2rzOd+GHRXNlNge3l UVyei6svtkX6rYy4C6uGkD9Mwqkp+OagxlglqGVMdnhYDgmvwKP8AsC7s43BIEVhba1YZh4T 2SaJUH6xVb901MG5Ag0/oQx+cszaaBJX6nULElHYradMjSgPcexZfCOB7WWGfOgJEMzS7ZTS Fznpq2cP/1+kRBtlh5yhnFPejvkmiFEKI02rd4aPKmlTxfBbRPm5looLAyqiiD7CQf0s6fbH FytZulKd2OneM206i/sH1YqQ2hJ6EsZBMKW7+2NNI3ExBwtH21s1h7kZ4+qyoDB0mAnrg6Wj qGGU9HcxNKe2iHzgqdOzsE6TL87Or3ig7JAg2r2wFRBJtCmrBMDDdfJU61sgjyPYrehqnIMv xt938jNHfCRb+l/qY987YXxgMObWPqf+TKIRQlErXY1qFKJFXw8w1tQA+SgcbfJH8wntVCLm q/jA/JX19Gr03soweXxlQbF5Nbm0EdeIjLYTBaOXelIkJlb1zaEU/4N+djX15/z8dh1veLwD AI9JlDdwKzeMAPhi+xuJE+NmERvrJllpbS0oOa4A6dfW3kEQmVYPFJCoS6sFhO8pqFNwty4C dKTg8FBbV6II75RPu239ZIAk630DuToksj4TYn1ZMAbFmm0DHakWIO6ja7Rugr/CI20ih7JY dAqshIAXPjL47p0Byjp08rQTQQh4Pun543lScKdGBWY9ARRpkl3MMBhAeiq/2t3ugTQGXKxd tq5V7vYg2yAGzHZhSpCOCUpA/eztNzS4LCe/LWAb77U39cvhn3pmBjVQlKbTcrhv8nOGEByg MoMqPScH4w8ykfkrZ3QCiRFkeBcvxKE3DVb8zQ0WvzDBuQINBFTAEbUBEAC0hrSG46djsoFv Me/9AIQBXvLXedhEpPYIEgj89kgVogrkZH2J1uaF/QtfLq7/FfQBYJkpOJnMaVrre7sF2GMO oPOMKsoxpVQzaXBOIY9jBclhky8iDffyqkXiwkHEzYnbmcz+uSLHwjubaAjFV/yXDFa2ric2 dmpbfggVv3zj6H7sa2Rlj5ifsyLla1p9qckTEv65JhJhP4VnHIknC89EfX3UppSzdiF5T6Xi qUYRTRT+vvKOkVN0/eAy5rv24nxIKy9vKOwdSnGTVwDzhq8db0VtIWRyGXbXd0vw+2xcVEoc uXSkmRMNkP69PIB1GvZ5YKON3K9npxk55IXWCFWYyP71Qu/AzOKONyAFUHtQp5j5VKKWt5Vl XtV4aDYAxC+JhJoad6zKC0XdiKYZCRWIqFjyKFe6tkYjK67oqBrlPhDJybAciluEsbhxmY/5 3yRAxyGnQIiKTFiM6gMLNQFD9UH5BqaxNnL1W0DHOK3wTMH0nAHd+6+omOH8TWp69UP9MR+O d8pTmryUCir1xfhdHsRlLR2hg66qn48XP2USDyddL6eNODUZi3x7/1N5xpjat37yZCja1sn5 bKINdJr3BResowKMOSsXktjqxsZop3u+eYCcH8H7JiJax+1UrafYPGJjfya3TiYKHU+HWQkB WratKshUTDkPIBnMB1QB7QARAQABiQIlBBgBCgAPBQJUwBG1AhsMBQkB4TOAAAoJEMzS7ZTS FznpsrUP/2b8h00MxwBVi9rF5e78Zpp8G5+/jOBUYF1Uu4cezyAVqQ1WgHVLOR4eFRIEdU5r 5wiK4s1tWnGM8mo4/K/124H7PXxZO9B62cEcZGrTs9AU1+iYI9ZW6a15LHTLdbOzxYahbA+I XRawHbwOLiVSF/pAme8lMXmt4dgpBF0YbdjGMmNcdgGWWAEUbGVLkuowudyG6AtSa9WeFGxv fz3ugCAnusIAVoICYPj7nl/5Ig166Bqzr4DouC7ewjI7hve2VxQ+S86qXKH/utmsyN9oF9fN RUHqkqQ3076IQDNl340DdUdO6u7GZ+9YggpovCR6qCUgy4A8PFy8gO7SIaPtvjIeS9Cseh6U W1gkTf+J/jzU3x5H+iaWuS/aQdNWCdkAfW+KX7iLFKzR8UxDdSWEjYTRvPeuKmbMVuzy2v0s 7TvgM1W/jdMp4J9jSfoVaU+CKD9UTBi8HLfOw/Br2r229b4gne8kPt06jJ1mBH+FxWJNbA36 WoHvbkcXMrQgJVmh6DA8G0QMrnpdY3uhIBMLYX+sk3W4fW1SU4GVDC7G0wHZ20R6tnALxt78 LWmL5t9ddheQppcvey3MZNH4rD6JtYojQYLrDRWY2I8D0sA7T891jIqlk9QUDaz2wQnHrPMR sXFwT5onzIfS+RaxPnpX6KGKpyOHZ/8LyfDYeuQXsvzguQINBFaLZa4BEADGpuoE0MZ35zVy 3I5R4DyRkyd+NX+Qitp9oZiU8HC6ZbyUbwUNe7f2IuR8RCczdWC9ObGdU1hkR4ZcRwhaX43V aEba48K6qmLr7HoqgQ/CyH29zcwFbV50j4h5/X7jkVx+hSRZqq9B9lZRgtECRYQpkZtMuj/T 87UmdgHQ/PU1oCg6ZfQrNW5/21R+OI2JXvUiujZf9ql4Uf9L9TYRWU1IroBl9oTVOOffpoqz 3liJhpFEs4fsltfryFkeD7rRFB70ag/dVBFJnynWX5MUPvBESIv7rCZSAGf0rJjfPT2SwGPW LQBTVFtvIXj+wEUNwGu2o27nL7iNUCIoq04o9mPuNRgs0DInyiPJWRJ0X1iMFxRC+HTb0lP2 cFsglOMBJ8bcJLleDiywbUvcAO12L7tXixMRJpsI9K3KU+0ej20mRFcryZamZ0zxNeSzrCBK QTF4v1v0eDWakZREfNvh1HZA64N49q4pXmEujF3QlOM3Lx9xuI5VxjG0+0/WPdwNWQwknVtF YysXWOFSerT4e+gQxq8MDDOcgfM6eZmQxKpxRXCiYD/Sn4CuMNUsB9pH75/yyZutPq608t0Y g4aWcmQi/8wc+9Nqm6L1xaSGu1ChZk9xGRWthsRxFejQdqXi0Ckqg7ehlgBsGQ5+dkAaCBGj xMjGSd9chm60/Q4tRXYOAQARAQABiQSkBBgBCgAPBQJWi2WuAhsCBQkB4TOAAokJEMzS7ZTS Fznpwb0gBBkBCgBmBQJWi2WuXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5w Z3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUyNEVDRkY1QUZG NjgzNzBBAAoJECTs/1r/aDcKcScP/13A6XNGNwJyqqR5popjPYHX3QRLFFiKnqHlz24ocZuG CCY9xDHmdE0+2VMvqaJzER9uPokITcdImoTYjPX6pWmhle+DB8pgOX129t5ihJAg2sduEtjb /9OtBQBaw0IDU+X5qNGDWXTwjs/rw1FAi0QLqZRgGsdiZfEKrYjdrvG0c9Y8sbyiCup01vZk /9LvgpImxX6mLU5CBAoSV/KwqNawETowfavCoqxi34un8dEYuBVqjLsAmLS+fQSpFyHNhejO PF0Qw8B8/SWxQ/53rXMWDX5zQ6COtfCB1aexa/D6dDd8tP1l695+dNIStu6gjAtnl/w5Xy5p uyt10FOWDWS8OhjLbZp+QwnzRVJdvG/hTqoXRO8EQx6CW2QSfK93R0pdd/7Mfc1XrhPZCLLY m+ZpZcEw9t2drf3+lHnASMZo0SklCSUVU0DowD+yLIxrrZzSkR3DD9iOBWtdqFejgzhzrGiN mpCpJhiksBWkZluWkhVeg0gmwQW+1J20JY5HYriOss0tUoc2xyA+tP1l8cphVANsbJaWzex1 eXuzQDUqJ2h7J+HpkgUcKx5Yt8oeZsc8tIH81zOItQpZiYx1AOO9SdM6LDrXRMI4WlbcZFDC BR/fv84gIgGXYATNMY6nqcO21K/uowGxi0oZFbkoCcY4zGAkESAlAzicSBiAr8UZgZQQAJCW ghYWnHlaOh5ql0A9oayTdQbjZKbk3rlOICFDXqqFn0aEd8KI+E09d2AQk3bbZuZvgDmzQ0t8 x0u4oE2Az4QpazO/30NqeiAs1keHORV8621gD1MR+dkagaFAQ6gy+jq2gwEofHRJyCLNjlRp u/VtojxDBPC7JcahWCBsPF6dNI4iM8W8C3T8eu7KnoqxD5wPG463Rgp+eYssUB8f8f2oLKc4 Ee+7d7TX+bHLcTPXBLwNwoK3VJTssZ5j6izMweQqiiZO1i9MW1Sa8lFtbgY33oTh5b0GmRiU hYjIIqYrNiGG6xKAvi7QzTUF6fdcN3+nNVscebg2318zRayfy5C5+JWTDaTgkoSiyu6XxRTQ IMYtqSQQ0HcJ5Zbd4xObtrSklb8C9f9oh3ioxqhjprV9oxVdV55OH+kvSRlE5N3Xb4CObh1t fiHJWdxarxtcy8J8c59RrHCdzkMydqqfPNO+/hRevD/HimE18xAeHvznDF86uO+HKthaVSt5 8i7+TCrCnXiNxnIzxYfGhVzGOJUs1mIPQxilcSzC62weczqeVWfRUaTobZd2tVRxr+g9DF1n jVtRw0uDJ0naTcbv2sAIlgHF6xbIMgQRMsAX+JLw5TUJmsZHyxmIp0KSbeNCkG9ui10WB9rF fYeNLB01LaVso4CTqUGP87kh7WlbzxoRuQINBFaLZeABEACrUd7CU5mmv1YCyGjgUTqV8BMG PFWASAzn0j7SlUTKgUn2RiyREpCkHZdF2Ad+5zPgQwWcOUmgT8ozuwSXj3ZV1Krq3Kkrs4M2 qU7hg9+hi9KmqTW+xJ6cEK3OPph9WYzYzFFcQl2UMe5+2JOls44uWlGSDWfES6TQVlSG468B /HBtrNjw4ux8U4aavGvAJYwg19lDXe1WOJjYq7fNnIHbfomkrXu0sqVhyPTtnOESKQqFJLWN b8dLrA5FW/LxvZ1XtpMczvnKQU4QjczbQjpz/2J4YnzQ5YwELSjpbaqO3IpVnQTgsabBhKRH OEWHZwOwBLZUmcodD3C5tQiEs/1oZLJ8CcTm7BtZOK3z6aFhnEDke8LFxxZ44bWnQoMmzlp2 mAASIz2eoMcvzfP8O6AnK+UjuHwVPbR/UQxSaIMtyRwCJkXA4e0X1JD3g9Z6YvaOGYFI12CQ 8FCNnKLMtTfzM9yh3egeTqFNi5S+sRaLCE2B1DLSrF9SBkIL5fn43oHoaFMCDq77AxZQx/sg REiwnQLo3pHnDuz+usYc2MmzSyQQ5rNpBW+I29+SR13Vjuj3byBfVPJAXf4lkoghAacTnurv 7rM/J5+3K6qgpwIBW13E1ZGH07XVkTfBbQLpkPLPSBQR3yKxF8H+N7freK70mZK/+6CbzNtc 5P6NyxEDzQARAQABiQIlBBgBCgAPBQJWi2XgAhsMBQkB4TOAAAoJEMzS7ZTSFznpfSsQAJE5 RefK40TQ9ctXu2oB4b5xew/Vlblikegyo6mlJOHyaHNbvglmpIy9H/t3k7BT8aTH1r9X4BfC zvUoaysGBq4YIyCqy+ncLu7ZNeJO/GZWDPttRGCtyYUe648jgOEemG5icJ+eDvMH9CFJh6QK pYURZBUZWpauQrmBu+QcV75GaN8qHAxyfC4L1y28Rdx7MrCA65r0qZh+xtuFlGjRnX5yCvs5 HK7Y3ffx+t8RGwxxtU2FerhqQ/MveZfvmF/O9f5Z0B8rKAIeUYUyryu03c2dWQ1Rr7EOJEk5 4kFD+338T/nYHDVUYasjsUN+1D3Ac5MvTC+f1X9lVt2WIbiBilj2vkgPEin3AK2CAew7vB4d b/v01C0ss1kXKdfajGhx8pO8gG6fRR4J33dt7wQfrch5wdl/v57S8UnwdeF+zqXHIB9lNn8Q MhiKsX1tDTQJl7VbYC7VxnqcWD70oQYPh/i0HuBIQAxvzUsONSxxXn3df/m5BjLK0Jkuma3h tucCad6oQChHLDOrQTwgL4t7yJABFuZTYQ+J94XXdo4tELF8/u8CR4zAWx+1QsHBK/O00ZmN RIEIBzoMg8KJh9eaqIf8Sp0JCy4c19qSHEMcss3TiW8Ab+7sPGjvFGpB75ut9kbn3kHtSPeQ x6irJ03f5vAKCvCIQy70FEyjHi4lFGZWuQINBFhakJABEADLYBkfz/EKmcAyJLb7ddXgACfO tBbWgtpsEulswQe5fKpg+T4fuq++hcbMJMtV9wM4rRUsq0ZmmLSnx2tqCfKrBpBfVzd9m2lB h5ew01KT8L9/9Hw3R+KCZuLAyaz/pOB1JCSi0pw57skdGLZUTjDJoluZe+VUDCfN7soCTtHn UPOEekto0r/qMoXfpdyDnq6acc7/BexXFL6uqTP8Wu51A5JQ1HZ9D/FO4ZF29jXRyTElpsp9 ODNXlW1Ffh5yFhXyHVE4BGthQpUD4/KIhWDcJU5Qvfa/o8Mt2Z/KNv35S4btruKQ00o4D2HM 6+1pHiEpr5O23wR9hwFXnKLIpFoK6pY4KPAM0tCGlb3h7plM64LFNdWg7ChyA+jNsCjJF6ki ol1sYqibrYmvjEcvISpQZx6AewjekoPQSrNf2HXSdNCDkZEB5hyJFm64rNsqrmCKZ0GWBMaJ uAcJO9O1j7YnFQ+SsLgiBHyWkNrykqZEsuVdSVKbDPtnHCXwZ6VZyBbcBMyQitbA52xEKXwJ V9SzyGfMQ6Kdslw1EOInO0uoGJkq/6WwZVahRsPTKMueSNfNEDCaEjVLIxfRbGvPW35mmyE7 g0lpyvTNvqU3JPfbWvomHyfxPmocgfZdMFiYe1Zahl8duB7j8XeOipI/ErlO7pWV+FO1dPvp ltFv0Lg3AQARAQABiQI8BBgBCgAmFiEEDuW+l5KC2AufdUDxzNLtlNIXOekFAlhakJACGwwF CQHhM4AACgkQzNLtlNIXOek7nQ/9G/hJCzPJ2EMQGT2meejT46RoPS1xodR6y7yFJ/V00k7q AXT4M3Ml5w13Ft4xyuaOazVXpmtAFJ5NCkwMutt49bOAr8Ihf3+/i6+g4v7gE/I3OP8wAL6k SXBwc4EXNBaScsEePM4MEFdjRCuGE4vj629mA7Mj3yhpNOv3ic2mhhO9MxTR+Dvo1ySYWsgp aEj2xRVWmFLDpUFXdFndWdcge8KFiRKVpImjxkz5omz1bLbjnM5NMeZwzBrChF/F+gywz0wz mOKjpgFW/liodIQ77Uq34xxnKvqBBD4JcaLPtvzjvf/zAtRYiIQNaJmbDWxC/e5jvVWmpesy KQGZgtEU3YZeQYSQu95QAtTAnxeniG8n/h8ndb71X2hmCDgvL+r8hCdqQBsH6PL3t+Yepeq8 bvNzaZJOrxTcAQCMaCAnCHdVOGp2pv+X8w+u0eEFHzmGDrr3SikoLrIl5EL7buPEortDFCMS 8xQnP2KSvZPf4KzhCXDVuy8E13OQo0iIlgh2FQafza4qtfz6jZ/dEUu9jfGJltrOU78UuXs/ JE8ZmEwieqy1Ou05evusNkSHtafW5DM1Vw5ccG25OCJU3QvP/TYKWYYYmB3v4blj8uNOoCka zcEez5yZC0OC6FCPxG+ZHYyqa13X/94mf3X1idAmLJqvD1/ZJ3VTaT4CXCcDV1m5Ag0EWFqR BAEQAM3TgMH1qK16yCnp1wtmdEs9gtg+LNwjJi2V/OpEcMhepF3GLJyKaPLC/sgORvUOR1qU +w5+1eh2XeL+80GDAooXIUB9FfyQG5Gep0ZPcTIbb8VgDPk12mo/PkFXH6UB0Dx+2OB4dmG1 Yjr83wNFZSQkew0TqIgl2teG+C892g4R9BeHSimUQTEaeqAbhhlzLJJQCls0Z/dsmFgoe8kw G/PCEF05KBMcC4P4JUJUue1l54PjdSFMXJgJvX+Zmx5kLp3V4mWyobt656z6EMVxN8zcd0+J J1P6oJr5yi60jdc+iKqRxYE/E5CQfWCGGJ/2oQLVbKPX8O52JRvCFOdsjC8WJWu4c6FlWn8F gWGMQ0CHkBio4d2vK0zAsIE2Z1+PlB338kBWYv0UJs2Bwyd9OeT3Acy6GuIkXmbmsX6g4qD6 P4kzDEC3HuX8yP+oTteVCW6BLS77q+BxKWBrEhu/MpOCdUDHKBi9hxkAxLZH7htkvhl3+/xu +VQvSXNLAzAVpCdlH+mHG7wnoiqUJtwG6diAVD+QZ7BPJz1hu10jgo9GuvGQONsQSW5DIbrV sY2dKkRQ4Eekqn6pn9YG+dj7quQdRHCDvnaDWMYyGriRcFwXYBcCtas00wUgn9D6IJtJGSqc HryYYZuuuDeadyU9AXpeXcz/DtlFbV4fqsTdjTvzABEBAAGJBHIEGAEKACYWIQQO5b6XkoLY C591QPHM0u2U0hc56QUCWFqRBAIbAgUJAeEzgAJACRDM0u2U0hc56cF0IAQZAQoAHRYhBDgn YFHqR3+j5JU5MhSYrcbBkjI3BQJYWpEEAAoJEBSYrcbBkjI3x0QP/jHi6WT9bD3JJPJljwHS CuHIoTwD32TWT57GxL8rzBmA3WNlx+xtAE3gVxHZGwSC6H6np7KDUpRYo7zIptgMAIUIgzyH HFajKW3a0JzGW7KkorTIBA8zm17Xg6HaNDOiOg+PtLZGqDcFB/1AVCNNz3vM4yMx00WDIqcU 3ZyDAdy2l1IJhnG8BH+g4oSYqAsKKiCd9/XCf3H7zLKoxLQVG76+AUA5e+07/B4HyTAVmfeD b1ap+gtGX87InH2vzYhAdCysibuy0M4SfaRycspw4+Qd5qgqiGnS3rvrJgg0BWVAlzg6apVL gSSmtTmmn6x+MPrsJQaMr321xqnruN0FwS2ENH61lB0eomg6ANj9+E67JGBvdo8i01occhiQ mQtJXU3JeQNu/nbv/fHMy7AqKr9rlokWcE8GgTU5wZ4OeWZ+WPFAkR5JMYy/jm1gRi53ywCR ajAezTn3sUSc4xDf8g9/PECUUAJT4Aw1Ucl/JRDlVloJlGlwqcpA2ux3dEKpAvCBvN98gy4/ uImUXFJQ1J5/3mxRGKkx9hDQFl2HWv5J5J1WQuArJ8GwlJqtRNAzzpF1xaP34KUgGWbATgUI y2ZhNhUfiSQ1pxlL8bkjotYU2bOmH7zfLq/HyvR/18ry6miksXcMzbER67BAJUhYIxAqpwWP mkBaFWqJEgRnug4aUF4QAJ2Cap1Qep5g0AGrnSkDiyxcpMMEfUdS8K1xC6eLl0h4lx14P0hJ b0ZEB19fC6uYylEXVcZOvBTFAEqWWMAjlUNHg+rxQyPKV34BilX0OeksNxYCLncTJy4takDo iQg6DZnip7n9o5QewqQWDs+xzeVowEJFwK59n3IVV/PpNc/BdExO6Q8m1ARWItPRuQswc2XG RDT4YKt6Hr5aR9U8SDgEEc8DwEC7vAVPsSbPkQj8rJMKp4tkPF+LYMHOG/7NNvHXVhYYxJTr C9EYXN8EhMXOFweoWlR8PZiBmSKABWLNTO/2u5zS1QVoIWffPoWYyE7CWCddrvMWL0viCDXh 0RpR49mfBrgxPMoh4pnwoyXNJ52Lakfz2qEpjHtX8OQLrnFb/s3er2+TdYbhT2Jg2e3fIset +w7a9qL+8IH1AeA2MZms1Yq7ZPznp8yVoowO1s685OJV2/W5q3p7rq7gczpRz/wnTs4wilBS PHArEZOw/NENblr2jbFtxkuk7fVRAuiKOD8jJL5Z84QSGaHPXF+X1GgiybIklBNMLdKXsL2a PcyHydUUUCGI+754mosFM8sUdESlAWAGhnwiW4hikiHGFO1KBPDBKVFgXp29o5qiO++Ja4Yh 87/veThr80t69YpQ+3T0IHoZrr3pHomMgcRjwwZe3RTy7XEekgyEMQOouQINBFolmcUBEADR AgdOeCJzYor85suSpRSKcJk2e+tETZMITdloSDglUuC0+CHPShwIs6WMnr6ED9au5PinB5fQ JIJvaoOOz0296PFDALMBoqh/sdRdqp+Sh+kwSlTVRAOF97x3O3jF0nnvQhVKBclSd2r/tfiE ZXB5UxKgOS3dg8+SsriIpaVEtxHQ4mHnAIbasilfh2ESsVab5maE+pmsdZvUVFzl3KeVfnZL tIFo84fYner8gCb0KrOGCeBl+kiOaCzK2TGpEEbNdgagFtL5eCl6RQwpJOOJ2wMTbHl53uSv t29+DAGNOYF4mYKtwe7vBKiaPdVhRy6ePFC5bH9sgG/i+pxGhcGBaTluIBy0AK6e55qIdPhL /8Uis/dTomP3D72/sss0EWNxajOBUpewl3KextEgaS2lNTPi2nS469iAfc+UAGfDKESZ3hJL OzVRSA1FHI0GAyMR0d6v/bDemO2JP8Lw4ooHXDZ1O5qqvJ/I3tuua1n7tnVwCIiM43kViSnA ybGqvcbDMIsMTf+0htd5scRBn/fuSG2ECsMeI7QLTNJbntJQXanD7S9QLXtK7O2oRmkg7ZMl 06xFBTstaZoEgzNKzHOOVr+dLd9ZreuMmssYtm/ZlwFueKo4vaWJn60LBUqrBZCDYbv1LrmF c53eTAfH7Xn1FpkV3gdlT3iOL/7CFyH2ywARAQABiQI8BBgBCgAmFiEEDuW+l5KC2AufdUDx zNLtlNIXOekFAlolmcUCGwwFCQIEzAAACgkQzNLtlNIXOel0wA//eWWaWXYOBPwPI0M2LopA YiMFeBm2H06RXUEbmxrobqOTUPPVkLGYxl+0SK26WJ/RJBMCHHs7P1IVWtCwFghX9sgd+pnf /lKLugNEyNC5veG6zS7S14dQdazYvQZg4WVqf6ECTQwlzjylBJZsHfndeqZG3w6WY3f4sp0l 7ke75ocXGced+DgHWsUDErRJjpi6uBjefie5WpGBZg2+OWK3uBor0WnyVRQKX1I79RV2QaKm AC4YFACJ5v8r8HbN2Yw0P4YYZ3o3qeUTetWv3xsWRrUX/5B3OLtfIfx2KJlq9DeZxxNgYS9v 3AF3mhgMpH2mzLxOsNBr6BOlXEZ8VgJIFNE9/MEbRgKppZ7uz2envpEXdCnqsER9rAUKD9AQ 2yhraV1ztFtpL1mRxq9brLoq+pzx7AtONlDBnpkosjjp1tQKljAZPfC5u1O87jpzQGq/GkAO ppR0TEYovhBA0peqimOfHgJoAGd25vNU/9ObMFtzg+jmlAMNMbLHiPniQz91m8q0qRQCo66K ZGauYamCsjAOQZny6kXhKZcXfp3E+5Sy6tunISWVklggkruO1MxITuB3sBOmblwvu/bhbZtz PLKkvvXQzK6W1+MdFxh0pjCw6nmLs0Cz9LmNAnqbKQuUmBeL8l/GPjigA1kktFFSjdQ8ZK9c 9jbeAZmrZ+Dk1S25Ag0EWiWaIAEQANfHL6Gd3CobCd/nhzIYgOAH0Oi6itu+/rkjJvRYntPG kuHqrhtE+rThEoY36mbAFGwIfOZGetpJnF+KKoJGMyg5J7Mw3/lJf0oQulud5AYDNDnjvDbG g4IvrTNUmrHR8xE33Tn14q27C93ViGfWs6W2Rem5FxSgRyRe+LiB9kHCNjn+TztJPKE5zzuA 6LW1Dd4asnSovSb3F7zlC2jeTkCyIisoVmUVVamgKxU4J9MOdeW4QT2hNko+IeK4gWPJzczk 8fBRQtFnHA1seXEu852K6X+2YMXa8R1QO5oADUmjhw3PMhqttO4ll49MUikSf50yhe52R2+T U9ssuiOt8YNfevcEPy4Xz1hlj97a0aL9hKmsPWy99VC4v4EiPQbbH42FjwQzQU5SLkODCtg1 BxKF4ODYx8UBbe+x3CZtscYZrnobzjR8JAGqYvh6VVDzQVXqbx1tfMHaXCu3Q2eaf3lARa9M kKMzAccUFqgu1V1mWnK6AJMtb/sf0qfoB3xhyUZYn7zm/X257y0Kjf8n4s8GWT03RlfNkYqa H5PP6k+TcKaWow/ob2SfvWypWAUoA/mbp4RYsB6We/23DJrGoTV6og2RbtJw3DNUEyIZ+ZQd BPg/v8NLpvk2fIeJW7O2GLmWdYj84ToOJmO7ZvT8hjWD9vuD9RRcJfpRw/PV8ePXABEBAAGJ BHIEGAEKACYWIQQO5b6XkoLYC591QPHM0u2U0hc56QUCWiWaIAIbAgUJAgTMAAJACRDM0u2U 0hc56cF0IAQZAQoAHRYhBM4nL5TsMpmlpZ6B48rvqIMhZ1MzBQJaJZogAAoJEMrvqIMhZ1Mz ZwMP/iFnpwa/thPok4XjLgM37FQHTLKiVYzUhcWQaHfcdLj5b/kd0j0QcYcOjb2dG8KMnkze R4k+ceOzWKXUMQYuQhhLRz9Ij3IcrZYhvDS6A7L1ra3soBILlid0K9P0JTLCAoHFlDQuzo4X uwbp3CU4rP60ChyFNdvZm6Q2JKcHR9x8NUK9PmOpx0gMElfDDuIl5jytuur2g7F42OzGhKL6 TyCcg4gcIw3Vzsz+OdxkQeFNzBr4aGJZSKiy6ZBodZ77rTsKV+dhZ2cgEYnDDB6zCGXnV9YA Zt2Lwz2z+4wOkPNu4zQv1EPVB8c9vZmdXV2Wl/8g5An6XjGfMLT35Ys9nqYubYe71QJ7gbBf a5lTKouadGfDxAsoFlHZCmIHqgRbvEYH6CeFm3LH1ZcU2PJxt2cJ4mPfyxVrNUe3OI4dmZxC 0XjUNxq4kMVYPOzlQWLH8R3vzkFDzmsJ/QEkWDFm3X56k3QxewVZrPJPYsF9MEoglwD6wV6T hKO/iUVWpUcXm+w7/F/s5MxrI3aksCiRmbPpObPcKaItcMABbgdiIirmySNodMfwcSbQGZu2 y0I9107/re4nZUlS4FphpMEf7saGyy0KXYqOAKGPplCTls4KAQREabSNLB+g+VIV0km4NgTA AiuqvSkgpxrltz/cqQRtpvCnUAZzDcfKygh0m2tDvlwP+wZLWvDQdomrhSaMXaRdSUsWmm6G uTvhBg+Gm3NJg243MLlgAWjNU4prWw34S0OsQb73PVDEXyjyHRnD/OoTLBep7Ww31iqaWVAo XghG9HjZVTEtkhPNOMLusxVPBMUNS2r0W/4YfRRV769rjvaRYnbg1ZXGKhPzLc04chWE7h03 kP+hKUR1spxdKCgcsXA8OZBtk/LhiMoz4UqDqAjWy5inRu4HdiZ3iC2HLQyy8iWw29CiPh+V g2tkkWcGX7u7J8EMWZApILv5r+JnVLAxAoTlRxygAWVOjYHqtwfGTWGYwG6efVPIlPdUsQcQ 6pAPcdzqmsduIPIGvRJL4McQlt8fmTnWvFkO5eGYCxWzA1bbLaec3u2RitzFOdqWOXANWJe0 07WtGK8SnscttZZugh6FOv1bZz5vcO9YQfCPk9V6z4d8nky55oQsxxkdn7WXSw0qEAyNeUyn ytvachF499WtQXGn1QHBDFiTa7cA004XJz/m2MC6HlQeaegn99yA2dD55g1IDzRMJh1PiBg6 bqT5v6w84n/fBtF3o6PL7vBd9zSP0taU2xFgcNl0llI0mwIjM9+QByGoHxRaPC6w8cKObiYm ui94n0lapotYqqbakoJGglmG/I5WZ7uhR+LP3jtFrSSkRNa6o5XQBHoH24yrg2BGxfbjse0w pU/CA8RsuDMEWlUW5hYJKwYBBAHaRw8BAQdAuyfqSjrggnftZ36u/l9urcjUTpKcAfvHMNLf eemKOPKJArMEGAEKACYWIQQO5b6XkoLYC591QPHM0u2U0hc56QUCWlUW5gIbAgUJAeEzgACB CRDM0u2U0hc56XYgBBkWCgAdFiEE02j+deGqkvbkm5nSbB8e3sxQ+lMFAlpVFuYACgkQbB8e 3sxQ+lOA4wD+NVk7QGo2a2wuf5pnBEh0vdV7z2zOlJF3Mimnzft0kQoA/jmx9rzTgByzeyjE DpJBx+uYkfs5n09xqYeVKq6PYn4DQ9YP/R4a5F6EbNToIkuztvxHQ2f7tZYmnoiYwhuRPebB N/1HD9QahJ/6vG/PYwvQb9ntiR4T13FiNU9Be9DzRxJsUtpatX3EAGU0bYayiZ0qgP/1QgpY CYp5JtRT5KA+9Op1weMoyQicFdxvuBIYZlCY70A05ucw/XmIgrEuSPcKheRFtT0BEClsAb9m R61kgxXQ0tzaiucn6KVT6WGItxiUzSa5a5EoIV98NLZg3dU/9IEa7UO/vYe8Ybw+asObLtXW EImMwmbzKMAToMcAoAQmcUjZgXzAr6l9aI8tCqGSJHcDrAIYmYzigk2ZjSimqQfFk729U74Q aMZQXMkNYXDHDRO1ISgj/HoMcj+ZVMjqbV4GRE9+cGMrIyElAZ1s92j/YywfSUXifs6lz4at JXRCzwvbdRzEIpXYtP0iMG5iwOC6y3GrmP8ntemSj96PU9oGiGZm2HUM4t/Cw7a2squ53XkI G9eauEcTK+FJ2FIfGDNUL90wwWBE8tRuzJ4mgqg1XNM4oY4yekll47OjENA3MmONG1VloFV0 NYCxqA/knpS/3eAKB8ZA8alYHmjn+dR/Sr3L4RIQe0dMSkXE0NRsWOput09O8ZKLRklJMlSI VkJgl/l2xPimPwrB9M+XUj3DrvQqj2afgFgjR7nWKh+ppSyqG2JwwtbgC8hdm6bPEpIluDgE WnsjtBIKKwYBBAGXVQEFAQEHQGrg9bPmFaWa9Ry0OBR+qdKnlJI3vxYBYqzKp85qnKIkAwEI B4kCPAQYAQoAJhYhBA7lvpeSgtgLn3VA8czS7ZTSFznpBQJaeyO0AhsMBQkBuwTcAAoJEMzS 7ZTSFznpMJ0QAJBK3D/KLJ031tE/rfivU4hdHdRH0uHjqIkZ5op0p3sn89wb9aPATQgLsbHW 5RHQaLOTC1/rU46FuZeOUcCoh3X46Bz3R5LkVcABYy+y5u/DUCpg9cKxpnGUAXEfFKPvWKUw m+5YUjFH18JdA6am6Qv5KiS5O4LYJpiztq0PMwnp40+QTIs8Gmwj+qBUwO+6zmXOg4i3SWfB CCQmqfXSBWsXFidFmHhfYYbppTP1KwrB2UQePO6aYuw0DE/LbaZ6CGFwpYJ+ArBRu75wPVi/ hzHlrw5wwPlOem/jKicOWFlFJ9BIKFm9V7l6T9A3AIMnXfocpl57f6XSuJI2bDhLoR1pawgc VmP2+J+W4/iTeCSOF0hvEmrPeROFGKfWkHY/gUWMakdczg9ociHvU1B5zIjIRtUF2vXM91P0 WepXy4V0cwwl6Aok4Evh8EUtzsfnkbgFhajfqBVEt7Z8rf0QN65l/I4Hb+eHskLGqpGi8gn5 ODYR1y2W/ThN5BxaTuqyHOqMP+T8MUBd3q4ssP28MGZ1bV0TDFdtZQaXcl5+Up60G8ufvbFq CR+HxbBMMmy/AGRfwoB+D7/Zdcuv2RrF1z2p7iTJtdz/6NM1HWSpDCYEVLJuLVVuRwDusXcv +lrdavHRUHp+Da9/hasu9/Z7sjbUs/GtGDNugaLC9s38ROyD Message-ID: Date: Tue, 10 Jul 2018 14:10:41 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <23364.61514.267429.409048@gro.dd.org> Content-Type: text/plain; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: base64 X-Originating-IP: [38.109.115.139] X-ClientProxiedBy: BN6PR21CA0009.namprd21.prod.outlook.com (2603:10b6:404:8e::19) To BYAPR01MB3653.prod.exchangelabs.com (2603:10b6:a02:84::13) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: dfbd928d-17cb-4807-0ac6-08d5e690761f X-Microsoft-Antispam: =?us-ascii?Q?UriScan=3A=3BBCL=3A0=3BPCL=3A0=3BRULEID?= =?us-ascii?Q?=3A=287020095=29=284652040=29=288989117=29=285600053=29=2871?= =?us-ascii?Q?1020=29=284534165=29=284627221=29=28201703031133081=29=28201?= =?us-ascii?Q?702281549075=29=288990107=29=282017052603328=29=287153060=29?= =?us-ascii?Q?=287193020=29=3BSRVR=3ABYAPR01MB3653=3B?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1=3BBYAPR01MB3653=3B3=3A5CI?= =?us-ascii?Q?xBCmVq5aNL/C2NT1Vb5VvIGUz6t5munLQ1wCiak3Y7BXir3LUp4OemhOrviX?= =?us-ascii?Q?27GtYTFrlLw3LCnZPgNjrY88gRzG63UpIxzghh03tZR4TFd4UJBMBHxnoPX5?= =?us-ascii?Q?eu1RbmeeO0WIZTc8eRRpoV0fZZiISP5mvglKkdv5+1PsYK9wapmOLBfmZXtx?= =?us-ascii?Q?5xM03QiuW7UmkRcZ2b/jjmUS9QbWKNi3nRB5S0HD1RQSe9CzYjbMN76xlH/O?= =?us-ascii?Q?NNkvzKrNR3jh0=3B25=3AVNwqwD7VxeLlvzX5QkZajUKkeB04lLENtHjU3Jv?= =?us-ascii?Q?fS8imY2z+7kGLcfOsgeYpqyiRKeuVQXzJmmiv2UrNzYKExGi4cq7UT5tUO+f?= =?us-ascii?Q?E00YT7b5R99VYZblGGzUNnKfSkKtP5rPY6kx7IsamINOz54TUWMs4RA6m89N?= =?us-ascii?Q?ql93oEgeux81foWjrTCNYE4UbbYbbKbBvsUeGcO8YJgHOBijgrLtzsr2fxSZ?= =?us-ascii?Q?00dk42wQkvs3+hH/bOLt96qRSzajkkcQuyAx+RT4C4MrGJlkFMb18bN18hBu?= =?us-ascii?Q?kS/GcGF0IaFLXOdqlD/VRH/q7+htwZXsoW0qnJjVUcz9DIXIL5NeMYLbopjr?= =?us-ascii?Q?VIQ=3D=3D=3B31=3Am2iPETmhoIp5VqVK/CmmnKQmIWBL71E3MrvP9wXuP5H?= =?us-ascii?Q?1h0FEV3Zl0L/wBg7WU7jubpZXZZPyq95OU9U5zYXx6r939epqSILDiHo7FeI?= =?us-ascii?Q?RH1b5Th5SNsOL62Lu7wc5wSdAENhUG3irs96vOv9/lJQqjDf6ilosb5fxpfO?= =?us-ascii?Q?nJNqNe14Dr0SYp82X2vgpT7MLR/7UgE5AGJznvnicUYaWYmOWPQQ9dQxdQD7?= =?us-ascii?Q?yTxzFNAKt+iw=3D?= X-MS-TrafficTypeDiagnostic: BYAPR01MB3653: X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1=3BBYAPR01MB3653=3B20=3AS3?= =?us-ascii?Q?Z2mQVIPW7G01JPxUglTbjt+Ol31lVovLZsTzi+VZIirDd4+85h7vRGuxlVaK?= =?us-ascii?Q?CWJPWy5kxDwUE1g6iQ6FmMUDexcGwBCafJ4GPp6+zUtUxZHK29bE6DG6nZp3?= =?us-ascii?Q?IgCx4bA55ciDcB7fL+J5F8oVYmti6YbtLz0RMfu2FpNwoCnniWQFKqwIBRzm?= =?us-ascii?Q?BLLMhqdyMtFOh8D8ZWTrndxfvNV1EwrTNMZbxCdi2u0MB62ghiPvcLJ8Zz4B?= =?us-ascii?Q?3gTIrWkE1NM4rT41Ks95C79oL+1jTmlbk6m51s5E5ejs3f77bXbzC9BmbZEg?= =?us-ascii?Q?dOVLXB6Ovn1mltWBFqdEAFqXje8+KSY56kbzMJN37Gn2V1BBXEQ2RE7qcD1X?= =?us-ascii?Q?+FxvtNKsIjC0pbMINUNajux+1z7gfIUdADK7/amtPb5ioU2/X6g2kC0oDBlZ?= =?us-ascii?Q?whoroqMheKHkSnKXx09sb48bOZ5upRru9DvjxOrUklFUcvSAPq7bpY192Q4H?= =?us-ascii?Q?2ngOvkaeddoy2GdUu5FZd1GOsN9eadICvAuBuDL2InCvNqaeJMyzdMe8OUCd?= =?us-ascii?Q?1oGe26JrbvUU0XLMmFDDKWTlBYCdDhar2uREeluJTi4A3wcjMW+QFqUTNwKY?= =?us-ascii?Q?eybz5ISa1zi2mhXQQ=3D=3B4=3ANJCVEmItSdFqZ4VLvQuwKN8Gf/Ge79639?= =?us-ascii?Q?iPObwuqId1AbGUX5EzT4/N2zWdTIuh8jqGDaFqTXNdyaFDosPT4jgbPKuaFr?= =?us-ascii?Q?Gk3nWTVwPb2kaW0DLyWZABvY7YPAnXtA3zCCapsleNt3f5ntvPAPUiwnjZVq?= =?us-ascii?Q?ocATDgGF2QPGo/KXiRiZTlDQouUEw/hxDvg0wLUctaeupr/GC+aKz4ww1B/3?= =?us-ascii?Q?i1/Et4D5bH1223jRk5mct6jA4wA2NVkszXXzU56kvvIyQTfN8GnefhVik95t?= =?us-ascii?Q?jo6CQ=3D=3D?= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-MS-Exchange-SenderADCheck: 1 X-Exchange-Antispam-Report-CFA-Test: =?us-ascii?Q?BCL=3A0=3BPCL=3A0=3BRULE?= =?us-ascii?Q?ID=3A=288211001083=29=286040522=29=282401047=29=288121501046?= =?us-ascii?Q?=29=285005006=29=2893006095=29=2893001095=29=283002001=29=28?= =?us-ascii?Q?10201501046=29=283231311=29=28944501410=29=2852105095=29=281?= =?us-ascii?Q?49027=29=28150027=29=286041310=29=28201703131423095=29=28201?= =?us-ascii?Q?702281528075=29=2820161123555045=29=28201703061421075=29=282?= =?us-ascii?Q?01703061406153=29=2820161123560045=29=2820161123564045=29=28?= =?us-ascii?Q?20161123562045=29=2820161123558120=29=286072148=29=282017080?= =?us-ascii?Q?71742011=29=287699016=29=3BSRVR=3ABYAPR01MB3653=3BBCL=3A0=3B?= =?us-ascii?Q?PCL=3A0=3BRULEID=3A=3BSRVR=3ABYAPR01MB3653=3B?= X-Forefront-PRVS: 0729050452 X-Forefront-Antispam-Report: =?us-ascii?Q?SFV=3ANSPM=3BSFS=3A=2810009020=29?= =?us-ascii?Q?=286049001=29=28366004=29=28346002=29=2839850400004=29=28396?= =?us-ascii?Q?003=29=28136003=29=28376002=29=28189003=29=28199004=29=28367?= =?us-ascii?Q?56003=29=286486002=29=286666003=29=28224303003=29=2822938300?= =?us-ascii?Q?1=29=28105586002=29=28106356001=29=2866066001=29=2811346002=29?= =?us-ascii?Q?=2864126003=29=28446003=29=2865806001=29=2865956001=29=28436?= =?us-ascii?Q?003=29=28478600001=29=28476003=29=282616005=29=287126003=29=28?= =?us-ascii?Q?956004=29=28486006=29=2825786009=29=28229853002=29=283168600?= =?us-ascii?Q?4=29=2816526019=29=2858126008=29=28110136005=29=2816576012=29?= =?us-ascii?Q?=2847776003=29=2854906003=29=28316002=29=28186003=29=2877096?= =?us-ascii?Q?007=29=2826005=29=2850466002=29=282906002=29=2881156014=29=28?= =?us-ascii?Q?97736004=29=28386003=29=288936002=29=2881166006=29=283846002?= =?us-ascii?Q?=29=28305945005=29=286116002=29=287736002=29=2853936002=29=28?= =?us-ascii?Q?5660300001=29=2868736007=29=2823676004=29=2852116002=29=2857?= =?us-ascii?Q?5784001=29=2876176011=29=284326008=29=2831696002=29=28658260?= =?us-ascii?Q?07=29=286246003=29=282486003=29=3BDIR=3AOUT=3BSFP=3A1101=3BS?= =?us-ascii?Q?CL=3A1=3BSRVR=3ABYAPR01MB3653=3BH=3A=5B127=2E0=2E0=2E1=5D=3B?= =?us-ascii?Q?FPR=3A=3BSPF=3ANone=3BLANG=3Ako=3BPTR=3AInfoNoRecords=3BMX=3A?= =?us-ascii?Q?1=3BA=3A1=3B?= Received-SPF: None (protection.outlook.com: aclu.org does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?Q?1=3BBYAPR01MB3653=3B23=3A98YpJ?= =?utf-8?Q?JG5GmYCjTTpwBkSpCQGLsb1W0FxnZhN/z5HETD228YTdBrFA2Okv+IEysnDzWhG?= =?utf-8?Q?uXF3LKuQnBdaklQEuFwWjpdaez0TL7tJYJZY325RBJFvtlzN4ypPdFXdRhSouXD?= =?utf-8?Q?6CiePKAn6QseGr4R1o1bn7GZaY1WIDkcEG+AI9guDP/ivR+OobH2gnIMKH2OmIA?= =?utf-8?Q?51lJT5rAPbC46lh3JUJJ0z1jFHDzUHN/K/6g8wtKDa/+HHYaFY41lv7HzYsJl+F?= =?utf-8?Q?HjM5DXYky1J3ZR8akVs6UXKLz4iDX6uYzhB9UkZ3KxYQb7ibRPOBk4Zi3JMAP/f?= =?utf-8?Q?yO4FVBsrh84nAhwFHLGwHO+ANTX7Q2IvUfkmC8gL43iviGa84TgzL9G5pp/NIF4?= =?utf-8?Q?hQMuj3N0Uv36PZkiRWkMvf1wv3rcsZaSBix8k3tgDL3A3551IKofCAbjaD1MsyI?= =?utf-8?Q?ETHOFUElyd16+xHxIseMpRb13lppSmrMSxgbRsDq2Yzevjbd3cUg5z68nQYGeKM?= =?utf-8?Q?gE5qymgGjzH0Ew/rOI2AIgZniEutVmdrZbbN8GEmcHmV+J3Uwt7zfdG36kfsB1+?= =?utf-8?Q?ISyO9uXXMdWLrbM4rj01HUmw16hDGkqRkD8HLsVfyu8XVPHdX2wYNP1QNYuOlG/?= =?utf-8?Q?aInKAmkn5L45NwNv2pBy6qRVTPXpH0Job/z2bi/7mrWzxKU8G/WMjjPWKbnn2bQ?= =?utf-8?Q?BUHS6spwZoYeDwiBjQJKHAXwEhhDjQvoECYXS7Q3082GXFC6tB1k9Z1dePvrEk7?= =?utf-8?Q?OoJiiLpAh/JBqdiEY6JpXW4pGktsI5JVENIb3Tj/+Fa/JiNVarN7zJBR32MZrWi?= =?utf-8?Q?O9n4Og58OysYSdbwPw3zdOt+yrRwl1TZ7bQu4Pd/MPm8FuCHazj4M6aeOEl1vcL?= =?utf-8?Q?l9AzuRJus1rdOwXEvSfvAGyjd1O2jciAm8XNkc6Yikg6CVLXpXFGBg3lKuNa4xP?= =?utf-8?Q?0H9lERdKVXczjZBH6vTieBho5Y4o6grqoWYAslBF8ayDLe27RkPGBAmxTAb5Nnx?= =?utf-8?Q?Mt9Wc4J42dphC4zRwzuoRy2RXIEZkW2heZK0Ed0X5aEKd0YrTm1vsxVLSKMHoGO?= =?utf-8?Q?uCD0rmhrYiavzDHom+tURvyeyC5N7D48PnGhjKvMFFxcKPqfj58wKCU26+ZCD/z?= =?utf-8?Q?LQUd/AIZoSbh3hYHB8x60HAAh5kLitq80dUP0V34YG5ea1Hl3DrEwWuQwnlFm6i?= =?utf-8?Q?P6B6KdYgi9Rlr9qqvKcTeUc758y9wZjRDMOBPkwMjBb4yr+49/+ag3tP9C18OGg?= =?utf-8?Q?Ny5eIM6dz+zCbl5eZGPYOS1lmxX2jXQlxa6WKL1zKBWu61RG8Qw5MNOLw6YfJzv?= =?utf-8?Q?jmJXTfMx0Q/He3dihFRzK9S+ZOhiXVGNx5v4Qoq8gtl9cvNztQ8OhI7BmdQJy8Q?= =?utf-8?Q?jVD7KFJfjEaLpmWV3mcAAuSOz+ZCGFxXB8kdfVA=3D=3D?= X-Microsoft-Antispam-Message-Info: =?us-ascii?Q?Z+f/u02kpxhtdSIyqM23ANc1d0?= =?us-ascii?Q?W1ohusslT1c2oBn6W3Vc/cLP4aS0Z60cQykMWYgdXRZLm1/NP6DYMMYHV8UE?= =?us-ascii?Q?m4Bv+he27MbOD7BiFIkJcEDWESRGXyJHg4JAGKMWas25FNqZf37G6oUjOkdr?= =?us-ascii?Q?nvULyeqHZ+dJU4LbE3i20HgUo3grlkqJ4qkmA+VvUlFu4yg9z/dPex9ZLfy8?= =?us-ascii?Q?n+1Vva9J9ZI48FaZRik4PNlicChs+3hpqiIiMCjZBInuzUdZZ1p3zxiuPQSM?= =?us-ascii?Q?ozSXHmFH4oM+uxfuGa/2jnT/44oip41sAnXeR85XX3MSvkw/5wfX8UDUxFGW?= =?us-ascii?Q?jAURMdX6A9VlYjQRhkAe1WHsWWBpr2SS0ucFY=3D?= X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1=3BBYAPR01MB3653=3B6=3AQAB?= =?us-ascii?Q?xAAw0oh5gDM8sjNLLrSwTJ2xP9PCR0dHzMyYetMpX4abhlPxkC/zo3L1hldi?= =?us-ascii?Q?agafuMNxLvb9lhWTmnl1bCtJO3kpXX23ljNlzCknzejovQVqBWgwM0z9oQYX?= =?us-ascii?Q?4rXygVkhPA/M4UQk/EnWNfmOYl2CAZtkort3IoJUMOcXGOqyvPUtzsS0ge7v?= =?us-ascii?Q?nfsWj4Tdn+2q/D5euDVOh2BMenHDZHpWkIewYYeGbsuw6Y7oxlmSQeDC2FBy?= =?us-ascii?Q?PpGO6KANZDzv2+e8AkLv70I/VQz/2uNnOGI92/ELULvvXhb/p1cbc+xNpQvy?= =?us-ascii?Q?dWDDIXLfMgdw70FQuYxJMpsX2aQSid+YauagY88WqlKnwlUpdrzs2KP3f9dd?= =?us-ascii?Q?rFAk7yy097oUvF4lgCr0aRwJKrnFiWDExEg4LD5iJWjtQZbO8eQoWaqGVWcE?= =?us-ascii?Q?uDMrclD9d3jg9Nrxmj6cle1P5eCmsPzIzUqlul2FK8Sg5aQ=3D=3D=3B5=3A?= =?us-ascii?Q?KgJh0xzpYvGBWaVvJoYTnDA82zI3Oit4uGw2aGytl00gzBbPCXFC9+neGqaF?= =?us-ascii?Q?SkrkFtF9qJh8ofHtfHHRMyj8EEm8Xc2eTb9wt14QE5/s5KLLnlj9Qbb58Wyw?= =?us-ascii?Q?VlKfXLzw0O31fff5VLBpkH8Qf+iPeaoS/TgpzlkesiIb2DkzVCc=3D=3B24=3A?= =?us-ascii?Q?qyGaxbLra8G+1bsBvX0KDZd2BJeY2il87Uq2fzHTaxT+gSX8G/UCUro5y+hn?= =?us-ascii?Q?4l8725RMoV52/vszZPm6pX3ClgIFRS3B/COUIRPPaD6edTg=3D?= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1=3BBYAPR01MB3653=3B7=3AS+a?= =?us-ascii?Q?wicWnMVN2mwYdcqjtBtFOscYsc+DKxv5BKZDir9ZJYd3lAeFeSoh/3iTFLqj?= =?us-ascii?Q?WfLCVx//cGhtphPV8O1pMdT2bBZj2SWBBYy6gwYlV3Fam6uR/0zqw2TJ4h8T?= =?us-ascii?Q?JGbRFfftFRp5t+8CA/FrwL8WdDTfYQDQXKlOsMrZXjIFoVWEOtfV+ANAEyuC?= =?us-ascii?Q?1VI23c13Wi8T7xOUsTmagY8bn2kTi5idVMCTi5PJIdEfZa0/OIYgqiujmK5N?= =?us-ascii?Q?952LT0PY7tdTm?= X-OriginatorOrg: aclu.org X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jul 2018 18:10:46.5602 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: dfbd928d-17cb-4807-0ac6-08d5e690761f X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 735676e9-2494-4a0f-bf31-4bdea1e91986 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR01MB3653 X-Vaultive-Router: decrypted Archived-At: Subject: Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:11:09 -0000 T24gMDcvMTAvMjAxOCAwMTo0MyBQTSwgRGF2ZSBMYXdyZW5jZSB3cm90ZToNCg0KPiBJbiB0 aGUgbGFyZ2UgSSBhZ3JlZSB3aXRoIHlvdSwgYnV0IEkgdGhpbmsgdGhlcmUncyBtb3JlIHRv IGl0IHRoYW4NCj4gdGhhdC4gIElmIGl0IHB1c2hlZCBtZSBETlNTRUMgcmVjb3JkcyB0aGF0 IEkgY291bGQgdmVyaWZ5IG15c2VsZiBmcm9tDQo+IG15IG93biBjb25maWd1cmVkIHRydXN0 IGFuY2hvciwgd2h5IGNhbid0IEkgdHJ1c3QgdGhlbSB0aGVuPw0KDQphbHRlcm5hdGVseSwg aWYgaSBrbm93IHRoYXQgaSdtIGdvaW5nIHRvIHZlcmlmeSB0aGUgZGF0YSBpbiB0aGVtIHNv bWUNCm90aGVyIHdheSAoZS5nLiB2aWEgWC41MDkgY2VydGlmaWNhdGUgdmVyaWZpY2F0aW9u IGluIGEgVExTIGNvbm5lY3Rpb24pLA0KaXMgaXQgZXZlbiAidHJ1c3QiIHRvIHNheSB0aGF0 IHlvdSBtaWdodCBiZSB3aWxsaW5nIHRvIHRyeSB1c2luZyB0aGUNCmRhdGEgaW4gdGhvc2Ug cmVjb3JkcyB0byBzZWUgd2hldGhlciB5b3UgY2FuIGNyZWF0ZSBhbiBhdXRoZW50aWNhdGVk DQpjb25uZWN0aW9uPw0KDQpJJ20gbm90IHNheWluZyBpdCdzIGEgc2xhbSBkdW5rOiB0aGVy ZSBhcmUgcHJpdmFjeSBjb25jZXJucyBpbiBib3RoDQpkaXJlY3Rpb25zLiBidXQgaSB0aGlu ayB0aGUgc2l0dWF0aW9uIGlzIHZlcnkgY29udGV4dC1zcGVjaWZpYy4gIGNlcnRhaW4NCmNs aWVudHMgaGF2ZSBzcGVjaWZpYyBuZWVkcyBmb3IgdGhlc2UgcmVjb3JkcyB0byB2YWxpZGF0 ZSBpbiBzb21lDQpwYXJ0aWN1bGFyIHdheXMsIGJ1dCBvdGhlciBjbGllbnRzIGhhdmUgZGlm ZmVyZW50IG5lZWRzLiAgSSBob3BlIHRoZQ0KZGlzY3Vzc2lvbiB3aWxsIGJlIHZlcnkgc3Bl Y2lmaWMgYWJvdXQgd2hpY2ggY2xpZW50cyB3ZSdyZSB0YWxraW5nIGFib3V0DQotLSBub3Qg anVzdCB3aGljaCBzcGVjaWZpYyB0cmFuc3BvcnQgdGhlIEROUyByZWNvcmRzIGFycml2ZSBv dmVyLg0KDQoJLS1ka2cNCg0KDQotLSANCkRhbmllbCBLYWhuIEdpbGxtb3INClNlbmlvciBT dGFmZiBUZWNobm9sb2dpc3QNClNwZWVjaCwgUHJpdmFjeSwgYW5kIFRlY2hub2xvZ3kgUHJv amVjdA0KQW1lcmljYW4gQ2l2aWwgTGliZXJ0aWVzIFVuaW9uDQorMS4yMTIuMjg0LjczMzYN Ck9wZW5QR1AgZmluZ2VycHJpbnQ6IDBFRTVCRTk3OTI4MkQ4MEI5Rjc1NDBGMUNDRDJFRDk0 RDIxNzM5RTkNClByb25vdW5zOiBoZS9oaW0vaGlz From nobody Tue Jul 10 11:14:00 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BECA81311A5; Tue, 10 Jul 2018 11:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nt6l760SQ4E8; Tue, 10 Jul 2018 11:13:34 -0700 (PDT) Received: from ppsw-33.csi.cam.ac.uk (ppsw-33.csi.cam.ac.uk [131.111.8.133]) (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 90936130F04; Tue, 10 Jul 2018 11:13:34 -0700 (PDT) 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]:37534) by ppsw-33.csi.cam.ac.uk (ppsw.cam.ac.uk [131.111.8.139]:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1fcx8k-000b7f-gQ (Exim 4.91) (return-path ); Tue, 10 Jul 2018 19:13:30 +0100 Date: Tue, 10 Jul 2018 19:13:29 +0100 From: Tony Finch To: Dave Lawrence cc: Paul Vixie , DoH WG , driu@ietf.org, Ben Schwartz , dnsop , Patrick McManus , Daniel Kahn Gillmor , HTTP Working Group In-Reply-To: <23364.61514.267429.409048@gro.dd.org> Message-ID: References: <5B447154.5010307@redbarn.org> <23364.61514.267429.409048@gro.dd.org> User-Agent: Alpine 2.11 (DEB 23 2013-08-11) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Archived-At: Subject: Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:13:49 -0000 Dave Lawrence wrote: > > In the large I agree with you, but I think there's more to it than > that. If it pushed me DNSSEC records that I could verify myself from > my own configured trust anchor, why can't I trust them then? I've been idly wondering about this from the point of view of RFC 2181 trust ranking: to what extent does it make sense to promote the rank of data (e.g. additional records) that has been validated? The risk, I think, is replaying stale data - there shouldn't be any worse consequences. So it should amount to a DoS attack (and there are easier ways to achieve one of those). Tony. -- f.anthony.n.finch http://dotat.at/ Shannon: Northerly 3 or 4, occasionally 5 in east. Moderate. Mainly fair. Good. From nobody Tue Jul 10 11:46:04 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2875130EAA; Tue, 10 Jul 2018 11:09:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 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, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 8edN_97smWhc; Tue, 10 Jul 2018 11:09:39 -0700 (PDT) Received: from NAM05-BY2-obe.outbound.protection.outlook.com (mail-eopbgr710110.outbound.protection.outlook.com [40.107.71.110]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18A2E131036; Tue, 10 Jul 2018 11:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=k9BZoUmLZ12sPFY6boOH52R0h7rbFM2eySAoMhW1DjA=; b=s7YIRkT4wtA0WSKFcJI2lBuZmdpAPwxViBQi8xMRzd2FrvoBYbzM8dMIkqJ/T1Qw++bnYVQSN7EN/4B2rsynqaFXOWF++TnAOXOVm79jBz2vFQj+e8Sho2W1n0P/pzdUDLmy653GLjv0J/AHm0kpUulHEQaEsggJjIf3ZQ24Kg0= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4903.namprd08.prod.outlook.com (20.176.255.96) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.20; Tue, 10 Jul 2018 18:09:34 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::2080:90d4:850e:af3]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::2080:90d4:850e:af3%2]) with mapi id 15.20.0952.017; Tue, 10 Jul 2018 18:09:34 +0000 From: Mike Bishop To: Ryan Sleevi , Adam Roach CC: Ted Lemon , Joe Abley , DoH WG , "driu@ietf.org" , dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group Thread-Topic: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal Thread-Index: AQHUGHcUEnMDtFq0KECSgsWzR+27KaSIv4hg Date: Tue, 10 Jul 2018 18:09:34 +0000 Message-ID: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.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=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB4903; 7:JTavA3z8oo217M6erlWzeqkgZ4iDn0tvPxzFCjnBkj7XhMn7+H7StFADGupE1nCM5Ek/j6cFbdc5Dgn2a+7dy40Ue7Nlu37lW0k4rzQvfnajybPjlFhGMxobmnMRbAOoDgqA8W8WCSy8Sc1WUYJQ28Id0OJRZeK0/sXL1PNp3nc4h32N2vzTdbudmiQOcBCk2aFLKtikb/M362Jk6nX/rlA8B0/6xkzeVgk4YE46ZNYeHOLwk0Kum4ufhz6bOJge x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: f76556fb-7879-4bcf-4252-08d5e6904a9a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600053)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4903; x-ms-traffictypediagnostic: BYAPR08MB4903: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(192374486261705)(21748063052155); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231311)(944501410)(52105095)(93006095)(93001095)(10201501046)(149027)(150027)(6041310)(20161123558120)(2016111802025)(20161123564045)(20161123562045)(20161123560045)(6072148)(6043046)(201708071742011)(7699016); SRVR:BYAPR08MB4903; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4903; x-forefront-prvs: 0729050452 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(136003)(366004)(396003)(39830400003)(199004)(189003)(25786009)(106356001)(14454004)(966005)(74482002)(11346002)(186003)(68736007)(26005)(45080400002)(478600001)(105586002)(76176011)(446003)(86362001)(7696005)(5070765005)(316002)(476003)(6506007)(53546011)(110136005)(99286004)(486006)(102836004)(54906003)(33656002)(236005)(74316002)(55016002)(9686003)(6306002)(93886005)(7736002)(54896002)(8936002)(8676002)(81156014)(81166006)(66066001)(53936002)(256004)(14444005)(229853002)(4326008)(97736004)(6116002)(2900100001)(6436002)(3846002)(790700001)(5660300001)(7416002)(19609705001)(5250100002)(53386004)(6246003)(2906002)(606006); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4903; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: U+BdcX6mwRUFbJ4Ikn/doYbxngkiyu3crljeQOtugikpKO2PlH9nGXF82W5KF8BWWi7RnY9Iiy6Iyeqhp4D/4akQMqo1tct2xj1twOWkjqho/SNml8BI+JDbENdWjf2xoHrka1l5/wTGIAYOUHXjCURZ3AanFgiGhCCGyNtJ1HsX2TwP/UBUocuDdwmvfu7pA07Z3Cl+kO/eIj/atdTUkJXfM1eA/foXeG0Yjl97uKQS4uoDJzdMD1x8u0waOI+jur+pKHc59+wt764m9JTP1a7MJG1NRJp/wTTCuyXnODnVJ0c+9uaX1KY/ZW3ZQDYpvBtAEInEwbB9DaeHe7i65RXdvmisMse793PTeX0L/TA= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BYAPR08MB3944C30A1016F6978EA325F8DA5B0BYAPR08MB3944namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: f76556fb-7879-4bcf-4252-08d5e6904a9a X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jul 2018 18:09:34.1283 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4903 Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 11:46:03 -0700 Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:09:43 -0000 --_000_BYAPR08MB3944C30A1016F6978EA325F8DA5B0BYAPR08MB3944namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGUgbXVsdGktQ0ROIGNhc2UgaXMgdGhlIHNjYXJpZXN0IGFzcGVjdCBvZiBjb2FsZXNj aW5nIGFuZCB0aGUgdmFyaW91cyBETlMgdHJpY2tzIHdl4oCZdmUgYmVlbiBkb2luZyBpbiByZWNl bnQgeWVhcnMuICBUaGUgc2VydmVyIG1heSBub3QgYmUgbWFsaWNpb3VzLCBtYXkgbm90IGV2ZW4g YmUgbWlzY29uZmlndXJlZCDigJMgc2l0ZSBYIHVzZXMgRE5TIHRvIGR5bmFtaWNhbGx5IHNoYXJl IGxvYWQgYmV0d2VlbiBDRE5zIEEgYW5kIEYuICBJZiBYIGRlY2lkZXMgdG8gc3RhcnQgbW92aW5n IG1vcmUgbG9hZCB0byBBLCBGIGNvdWxkIGluIGFsbCBnb29kIGZhaXRoIGNvbnRpbnVlIHRvIHJv dXRlIGNsaWVudHMgdG8gaXRzZWxmIGJ5IHByb3ZpZGluZyBjYWNoZWQsIHNpZ25lZCBETlMgcmVj b3Jkcy4NCg0KVGhlIGluZHVzdHJ5IG5vcm0gaXMgdGhhdCBjaGFuZ2luZyB0aGUgRE5TIHJlY29y ZOKAmXMgQ05BTUUgdG8gYSBkaWZmZXJlbnQgQ0ROIGlzIHRoZSBjdXQtb3ZlciwgcmVnYXJkbGVz cyBvZiB3aGV0aGVyIHRoZSBvdGhlciBDRE4gcmVtYWlucyBjb25maWd1cmVkLiAgSXTigJlzIGVm ZmVjdGl2ZWx5IGFjdGluZyBhcyBhIOKAnGhvdCBzdGFuZGJ5LuKAnSAgSWYgaXQgaGFkIHRvIHBy b3ZpZGVkIGJldHRlciBwcm9vZiBvZiBmcmVzaG5lc3MsIHRoYXQgbWlnaHQgYmUgc3VmZmljaWVu dCwgYnV0IGhvdyBmcmVzaCBpcyBzdWZmaWNpZW50bHkgZnJlc2g/ICBBbmQgZG9lcyBETlNTRUMg cHJvdmlkZSB0aGF0IGZyZXNobmVzcyBndWFyYW50ZWU/DQoNCkhvd2V2ZXIsIEYgY291bGQgZG8g dGhpcyB0b2RheSB3aXRoIEFsdC1TdmMgYW5kIGhhdmUgdGhlIHNhbWUgaW1wYWN0LiAgU2Vjb25k YXJ5IENlcnRpZmljYXRlcyBwcm92aWRlcyBhbm90aGVyIHdheSB0aGlzIG1pZ2h0IGhhcHBlbi4g IFNvIHRoaXMgc2hpcCBtaWdodCBoYXZlIGFscmVhZHkgc2FpbGVkLg0KDQpGcm9tOiBSeWFuIFNs ZWV2aSBbbWFpbHRvOnJ5YW4taWV0ZkBzbGVldmkuY29tXQ0KU2VudDogVHVlc2RheSwgSnVseSAx MCwgMjAxOCAxMDo1MiBBTQ0KVG86IEFkYW0gUm9hY2ggPGFkYW1Abm9zdHJ1bS5jb20+DQpDYzog VGVkIExlbW9uIDxtZWxsb25AZnVndWUuY29tPjsgSm9lIEFibGV5IDxqYWJsZXlAaG9wY291bnQu Y2E+OyBEb0ggV0cgPGRvaEBpZXRmLm9yZz47IGRyaXVAaWV0Zi5vcmc7IGRuc29wIFdHIDxkbnNv cEBpZXRmLm9yZz47IFBhdWwgV291dGVycyA8cGF1bEBub2hhdHMuY2E+OyBQYXRyaWNrIE1jTWFu dXMgPHBtY21hbnVzQG1vemlsbGEuY29tPjsgUGhpbGlwIEhvbWJ1cmcgPHBjaC1kbnNvcC0zQHUt MS5waGljb2guY29tPjsgSFRUUCBXb3JraW5nIEdyb3VwIDxpZXRmLWh0dHAtd2dAdzMub3JnPg0K U3ViamVjdDogUmU6IFtEcml1XSBbRE5TT1BdIFtEb2hdIFJlc29sdmVybGVzcyBETlMgU2lkZSBN ZWV0aW5nIGluIE1vbnRyZWFsDQoNCg0KDQpPbiBUdWUsIEp1bCAxMCwgMjAxOCBhdCAxOjA1IFBN LCBBZGFtIFJvYWNoIDxhZGFtQG5vc3RydW0uY29tPG1haWx0bzphZGFtQG5vc3RydW0uY29tPj4g d3JvdGU6DQpPbiA3LzEwLzE4IDExOjQxIEFNLCBUZWQgTGVtb24gd3JvdGU6DQpPbiBUdWUsIEp1 bCAxMCwgMjAxOCBhdCAxMjozNCBQTSwgSm9lIEFibGV5IDxqYWJsZXlAaG9wY291bnQuY2E8bWFp bHRvOmphYmxleUBob3Bjb3VudC5jYT4+IHdyb3RlOg0KPiBCdXQgdGhpcyBpcyByZWFsbHkgZXF1 aXZhbGVudCBpbiBqdXN0IGFib3V0IGV2ZXJ5IGltcG9ydGFudCB3YXkgdG8gc2VuZGluZyB0aGUg bm9ybWFsIDxpbWcgc3JjPSJodHRwczovL2V4YW1wbGUuY29tL2ltZy9mLmpwZyI+IGFsb25nIHdp dGggYSBwdXNoZWQgRE5TIHJlY29yZCB0aGF0IGluZGljYXRlcyB0aGF0ICJleGFtcGxlLmNvbTxo dHRwOi8vZXhhbXBsZS5jb20+IiByZXNvbHZlcyB0byAiMTkyLjAuMi4xIiAtLSBhbmQgdGhpcyBs YXR0ZXIgdGhpbmcgaXMgKHRvIG15IHVuZGVyc3RhbmRpbmcsIGF0IGxlYXN0KSBpbiBzY29wZSBv ZiB0aGUgY29udmVyc2F0aW9uIHRoYXQgUGF0cmljayBpcyBwcm9wb3NpbmcgdG8gaGF2ZS4NCg0K TXkgcXVlc3Rpb24gaXMgd2h5IHlvdSB3b3VsZCBpbnZvbHZlIHRoZSBETlMgYXQgYWxsIGlmIGFs bCB0aGUNCnBlcmZvcm1hbmNlLWJhc2VkIHJlc29sdXRpb24gZGVjaXNpb25zIGNhbiBiZSBtYWRl IHdpdGhvdXQgaXQuIFlvdSdyZQ0KanVzdCBhZGRpbmcgY29zdCBhbmQgY29tcGxleGl0eSB3aXRo b3V0IGJlbmVmaXQNCg0KVGhlIGlwPSBtb2RpZmllciB3b3VsZCBiZSBhIGdyZWF0IHdheSB0byBh cnJhbmdlIGZvciBzb21ldGhpbmcgdG8gbG9vayBsaWtlIGl0IGNhbWUgZnJvbSBhIGRpZmZlcmVu dCBzb3VyY2UgdGhhbiBpdHMgYWN0dWFsIHNvdXJjZS4gICBJJ20gc3VyZSB0aGVyZSdzIGFuIGF0 dGFjayBzdXJmYWNlIGluIHRoZXJlIHNvbWV3aGVyZS4NCg0KDQoNCktlZXBpbmcgaW4gbWluZCB0 aGF0IHRoZSBjZXJ0aWZpY2F0ZSBwcm92aWRlZCBieSB3aGF0ZXZlciBtYWNoaW5lIHlvdSByZWFj aGVkIHdvdWxkIG5lY2Vzc2FyaWx5IGhhdmUgdG8gbWF0Y2ggdGhlIFVSTCdzIG9yaWdpbiwgdGhp cyBpcyB2ZXJ5IG11Y2ggb25lIG9mIHRoZSBxdWVzdGlvbnMgdGhhdCBpcyBiZWluZyBhc2tlZDog aXMgdGhlcmU/DQoNCi9hDQpZZXMuIENvbnNpZGVyIFNpdGUgQSAoZm9vLmV4YW1wbGUpIGFuZCBT aXRlIEIgKGJhci5leGFtcGxlKS4gQm90aCBwb2ludCB0aGVtc2VsdmVzIHRvIENETiAxLCB3aGlj aCB0aGVuIG9idGFpbnMgYSBjZXJ0aWZpY2F0ZSBmb3IgYm90aCB0aGVpciBuYW1lcyBpbiBzdWJq ZWN0QWx0TmFtZXMuIFNpdGUgQiB0aGVuIGRlY2lkZXMgdGhhdCBDRE4gMSBpcyBhbiB1bnJlbGlh YmxlIHBhcnRuZXIsIGFuZCBnb2VzIENETiAyLCB1cGRhdGluZyBETlMgYXBwcm9wcmlhdGVseS4N Cg0KVGhpcyBpcyB0aGUgc2FtZSBwcm9ibGVtIGluIGNvbnNpZGVyaW5nIHRoZSBIVFRQLzIgY29h bGVzY2luZyB3aXRob3V0IGRvaW5nIEROUyByZXNvbHV0aW9uIChlaXRoZXIgYmVjYXVzZSBvZiBw b29yIHNlY3VyaXR5IHBvc3R1cmUgb3IgYnkgY29tYmluaW5nIE9SSUdJTiArIFNlY29uZGFyeSBD ZXJ0aWZpY2F0ZXMpLiBSRkMgODMzNiBicmllZmx5IHRvdWNoZXMgb24gdGhpcyAoIGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM4MzM2I3NlY3Rpb24tNCApIGJ1dCBkb2Vzbid0IHJlYWxs eSBleHBsb3JlIHRoZSBwb2xpY3kgaW1wbGljYXRpb25zIG9mIHRoZSBwcm9wb3NlZCBvciByZWNv bW1lbmRlZCBtaXRpZ2F0aW9ucy4NCg0KSWYgeW91IHN0YXJ0IHdpdGggbm8gbWl0aWdhdGlvbnMs IHRoZSBuZXQgZWZmZWN0IG9mIGJvdGggYW4gaXA9IG9yIGEgRE5TLWlnbm9yaW5nIE9SSUdJTiBm cmFtZSBpcyB0byBlZmZlY3RpdmVseSB0cmVhdCB0aGUgY2VydGlmaWNhdGUgYXMgYSA4MjUtZGF5 IEROUyBUVEwuIEJ5IGZyYW1pbmcgdGhlIHByb2JsZW0gYXMgIldoYXQncyB0aGUgd29yc3QgdGhh dCBjb3VsZCBoYXBwZW4gaWYgRE5TIGVudHJpZXMgaGFkIHRoZWlyIFRUTHMgaWdub3JlZCBhbmQg d2VyZSBjYWNoZWQgZm9yIDgyNSBkYXlzIiwgdGhhdCBtaWdodCBoZWxwIGV4cGxvcmUgdGhpbmdz IGZ1cnRoZXIuIFRoZSBzdWdnZXN0aW9uIG9mIE9DU1AgcmVkdWNlcyB0aGF0IFRUTCB0byA3IGRh eXMgKGVmZmVjdGl2ZWx5OyBkdWUgdG8gTWljcm9zb2Z0J3MgY29udHJhY3R1YWwgcmVxdWlyZW1l bnRzIG9uIHB1YmxpY2x5IHRydXN0ZWQgQ0FzKSwgYnV0IHRoYXQncyBzdGlsbCBzdWJzdGFudGlh bGx5IGxvbmdlci4NCg0KVGhhdCdzIHdoeSBpbnZvbHZpbmcgRE5TIGlzIGF0IGxlYXN0IHJlbGV2 YW50IHRvIHRoYXQgZGlzY3Vzc2lvbiwgZXNwZWNpYWxseSBnaXZlbiB0aGF0IHB1YmxpY2x5IHRy dXN0ZWQgY2VydGlmaWNhdGVzIGFyZSB0aGVtc2VsdmVzIHByZWRpY2F0ZWQgb24gRE5TLiBGdXJ0 aGVyLCBjb25zaWRlcmluZyB0aGF0IHRoZSBDQSBvbmx5IGhhcyB0byB2YWxpZGF0ZSBhIEROUyBv bmNlIHBlciA4MjUtZGF5IHBlcmlvZCwgYW5kIGNhbiBpc3N1ZSB1bmxpbWl0ZWQgODI1LWRheSBj ZXJ0aWZpY2F0ZXMgZHVyaW5nIHRoYXQgcGVyaW9kLCB0aGVuIHRoZSBlZmZlY3RpdmUgZXh0ZW5z aW9uIG9mIHJlbHlpbmcgc29sZWx5IG9uIGNlcnRpZmljYXRlcyAxNjUwIGRheXMgbWludXMgYSBz ZWNvbmQuDQo= --_000_BYAPR08MB3944C30A1016F6978EA325F8DA5B0BYAPR08MB3944namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21zby1zdHls ZS1uYW1lOmdtYWlsLTt9DQpzcGFuLmdtYWlsLWhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpnbWFp bC1ob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgdGhlIG11bHRpLUNETiBjYXNl IGlzIHRoZSBzY2FyaWVzdCBhc3BlY3Qgb2YgY29hbGVzY2luZyBhbmQgdGhlIHZhcmlvdXMgRE5T IHRyaWNrcyB3ZeKAmXZlIGJlZW4gZG9pbmcgaW4gcmVjZW50IHllYXJzLiZuYnNwOyBUaGUgc2Vy dmVyIG1heSBub3QgYmUgbWFsaWNpb3VzLCBtYXkgbm90IGV2ZW4gYmUgbWlzY29uZmlndXJlZCDi gJMgc2l0ZSBYIHVzZXMgRE5TIHRvIGR5bmFtaWNhbGx5IHNoYXJlIGxvYWQgYmV0d2Vlbg0KIENE TnMgQSBhbmQgRi4mbmJzcDsgSWYgWCBkZWNpZGVzIHRvIHN0YXJ0IG1vdmluZyBtb3JlIGxvYWQg dG8gQSwgRiBjb3VsZCBpbiBhbGwgZ29vZCBmYWl0aCBjb250aW51ZSB0byByb3V0ZSBjbGllbnRz IHRvIGl0c2VsZiBieSBwcm92aWRpbmcgY2FjaGVkLCBzaWduZWQgRE5TIHJlY29yZHMuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpbmR1c3RyeSBub3JtIGlzIHRoYXQgY2hhbmdpbmcgdGhl IEROUyByZWNvcmTigJlzIENOQU1FIHRvIGEgZGlmZmVyZW50IENETiBpcyB0aGUgY3V0LW92ZXIs IHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGUgb3RoZXIgQ0ROIHJlbWFpbnMgY29uZmlndXJlZC4m bmJzcDsgSXTigJlzIGVmZmVjdGl2ZWx5IGFjdGluZyBhcyBhIOKAnGhvdCBzdGFuZGJ5LuKAnSZu YnNwOyBJZiBpdCBoYWQgdG8gcHJvdmlkZWQgYmV0dGVyIHByb29mIG9mIGZyZXNobmVzcywNCiB0 aGF0IG1pZ2h0IGJlIHN1ZmZpY2llbnQsIGJ1dCBob3cgZnJlc2ggaXMgc3VmZmljaWVudGx5IGZy ZXNoPyZuYnNwOyBBbmQgZG9lcyBETlNTRUMgcHJvdmlkZSB0aGF0IGZyZXNobmVzcyBndWFyYW50 ZWU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvd2V2ZXIsIEYgY291bGQgZG8gdGhpcyB0b2Rh eSB3aXRoIEFsdC1TdmMgYW5kIGhhdmUgdGhlIHNhbWUgaW1wYWN0LiZuYnNwOyBTZWNvbmRhcnkg Q2VydGlmaWNhdGVzIHByb3ZpZGVzIGFub3RoZXIgd2F5IHRoaXMgbWlnaHQgaGFwcGVuLiZuYnNw OyBTbyB0aGlzIHNoaXAgbWlnaHQgaGF2ZSBhbHJlYWR5IHNhaWxlZC48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+RnJvbTo8L2I+IFJ5YW4gU2xlZXZpIFttYWlsdG86cnlhbi1pZXRmQHNsZWV2 aS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdWx5IDEwLCAyMDE4IDEwOjUyIEFN PGJyPg0KPGI+VG86PC9iPiBBZGFtIFJvYWNoICZsdDthZGFtQG5vc3RydW0uY29tJmd0Ozxicj4N CjxiPkNjOjwvYj4gVGVkIExlbW9uICZsdDttZWxsb25AZnVndWUuY29tJmd0OzsgSm9lIEFibGV5 ICZsdDtqYWJsZXlAaG9wY291bnQuY2EmZ3Q7OyBEb0ggV0cgJmx0O2RvaEBpZXRmLm9yZyZndDs7 IGRyaXVAaWV0Zi5vcmc7IGRuc29wIFdHICZsdDtkbnNvcEBpZXRmLm9yZyZndDs7IFBhdWwgV291 dGVycyAmbHQ7cGF1bEBub2hhdHMuY2EmZ3Q7OyBQYXRyaWNrIE1jTWFudXMgJmx0O3BtY21hbnVz QG1vemlsbGEuY29tJmd0OzsgUGhpbGlwIEhvbWJ1cmcgJmx0O3BjaC1kbnNvcC0zQHUtMS5waGlj b2guY29tJmd0OzsgSFRUUA0KIFdvcmtpbmcgR3JvdXAgJmx0O2lldGYtaHR0cC13Z0B3My5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbRHJpdV0gW0ROU09QXSBbRG9oXSBSZXNvbHZl cmxlc3MgRE5TIFNpZGUgTWVldGluZyBpbiBNb250cmVhbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g VHVlLCBKdWwgMTAsIDIwMTggYXQgMTowNSBQTSwgQWRhbSBSb2FjaCAmbHQ7PGEgaHJlZj0ibWFp bHRvOmFkYW1Abm9zdHJ1bS5jb20iIHRhcmdldD0iX2JsYW5rIj5hZGFtQG5vc3RydW0uY29tPC9h PiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiA3LzEwLzE4IDExOjQxIEFNLCBUZWQgTGVtb24gd3JvdGU6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJnbWFpbC0iPk9uIFR1ZSwgSnVsIDEwLCAyMDE4IGF0IDEyOjM0IFBNLCBKb2Ug QWJsZXkgJmx0OzxhIGhyZWY9Im1haWx0bzpqYWJsZXlAaG9wY291bnQuY2EiIHRhcmdldD0iX2Js YW5rIj5qYWJsZXlAaG9wY291bnQuY2E8L2E+Jmd0OyB3cm90ZTo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBjbGFzcz0iZ21haWwtIj4mZ3Q7IEJ1dCB0aGlzIGlzIHJlYWxseSBlcXVpdmFsZW50IGluIGp1 c3QgYWJvdXQgZXZlcnkgaW1wb3J0YW50IHdheSB0byBzZW5kaW5nIHRoZSBub3JtYWwgJmx0O2lt ZyBzcmM9JnF1b3Q7PGEgaHJlZj0iaHR0cHM6Ly9leGFtcGxlLmNvbS9pbWcvZi5qcGciIHRhcmdl dD0iX2JsYW5rIj5odHRwczovL2V4YW1wbGUuY29tL2ltZy9mLmpwZzwvYT4mcXVvdDsmZ3Q7IGFs b25nIHdpdGggYSBwdXNoZWQgRE5TIHJlY29yZA0KIHRoYXQgaW5kaWNhdGVzIHRoYXQgJnF1b3Q7 PGEgaHJlZj0iaHR0cDovL2V4YW1wbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZXhhbXBsZS5jb208 L2E+JnF1b3Q7IHJlc29sdmVzIHRvICZxdW90OzE5Mi4wLjIuMSZxdW90OyAtLSBhbmQgdGhpcyBs YXR0ZXIgdGhpbmcgaXMgKHRvIG15IHVuZGVyc3RhbmRpbmcsIGF0IGxlYXN0KSBpbiBzY29wZSBv ZiB0aGUgY29udmVyc2F0aW9uIHRoYXQgUGF0cmljayBpcyBwcm9wb3NpbmcgdG8gaGF2ZS48L3Nw YW4+PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImdtYWlsLSI+TXkgcXVlc3Rpb24gaXMgd2h5IHlv dSB3b3VsZCBpbnZvbHZlIHRoZSBETlMgYXQgYWxsIGlmIGFsbCB0aGU8L3NwYW4+PGJyPg0KPHNw YW4gY2xhc3M9ImdtYWlsLSI+cGVyZm9ybWFuY2UtYmFzZWQgcmVzb2x1dGlvbiBkZWNpc2lvbnMg Y2FuIGJlIG1hZGUgd2l0aG91dCBpdC4gWW91J3JlPC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJn bWFpbC0iPmp1c3QgYWRkaW5nIGNvc3QgYW5kIGNvbXBsZXhpdHkgd2l0aG91dCBiZW5lZml0PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIGlwPSBtb2RpZmllciB3b3VsZCBiZSBhIGdyZWF0IHdheSB0byBhcnJhbmdl IGZvciBzb21ldGhpbmcgdG8gbG9vayBsaWtlIGl0IGNhbWUgZnJvbSBhIGRpZmZlcmVudCBzb3Vy Y2UgdGhhbiBpdHMgYWN0dWFsIHNvdXJjZS4gJm5ic3A7IEknbSBzdXJlIHRoZXJlJ3MgYW4gYXR0 YWNrIHN1cmZhY2UgaW4gdGhlcmUgc29tZXdoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cD48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwPktlZXBpbmcgaW4gbWluZCB0aGF0IHRoZSBjZXJ0aWZpY2F0ZSBwcm92aWRlZCBi eSB3aGF0ZXZlciBtYWNoaW5lIHlvdSByZWFjaGVkIHdvdWxkIG5lY2Vzc2FyaWx5IGhhdmUgdG8g bWF0Y2ggdGhlIFVSTCdzIG9yaWdpbiwgdGhpcyBpcyB2ZXJ5IG11Y2ggb25lIG9mIHRoZSBxdWVz dGlvbnMgdGhhdCBpcyBiZWluZyBhc2tlZDogaXMgdGhlcmU/PG86cD48L286cD48L3A+DQo8cD48 c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+L2E8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLiBDb25z aWRlciBTaXRlIEEgKGZvby5leGFtcGxlKSBhbmQgU2l0ZSBCIChiYXIuZXhhbXBsZSkuIEJvdGgg cG9pbnQgdGhlbXNlbHZlcyB0byBDRE4gMSwgd2hpY2ggdGhlbiBvYnRhaW5zIGEgY2VydGlmaWNh dGUgZm9yIGJvdGggdGhlaXIgbmFtZXMgaW4gc3ViamVjdEFsdE5hbWVzLiBTaXRlIEIgdGhlbiBk ZWNpZGVzIHRoYXQgQ0ROIDEgaXMgYW4gdW5yZWxpYWJsZSBwYXJ0bmVyLCBhbmQgZ29lcyBDRE4N CiAyLCB1cGRhdGluZyBETlMgYXBwcm9wcmlhdGVseS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBpcyB0aGUgc2FtZSBwcm9ibGVtIGlu IGNvbnNpZGVyaW5nIHRoZSBIVFRQLzIgY29hbGVzY2luZyB3aXRob3V0IGRvaW5nIEROUyByZXNv bHV0aW9uIChlaXRoZXIgYmVjYXVzZSBvZiBwb29yIHNlY3VyaXR5IHBvc3R1cmUgb3IgYnkgY29t YmluaW5nIE9SSUdJTiAmIzQzOyBTZWNvbmRhcnkgQ2VydGlmaWNhdGVzKS4gUkZDIDgzMzYgYnJp ZWZseSB0b3VjaGVzIG9uIHRoaXMgKCZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9yZmM4MzM2I3NlY3Rpb24tNCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3Jm YzgzMzYjc2VjdGlvbi00PC9hPg0KICkgYnV0IGRvZXNuJ3QgcmVhbGx5IGV4cGxvcmUgdGhlIHBv bGljeSBpbXBsaWNhdGlvbnMgb2YgdGhlIHByb3Bvc2VkIG9yIHJlY29tbWVuZGVkIG1pdGlnYXRp b25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JZiB5b3Ugc3RhcnQgd2l0aCBubyBtaXRpZ2F0aW9ucywgdGhlIG5ldCBlZmZlY3Qgb2YgYm90 aCBhbiBpcD0gb3IgYSBETlMtaWdub3JpbmcgT1JJR0lOIGZyYW1lIGlzIHRvIGVmZmVjdGl2ZWx5 IHRyZWF0IHRoZSBjZXJ0aWZpY2F0ZSBhcyBhIDgyNS1kYXkgRE5TIFRUTC4gQnkgZnJhbWluZyB0 aGUgcHJvYmxlbSBhcyAmcXVvdDtXaGF0J3MgdGhlIHdvcnN0IHRoYXQgY291bGQgaGFwcGVuIGlm IEROUyBlbnRyaWVzIGhhZA0KIHRoZWlyIFRUTHMgaWdub3JlZCBhbmQgd2VyZSBjYWNoZWQgZm9y IDgyNSBkYXlzJnF1b3Q7LCB0aGF0IG1pZ2h0IGhlbHAgZXhwbG9yZSB0aGluZ3MgZnVydGhlci4g VGhlIHN1Z2dlc3Rpb24gb2YgT0NTUCByZWR1Y2VzIHRoYXQgVFRMIHRvIDcgZGF5cyAoZWZmZWN0 aXZlbHk7IGR1ZSB0byBNaWNyb3NvZnQncyBjb250cmFjdHVhbCByZXF1aXJlbWVudHMgb24gcHVi bGljbHkgdHJ1c3RlZCBDQXMpLCBidXQgdGhhdCdzIHN0aWxsIHN1YnN0YW50aWFsbHkgbG9uZ2Vy LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U aGF0J3Mgd2h5IGludm9sdmluZyBETlMgaXMgYXQgbGVhc3QgcmVsZXZhbnQgdG8gdGhhdCBkaXNj dXNzaW9uLCBlc3BlY2lhbGx5IGdpdmVuIHRoYXQgcHVibGljbHkgdHJ1c3RlZCBjZXJ0aWZpY2F0 ZXMgYXJlIHRoZW1zZWx2ZXMgcHJlZGljYXRlZCBvbiBETlMuIEZ1cnRoZXIsIGNvbnNpZGVyaW5n IHRoYXQgdGhlIENBIG9ubHkgaGFzIHRvIHZhbGlkYXRlIGEgRE5TIG9uY2UgcGVyIDgyNS1kYXkg cGVyaW9kLA0KIGFuZCBjYW4gaXNzdWUgdW5saW1pdGVkIDgyNS1kYXkgY2VydGlmaWNhdGVzIGR1 cmluZyB0aGF0IHBlcmlvZCwgdGhlbiB0aGUgZWZmZWN0aXZlIGV4dGVuc2lvbiBvZiByZWx5aW5n IHNvbGVseSBvbiBjZXJ0aWZpY2F0ZXMgMTY1MCBkYXlzIG1pbnVzIGEgc2Vjb25kLiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR08MB3944C30A1016F6978EA325F8DA5B0BYAPR08MB3944namp_-- From nobody Tue Jul 10 15:39:00 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40CF5131052; Tue, 10 Jul 2018 11:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sleevi.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 TCO7Gzya_x2R; Tue, 10 Jul 2018 11:57:26 -0700 (PDT) Received: from homiemail-a129.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07E81130E51; Tue, 10 Jul 2018 11:57:25 -0700 (PDT) Received: from homiemail-a129.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a129.g.dreamhost.com (Postfix) with ESMTP id 614F010002181; Tue, 10 Jul 2018 11:57:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=NMzpBgH2U2T5q54GvtwFqGAauEY=; b= NCDWlsEVSi7jzISpcBch+daRshwVdcBtuZOsU++CA0HC+NWXHyE9H4eeTFDWQc8b RJUH/8kfUThiuv0AAjux+4dW/xO6iT3Qxh9kTeu/5yRuyzlqwBYOGlxlScF/HHF2 OPAkH9XogBlo9Ng7NxlTu08hA0qsE+LloC5RC2+gG2U= Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a129.g.dreamhost.com (Postfix) with ESMTPSA id 51CC410002180; Tue, 10 Jul 2018 11:57:25 -0700 (PDT) Received: by mail-it0-f47.google.com with SMTP id p185-v6so127200itp.4; Tue, 10 Jul 2018 11:57:25 -0700 (PDT) X-Gm-Message-State: APt69E2WF8f3cRuhS51sAn9dKNDGpwwp0AoSFPenPbtoX8052mJ/yNac AhDHFHOxxYgLz+Mob9ApmXHCSX1yk9IG5GBIMi8= X-Google-Smtp-Source: AAOMgpf29o/XI/QmgdbET3+qmN80+ur+RYo1h4RZGDrLvB4XnOred8MZcckL5u3Ia8MiCAPhh5JZv36/tMWwwHNTXQ0= X-Received: by 2002:a24:684d:: with SMTP id v74-v6mr20894074itb.88.1531249044728; Tue, 10 Jul 2018 11:57:24 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a02:244:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 11:57:24 -0700 (PDT) In-Reply-To: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> From: Ryan Sleevi Date: Tue, 10 Jul 2018 14:57:24 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Mike Bishop Cc: Ryan Sleevi , Adam Roach , Ted Lemon , Joe Abley , DoH WG , "driu@ietf.org" , dnsop WG , Paul Wouters , Patrick McManus , Philip Homburg , HTTP Working Group Content-Type: multipart/alternative; boundary="0000000000005fba590570a9b393" Archived-At: X-Mailman-Approved-At: Tue, 10 Jul 2018 15:38:58 -0700 Subject: Re: [Driu] [DNSOP] [Doh] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jul 2018 18:57:29 -0000 --0000000000005fba590570a9b393 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop wrote: > Yes, the multi-CDN case is the scariest aspect of coalescing and the > various DNS tricks we=E2=80=99ve been doing in recent years. The server = may not be > malicious, may not even be misconfigured =E2=80=93 site X uses DNS to dyn= amically > share load between CDNs A and F. If X decides to start moving more load = to > A, F could in all good faith continue to route clients to itself by > providing cached, signed DNS records. > Yup. And, at least for browsers that follow a Priority of Constituency model, it seems more important to ensure that site operators wishes are respected over that of the CDNs they've used, or for their being a more explicit signal from the user that it truly intends to ignore the site operator. > > > The industry norm is that changing the DNS record=E2=80=99s CNAME to a di= fferent > CDN is the cut-over, regardless of whether the other CDN remains > configured. It=E2=80=99s effectively acting as a =E2=80=9Chot standby.= =E2=80=9D If it had to > provided better proof of freshness, that might be sufficient, but how fre= sh > is sufficiently fresh? And does DNSSEC provide that freshness guarantee? > Right, these are questions that need to be answered, and not just with abstract theoretical mitigations that don't or can't be deployed. > However, F could do this today with Alt-Svc and have the same impact. > Secondary Certificates provides another way this might happen. So this > ship might have already sailed. > The ship has only sailed for those foolish enough to ship those features :) That is, these are real security concerns, they have not been satisfactorily addressed, and security conscious implementations have held off implementing these features for precisely this reason. If there are implementations that have shipped, without understanding or considering the security harm they're doing, that doesn't seem like a good argument to keep building more features on the buggy premise. If they believe they have sufficiently mitigated those very real and practical security concerns, they would hopefully be sharing those concrete strategies and tradeoffs, rather than a Security Considerations that acknowledges the dragons without adequately describing how to avoid them (or how not to). --0000000000005fba590570a9b393 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop <mbishop@evequefou.be<= /a>> wrote:

Yes, the multi-CDN case is the scariest aspect of co= alescing and the various DNS tricks we=E2=80=99ve been doing in recent year= s.=C2=A0 The server may not be malicious, may not even be misconfigured =E2= =80=93 site X uses DNS to dynamically share load between CDNs A and F.=C2=A0 If X decides to start moving more load to A, F could i= n all good faith continue to route clients to itself by providing cached, s= igned DNS records.


Yup. And= , at least for browsers that follow a Priority of Constituency model, it se= ems more important to ensure that site operators wishes are respected over = that of the CDNs they've used, or for their being a more explicit signa= l from the user that it truly intends to ignore the site operator.
=C2=A0


The ship has only sailed for those foolish e= nough to ship those features :) That is, these are real security concerns, = they have not been satisfactorily addressed, and security conscious impleme= ntations have held off implementing these features for precisely this reaso= n. If there are implementations that have shipped, without understanding or= considering the security harm they're doing, that doesn't seem lik= e a good argument to keep building more features on the buggy premise.

If they believe they have sufficiently mitigated those= very real and practical security concerns, they would hopefully be sharing= those concrete strategies and tradeoffs, rather than a Security Considerat= ions that acknowledges the dragons without adequately describing how to avo= id them (or how not to).
--0000000000005fba590570a9b393-- From nobody Tue Jul 10 18:23:16 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 124E7129C6A; Tue, 10 Jul 2018 18:23:04 -0700 (PDT) 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=mnot.net header.b=g+Yk8hBc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=IvVT9vFs Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDAILX8905zN; Tue, 10 Jul 2018 18:23:02 -0700 (PDT) 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 A42C3127332; Tue, 10 Jul 2018 18:23:02 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id CBC9521B9E; Tue, 10 Jul 2018 21:23:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 10 Jul 2018 21:23:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=EBQI3ObNpEyvbBEkEaz29MaPRXpnC IjpCZ+YWZBgSr4=; b=g+Yk8hBcJMp+m8oWMS2Q2a5VKksfH/m9lLU6Zk6lXiC3n TYCfUlV9L7Cy7FW5+A2u+JUrNJmmlojXjD5x6qLnxLHnirj5uL7l+B5w7hgD+Uf9 WPzdxeJsyTxjJvazpkieLdaYXsNsxO646/rnwM6WMUEBxd6+oIZbbn5SsiMYgQCb 8NtbNGD3DrgBqez0mXiBCEtIYACdKb7lsUwyasLBXGmsUWINYdANzkX2oSmoBRwz dt20Q0iO23y65hNhsepGh1HbbtCyLJ25OKSGbkFKw3FOIwW2Dzpy9TkvvzBoDPRa UNKZr/106mDCTEljuUZsUOx41GxaWlpUk6q7EoZRg== 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=EBQI3O bNpEyvbBEkEaz29MaPRXpnCIjpCZ+YWZBgSr4=; b=IvVT9vFszEsfl6nEpeDy7e IpE91xgpTXCs9vmBpm96BezyeEtorOaSvDNxz5C5zuTiErXcSM/3t+CyJXctS9E2 LSnlVn80DxAM0jDy3XG4AseNUNxnIQQjpFRpokNYgliAHt56kRCnpfS3vFKjnVrp RlgQeDd0+O4jNoOLtzKvzw/y3TDDmyv08lyBPZffTI4AWAUord1abjQHkMDMyOXp pStyeHOC7O3AdCKFetcHac1Vh1pk3IJV4YhxNTlEe4v4nrcpqM7AFde2EPcck0QM I4VsKIhm8Ll21CSr+ImwIZpngrdCe4hJek8hpQWiD2iUH4JCjech1+aymWGII98g == X-ME-Proxy: X-ME-Sender: Received: from attitudadjuster.localdomain (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 4410CE405A; Tue, 10 Jul 2018 21:22:59 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Mark Nottingham In-Reply-To: Date: Wed, 11 Jul 2018 11:22:55 +1000 Cc: Adam Roach , DoH WG , driu@ietf.org, dnsop@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> To: Joe Abley X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: [Driu] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:23:04 -0000 > On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >=20 > On Jul 10, 2018, at 18:02, Adam Roach wrote: >=20 >> In large part because DNS provides "a richer scheme that accommodates = address families and multiple addresses with priorities". >=20 > *cups hand to ear* >=20 > Was that the sound of a distant desire to specify use of SRV for HTTP? >=20 I recently did some digging on this topic, and can try to characterise = what the issues / objections are. Would people be interested in a (hopefully brief) side meeting to = discuss and maybe come to a shared understanding of the problem space? Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 10 18:26:36 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D7D130E9E for ; Tue, 10 Jul 2018 18:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.031 X-Spam-Level: X-Spam-Status: No, score=-1.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 R8Ng6I45x0Oe for ; Tue, 10 Jul 2018 18:26:30 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::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 E6C4A129C6A for ; Tue, 10 Jul 2018 18:26:29 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id w16-v6so761176wmc.2 for ; Tue, 10 Jul 2018 18:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YfCeSR1woNfcgPU/y1hMxw6bD6VluXNZEvLMN7jfyHk=; b=epwzgmBKOYv0Jw4GswxcQ93JuiWnaSLMMnJc2Bee9ek9N3X1appGNHKY5R6/ORumQI uv4sSpgLT9K9YiRnxB1ndIZ/QdK1MJ55A6GcC/+rOAtuQlkoQgiyIX1mbDuefoi/5kUk gHagYi7uW+v9JEoc5F+80co8BJlbrjIa+3tqE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YfCeSR1woNfcgPU/y1hMxw6bD6VluXNZEvLMN7jfyHk=; b=TGO7zGRtKJlRCh8skWlpMXSHVkqdfe6oz4WBUQ7onFquRhqS18gppje0kIxebI1Lb/ kH4AT7R4bM2nit52fvS8jcDkGXVp4q7zziLDdH+K9376iwvjmBUf6cFsadCYUlvst+3w 7H/QhkCRjUqOwJGNGN62jAQzRPFkkOndViHMpgZv4W+EpLP1l/xqdP4NijWhuA9WVBhs pfRmz4+wKohWfeEhhZQ0nMphCv0QOTF7NXmhHCMtlC9+M1Kuc6dXqQYJvOvNsZ4IW2h5 6bOBg6kahFfOIO+xFApbN8dOKJRPJ6l4iwEBSWbuOcdbwhYZ+7rfbES13Jj7SzkI0q7V d5rg== X-Gm-Message-State: APt69E1RpMe3uFR0yzu6Jxy5ZNh/gKh4VpiNhqcF9SBVFs1RBOPw2qtx 0wGeWKnqLR38NXutIKqWxz6CePP9HWucdpaEIFvS6w== X-Google-Smtp-Source: AAOMgpdgb2b8fkyhUvXUUturruyM4O8CbifLcDpMWBkwWgq/irc0oGOSOGamPK3vkT8i1mhMBsOEfCRSLsRxhLYpH3k= X-Received: by 2002:a1c:d602:: with SMTP id n2-v6mr15643972wmg.150.1531272388413; Tue, 10 Jul 2018 18:26:28 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:e44a:0:0:0:0:0 with HTTP; Tue, 10 Jul 2018 18:26:27 -0700 (PDT) In-Reply-To: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> From: =?UTF-8?B?w5NsYWZ1ciBHdcOwbXVuZHNzb24=?= Date: Tue, 10 Jul 2018 21:26:27 -0400 Message-ID: To: Mark Nottingham Cc: Joe Abley , dnsop , DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Content-Type: multipart/alternative; boundary="000000000000c4241e0570af229d" Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:26:34 -0000 --000000000000c4241e0570af229d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yes On Tue, Jul 10, 2018 at 9:22 PM, Mark Nottingham wrote: > > > > On 11 Jul 2018, at 3:55 am, Joe Abley wrote: > > > > On Jul 10, 2018, at 18:02, Adam Roach wrote: > > > >> In large part because DNS provides "a richer scheme that accommodates > address families and multiple addresses with priorities". > > > > *cups hand to ear* > > > > Was that the sound of a distant desire to specify use of SRV for HTTP? > > > > I recently did some digging on this topic, and can try to characterise > what the issues / objections are. > > Would people be interested in a (hopefully brief) side meeting to discuss > and maybe come to a shared understanding of the problem space? > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > --=20 =C3=93lafur Gudmundsson | Engineering Director www.cloudflare.com blog.cloudflare.com --000000000000c4241e0570af229d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yes=C2=A0

<= br>
On Tue, Jul 10, 2018 at 9:22 PM, Mark Notting= ham <mnot@mnot.net> wrote:

> On 11 Jul 2018, at 3:55 am, Joe Abley <jabley@hopcount.ca> wrote:
>
> On Jul 10, 2018, at 18:02, Adam Roach <adam@nostrum.com> wrote:
>
>> In large part because DNS provides "a richer scheme that acco= mmodates address families and multiple addresses with priorities".
>
> *cups hand to ear*
>
> Was that the sound of a distant desire to specify use of SRV for HTTP?=
>

I recently did some digging on this topic, and can try to characterise what= the issues / objections are.

Would people be interested in a (hopefully brief) side meeting to discuss a= nd maybe come to a shared understanding of the problem space?

Cheers,

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

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop



--
= =C3=93lafur Gudmundsson |=C2=A0Engineering= Director=C2=A0
--000000000000c4241e0570af229d-- From nobody Tue Jul 10 18:30:28 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 101A9130E9E; Tue, 10 Jul 2018 18:30:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 W0BTN5dMyGL7; Tue, 10 Jul 2018 18:30:25 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 08C37129C6A; Tue, 10 Jul 2018 18:30:25 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id E824C3AB043; Wed, 11 Jul 2018 01:30:24 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id A3D2C160072; Wed, 11 Jul 2018 01:30:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8FB1D16006B; Wed, 11 Jul 2018 01:30:24 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id W4OLdSWo7R8c; Wed, 11 Jul 2018 01:30:24 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 0AB5016006A; Wed, 11 Jul 2018 01:30:22 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: Date: Wed, 11 Jul 2018 11:30:20 +1000 Cc: Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> To: Mark Nottingham X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:30:27 -0000 > On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: >=20 >=20 >=20 >> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >>=20 >> On Jul 10, 2018, at 18:02, Adam Roach wrote: >>=20 >>> In large part because DNS provides "a richer scheme that = accommodates address families and multiple addresses with priorities". >>=20 >> *cups hand to ear* >>=20 >> Was that the sound of a distant desire to specify use of SRV for = HTTP? >>=20 >=20 > I recently did some digging on this topic, and can try to characterise = what the issues / objections are. I think there are three main objections. 1) Wildcards don=E2=80=99t work with prefixes. 2) Additional data isn=E2=80=99t always returned it may require multiple = round trips. 3) Additional data processing doesn=E2=80=99t support negative = responses. All of these issues are trivially easy to fix. It just require = willingness to implement. 1) is addressed by defining a new type(s) rather than using prefixes. 2) is addressed by getting recursive servers to fill in missing = additional data before returning. Named has code in review for this for = SRV as proof of concept. 3) is addressed by adding some signalling between the client and = recursive server to indicate if the additional section is complete or = not. > Would people be interested in a (hopefully brief) side meeting to = discuss and maybe come to a shared understanding of the problem space? >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 10 18:32:26 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254F4130EB2; Tue, 10 Jul 2018 18:32:10 -0700 (PDT) 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=mnot.net header.b=NYCbfOXc; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Y0na1WHh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VGH7azKCzaBf; Tue, 10 Jul 2018 18:32:08 -0700 (PDT) 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 3E109130E9E; Tue, 10 Jul 2018 18:32:08 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9D1CF21BBE; Tue, 10 Jul 2018 21:32:07 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 10 Jul 2018 21:32:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=SJHSDQW0ZFcwV65ySt4qqfPe9vcr9 QOjwKmSeAa7pWg=; b=NYCbfOXce98kVuWEG9ADfmdO1R9Ek6Hm5ixKgvUBzyMg1 d26kZlhTJupBDJB+eAXFamjueLCOKvIZCDY0522an3Ll1L+MOVMnLbawFZgvDjrl ggFeU1+dhRhnnauuSVP/kjF4iZ+ng55WP0mUnsjeqOl6pEzxF/veXoFX+880Y7ps ffkO70SO9WgbAzIIVDtQWcoXkw9qAamna9Dr2QrwDfuERBy0St6/37DPzqaDfe3x 7s/YzeLQYb6wKCshK/1ss3ikyrtPq/05bYxKRvcrt3kFt/gOqRHSqG5V9De7B2zX H3JYeF1M9COJ6PuUF6+sh7uwcZGeYCzciFYRfpYpQ== 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=SJHSDQ W0ZFcwV65ySt4qqfPe9vcr9QOjwKmSeAa7pWg=; b=Y0na1WHh81Eu/3+fy4GWto sDOJH9PQaPtrntWB6OyGCTf+qi9QkrPJYm7bV//ch6h/QxMFvcKgdTys1b6YCWRe YgcK4/QHfuu5MSsl+W3l/E1NuA4C5KXl1ktZvelRyfdn/jg87uC936hZmwXphEnX YBkhVEoNwBU5+r4gS+Gftpid3GnMA4u5IXCMYxkeKX4pWPZ8+q8FtRBAB4P4RO4s 18dHLpLJKe8ZFY3sWEPAcgShno7b8bVpmYgtrVyXCsJ2witkh32PvWksSJ0veGWY Z+mFKbpKDlci1OBzVDl6ply4fkRBfkdKgkHDgEMD9d0FsAbILk5X6ZjctP2TCj5Q == X-ME-Proxy: X-ME-Sender: Received: from attitudadjuster.localdomain (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 06702E405A; Tue, 10 Jul 2018 21:32:04 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Mark Nottingham In-Reply-To: <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> Date: Wed, 11 Jul 2018 11:32:02 +1000 Cc: Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> To: Mark Andrews X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:32:11 -0000 I didn't find those, but I found many others. I'll start collecting. How about Tuesday, say 6:45-7:45pm? > On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: >=20 >=20 >=20 >> On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: >>=20 >>=20 >>=20 >>> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >>>=20 >>> On Jul 10, 2018, at 18:02, Adam Roach wrote: >>>=20 >>>> In large part because DNS provides "a richer scheme that = accommodates address families and multiple addresses with priorities". >>>=20 >>> *cups hand to ear* >>>=20 >>> Was that the sound of a distant desire to specify use of SRV for = HTTP? >>>=20 >>=20 >> I recently did some digging on this topic, and can try to = characterise what the issues / objections are. >=20 > I think there are three main objections. >=20 > 1) Wildcards don=E2=80=99t work with prefixes. > 2) Additional data isn=E2=80=99t always returned it may require = multiple round trips. > 3) Additional data processing doesn=E2=80=99t support negative = responses. >=20 > All of these issues are trivially easy to fix. It just require = willingness to implement. >=20 > 1) is addressed by defining a new type(s) rather than using prefixes. > 2) is addressed by getting recursive servers to fill in missing = additional data before returning. Named has code in review for this for = SRV as proof of concept. > 3) is addressed by adding some signalling between the client and = recursive server to indicate if the additional section is complete or = not. >=20 >=20 >> Would people be interested in a (hopefully brief) side meeting to = discuss and maybe come to a shared understanding of the problem space? >>=20 >> Cheers, >>=20 >> -- >> Mark Nottingham https://www.mnot.net/ >>=20 >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop >=20 > --=20 > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 10 18:37:41 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A87A9130EAB; Tue, 10 Jul 2018 18:37:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 peqrUSp4J1Pb; Tue, 10 Jul 2018 18:37:26 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 EAD30130DD6; Tue, 10 Jul 2018 18:37:25 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id BF4A73AB041; Wed, 11 Jul 2018 01:37:25 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 82A1E160072; Wed, 11 Jul 2018 01:37:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 5B13016006B; Wed, 11 Jul 2018 01:37:22 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iRbvBX2HhmUx; Wed, 11 Jul 2018 01:37:22 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id A1B5D16006A; Wed, 11 Jul 2018 01:37:20 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> Date: Wed, 11 Jul 2018 11:37:16 +1000 Cc: Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <57193515-CDC7-442A-892F-D0DDF259B1E6@isc.org> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> To: Mark Nottingham X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:37:28 -0000 Fine by me. > On 11 Jul 2018, at 11:32 am, Mark Nottingham wrote: >=20 > I didn't find those, but I found many others. >=20 > I'll start collecting. How about Tuesday, say 6:45-7:45pm? >=20 >=20 >=20 >> On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: >>=20 >>=20 >>=20 >>> On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: >>>=20 >>>=20 >>>=20 >>>> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >>>>=20 >>>> On Jul 10, 2018, at 18:02, Adam Roach wrote: >>>>=20 >>>>> In large part because DNS provides "a richer scheme that = accommodates address families and multiple addresses with priorities". >>>>=20 >>>> *cups hand to ear* >>>>=20 >>>> Was that the sound of a distant desire to specify use of SRV for = HTTP? >>>>=20 >>>=20 >>> I recently did some digging on this topic, and can try to = characterise what the issues / objections are. >>=20 >> I think there are three main objections. >>=20 >> 1) Wildcards don=E2=80=99t work with prefixes. >> 2) Additional data isn=E2=80=99t always returned it may require = multiple round trips. >> 3) Additional data processing doesn=E2=80=99t support negative = responses. >>=20 >> All of these issues are trivially easy to fix. It just require = willingness to implement. >>=20 >> 1) is addressed by defining a new type(s) rather than using prefixes. >> 2) is addressed by getting recursive servers to fill in missing = additional data before returning. Named has code in review for this for = SRV as proof of concept. >> 3) is addressed by adding some signalling between the client and = recursive server to indicate if the additional section is complete or = not. >>=20 >>=20 >>> Would people be interested in a (hopefully brief) side meeting to = discuss and maybe come to a shared understanding of the problem space? >>>=20 >>> Cheers, >>>=20 >>> -- >>> Mark Nottingham https://www.mnot.net/ >>>=20 >>> _______________________________________________ >>> DNSOP mailing list >>> DNSOP@ietf.org >>> https://www.ietf.org/mailman/listinfo/dnsop >>=20 >> --=20 >> Mark Andrews, ISC >> 1 Seymour St., Dundas Valley, NSW 2117, Australia >> PHONE: +61 2 9871 4742 INTERNET: marka@isc.org >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 10 18:51:26 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF0CE12E039; Tue, 10 Jul 2018 18:51:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 c7u3_RiCoBjg; Tue, 10 Jul 2018 18:51:11 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7C44127148; Tue, 10 Jul 2018 18:51:11 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id 9248F47C3F; Tue, 10 Jul 2018 21:51:10 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23365.25230.573067.921128@gro.dd.org> Date: Tue, 10 Jul 2018 21:51:10 -0400 From: Dave Lawrence To: Mark Nottingham Cc: Mark Andrews , DoH WG , Adam Roach , driu@ietf.org, dnsop@ietf.org, HTTP Working Group , Joe Abley In-Reply-To: <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:51:13 -0000 Mark Nottingham writes: > I'll start collecting. How about Tuesday, say 6:45-7:45pm? Last session ends at 6:20 and social starts at 7, not sure how late the last bus (if any?) will be leaving the hotel. From nobody Tue Jul 10 18:52:57 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F51112E039; Tue, 10 Jul 2018 18:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 4eqy6DODHyjO; Tue, 10 Jul 2018 18:52:54 -0700 (PDT) Received: from gro.dd.org (gro.dd.org [207.136.192.136]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D51127148; Tue, 10 Jul 2018 18:52:54 -0700 (PDT) Received: by gro.dd.org (Postfix, from userid 102) id E103347C47; Tue, 10 Jul 2018 21:52:53 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <23365.25333.904112.575031@gro.dd.org> Date: Tue, 10 Jul 2018 21:52:53 -0400 From: Dave Lawrence To: Mark Nottingham , DoH WG , Adam Roach , driu@ietf.org, dnsop@ietf.org, HTTP Working Group , Joe Abley In-Reply-To: <23365.25230.573067.921128@gro.dd.org> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:52:56 -0000 Dave Lawrence writes: > Mark Nottingham writes: > > I'll start collecting. How about Tuesday, say 6:45-7:45pm? > > Last session ends at 6:20 and social starts at 7, not sure how late > the last bus (if any?) will be leaving the hotel. Nevermind, walking distance to social, under 1km. Maybe still though shifting it a little earlier, like 18:30. From nobody Tue Jul 10 18:58:36 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34CC3130E82; Tue, 10 Jul 2018 18:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 w53nu-PMZs57; Tue, 10 Jul 2018 18:58:18 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 02304130DE8; Tue, 10 Jul 2018 18:58:18 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id C9B933AB041; Wed, 11 Jul 2018 01:58:17 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 9A3A616006A; Wed, 11 Jul 2018 01:58:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8610816006B; Wed, 11 Jul 2018 01:58:17 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id BgkaAGvZRlmq; Wed, 11 Jul 2018 01:58:17 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id DB21016006A; Wed, 11 Jul 2018 01:58:15 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <23365.25230.573067.921128@gro.dd.org> Date: Wed, 11 Jul 2018 11:58:13 +1000 Cc: Mark Nottingham , DoH WG , Adam Roach , driu@ietf.org, dnsop@ietf.org, HTTP Working Group , Joe Abley Content-Transfer-Encoding: quoted-printable Message-Id: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> To: Dave Lawrence X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 01:58:23 -0000 > On 11 Jul 2018, at 11:51 am, Dave Lawrence wrote: >=20 > Mark Nottingham writes: >> I'll start collecting. How about Tuesday, say 6:45-7:45pm? >=20 > Last session ends at 6:20 and social starts at 7, not sure how late > the last bus (if any?) will be leaving the hotel. It=E2=80=99s a 9 minute walk (4 blocks). --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Tue Jul 10 19:26:01 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF14912E039; Tue, 10 Jul 2018 19:25:47 -0700 (PDT) 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=mnot.net header.b=DSgUxvRN; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=AIFvcHOZ Received: 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-3S97mUPoZi; Tue, 10 Jul 2018 19:25:45 -0700 (PDT) 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 B32C1130DCD; Tue, 10 Jul 2018 19:25:45 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E10DA21B81; Tue, 10 Jul 2018 22:25:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Tue, 10 Jul 2018 22:25:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=OYJezIELdhXV3tTTU1inb6Ed+WHTS e5+6W7TmEh1do4=; b=DSgUxvRNgy00Q43sJgwrAkXlvKvb7YKX1OWKU/ZAEj40e SMEf/FQpmkWxrwtSAj+bXot/jNjVtafWwMhGSwFeRkxdjheKVbuHreDO2qgaf/0V DpSXiGswyZwNdKVd5S+4DmweYxzTEGveIIjSgTCTMsZuocGSr3h2qnDU3CTRXV7C h1HiHLk4FBPf9r1HdBBcnDg1eP08BebgrcX9ns2ZLIfcIQKxcyS3N1zfQfwSolUv WvWuzkbNz1O7oHgjZJimxctkQV5yQpURDX1SuMyxRY8h6uXCzuubxmK7OGFMtCRk JxMET7miwsvRQGyC4iODca9lrlmolf8Y8p8fdPXLQ== 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=OYJezI ELdhXV3tTTU1inb6Ed+WHTSe5+6W7TmEh1do4=; b=AIFvcHOZkwWpYJHvYtp/Qj y0yc8UmbeeuNZvIhoUxN1i91zf6g481eWqviewGANIQMOZ4RLroL/JVLV/WMJQ+R gtmKreQytMxRrPircT097nWawRdN2ZGxC4gKzF89S5I0SuvdaMZrAomXELo+1LSw PmfpZ/NI3xb2+jhx+tkXOa/iBLH7P1TpCYjJrp1aJ81aVhM+RseqP821UhqVQBJy Ho99IFrX/e4J/t4TDM829kXKihB0AwcQhl62vuOgcaSGgJ/DIkUXuxVssDou71f0 gxQ7pVYMM/TGQt5CIynPaztoqD2WOGv+ojJG2mvySkLVheCMS/cIROLUCYJvwQMw == X-ME-Proxy: X-ME-Sender: Received: from attitudadjuster.localdomain (unknown [144.136.175.28]) by mail.messagingengine.com (Postfix) with ESMTPA id 0D277E4516; Tue, 10 Jul 2018 22:25:41 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Mark Nottingham In-Reply-To: <23365.25333.904112.575031@gro.dd.org> Date: Wed, 11 Jul 2018 12:25:38 +1000 Cc: DoH WG , Adam Roach , driu@ietf.org, dnsop@ietf.org, HTTP Working Group , Joe Abley Content-Transfer-Encoding: quoted-printable Message-Id: <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> <23365.25333.904112.575031@gro.dd.org> To: Dave Lawrence X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Driu] SRV and HTTP - 18:30 Tuesday X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 02:25:49 -0000 Sure, with the understanding that we'll probably start a few minutes = after that, given the session end at 16:20 (I'm chairing then, it = usually takes a little while to get out). I've reserved Barre Oblique from 18:30 until 19:30 on Tuesday. Cheers, > On 11 Jul 2018, at 11:52 am, Dave Lawrence wrote: >=20 > Dave Lawrence writes: >> Mark Nottingham writes: >>> I'll start collecting. How about Tuesday, say 6:45-7:45pm? >>=20 >> Last session ends at 6:20 and social starts at 7, not sure how late >> the last bus (if any?) will be leaving the hotel. >=20 > Nevermind, walking distance to social, under 1km. Maybe still though > shifting it a little earlier, like 18:30. >=20 > _______________________________________________ > DRIU mailing list > DRIU@ietf.org > https://www.ietf.org/mailman/listinfo/driu -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 10 22:53:53 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A9B130E02; Tue, 10 Jul 2018 22:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, 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 dxMXrxxtdsgY; Tue, 10 Jul 2018 22:53:39 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DFE1126F72; Tue, 10 Jul 2018 22:53:39 -0700 (PDT) Received: from [169.254.214.146] (vpn-client-208.netnod.se [192.71.80.208]) by mail.frobbit.se (Postfix) with ESMTPSA id 4BB7A22078; Wed, 11 Jul 2018 07:53:36 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Mark Andrews" Cc: "Mark Nottingham" , "DoH WG" , "Adam Roach" , driu@ietf.org, dnsop@ietf.org, "HTTP Working Group" , "Joe Abley" Date: Wed, 11 Jul 2018 07:53:35 +0200 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <965AE0A9-DBFC-4823-8E54-216BD70D089F@frobbit.se> In-Reply-To: <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_2894E674-2A94-4682-8D94-A680CE7FC40E_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 05:53:42 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_2894E674-2A94-4682-8D94-A680CE7FC40E_= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 11 Jul 2018, at 3:30, Mark Andrews wrote: > I think there are three main objections. > > 1) Wildcards don=E2=80=99t work with prefixes. > 2) Additional data isn=E2=80=99t always returned it may require multipl= e round trips. > 3) Additional data processing doesn=E2=80=99t support negative response= s. 4) Various libraries in PHP and ultimately lib curl do not include SRV in= the resolution 5) New resource record types are very hard to implement (same argument as= why we use TXT for SPF and not SPF for example) 6) You "only" change hostname with SRV and not a "complete change of the = URL" > All of these issues are trivially easy to fix. It just require willing= ness to implement. > > 1) is addressed by defining a new type(s) rather than using prefixes. > 2) is addressed by getting recursive servers to fill in missing additio= nal data before returning. Named has code in review for this for SRV as = proof of concept. > 3) is addressed by adding some signalling between the client and recurs= ive server to indicate if the additional section is complete or not. 4) Is of course "just code" in lib curl and what not 5) Is like (4) but possibly harder if you want it implemented in PHP, jav= ascript etc and not in the underlying libraries 6) This is why I came up with URI which is supposed to be a competitor to= "well known URI" paf --=_MailMate_2894E674-2A94-4682-8D94-A680CE7FC40E_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCW0WbXw8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI182jdACgjBgO7Src+l5thvu8Y74cmzloG8QAn1eSfRQ+ COid72LPngyhhRJW9jgM =wxLI -----END PGP SIGNATURE----- --=_MailMate_2894E674-2A94-4682-8D94-A680CE7FC40E_=-- From nobody Tue Jul 10 23:21:45 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8359130EBF; Tue, 10 Jul 2018 23:21:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 yyei5UxS3VbC; Tue, 10 Jul 2018 23:21:40 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 7479E130E13; Tue, 10 Jul 2018 23:21:40 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 16E803AB03F; Wed, 11 Jul 2018 06:21:40 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D9F4B16006A; Wed, 11 Jul 2018 06:21:39 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id B051316006B; Wed, 11 Jul 2018 06:21:39 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 1WPY288j99Zw; Wed, 11 Jul 2018 06:21:39 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id C51FB16006A; Wed, 11 Jul 2018 06:21:37 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <965AE0A9-DBFC-4823-8E54-216BD70D089F@frobbit.se> Date: Wed, 11 Jul 2018 16:21:35 +1000 Cc: Mark Nottingham , DoH WG , Adam Roach , driu@ietf.org, dnsop@ietf.org, HTTP Working Group , Joe Abley Content-Transfer-Encoding: quoted-printable Message-Id: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <965AE0A9-DBFC-4823-8E54-216BD70D089F@frobbit.se> To: =?utf-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 06:21:44 -0000 > On 11 Jul 2018, at 3:53 pm, Patrik F=C3=A4ltstr=C3=B6m = wrote: >=20 > On 11 Jul 2018, at 3:30, Mark Andrews wrote: >=20 >> I think there are three main objections. >>=20 >> 1) Wildcards don=E2=80=99t work with prefixes. >> 2) Additional data isn=E2=80=99t always returned it may require = multiple round trips. >> 3) Additional data processing doesn=E2=80=99t support negative = responses. >=20 > 4) Various libraries in PHP and ultimately lib curl do not include SRV = in the resolution Then PHP is not STD 13 compliant. Resolver libraries are supposed to be = able resolve UNKNOWN records per STD 13 and that includes SRV. As for lib curl, there is not a RFC that says to lookup SRV records for = HTTP or HTTPS. > 5) New resource record types are very hard to implement (same argument = as why we use TXT for SPF and not SPF for example) SPF was just plain unwillingness to complete the transition. The code = was out there. It was being deployed. TXT to SPF transition was never = part of the experiment, it was in addition to the experiment. No resources record is hard to implement. What hard is getting someone = to commit 30 minutes to 1 hour of time to do something at all. That is = what it takes most pieces of software to add a new record type. Thats = been true since I started in the DNS back in the early 90=E2=80=99s. > 6) You "only" change hostname with SRV and not a "complete change of = the URL >> All of these issues are trivially easy to fix. It just require = willingness to implement. >>=20 >> 1) is addressed by defining a new type(s) rather than using prefixes. >> 2) is addressed by getting recursive servers to fill in missing = additional data before returning. Named has code in review for this for = SRV as proof of concept. >> 3) is addressed by adding some signalling between the client and = recursive server to indicate if the additional section is complete or = not. >=20 > 4) Is of course "just code" in lib curl and what not >=20 > 5) Is like (4) but possibly harder if you want it implemented in PHP, = javascript etc and not in the underlying libraries >=20 > 6) This is why I came up with URI which is supposed to be a competitor = to "well known URI" >=20 > paf --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jul 11 05:20:29 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B21E130EDF; Wed, 11 Jul 2018 01:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.021 X-Spam-Level: X-Spam-Status: No, score=-6.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5] 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 6qimPhtgKsj3; Wed, 11 Jul 2018 01:23:30 -0700 (PDT) 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 387C5130ED6; Wed, 11 Jul 2018 01:23:29 -0700 (PDT) Received: from [IPv6:2001:67c:1220:80c:dc58:aeeb:87f9:51f8] (unknown [IPv6:2001:67c:1220:80c:dc58:aeeb:87f9:51f8]) by mail.nic.cz (Postfix) with ESMTPSA id E462F600FF; Wed, 11 Jul 2018 10:23:24 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1531297405; bh=LHnuk7xCUvKAhdUEXuQO/0trUrxPE3WKUOHJmcTstec=; h=To:From:Date; b=oR02KeTY6sBXzaFYnJl1HshzUA6KpdfLjWPQrVfY4FtgzaIauvpnwTjpeUDhDy75Q 8fYbCD5CE/pRb8n92SCwnT68kAF3xWAoNHnz9SGqT0dwgNVQ4LBipeNxQOcNawhVDU DlBmpl+rAgS3Gy8WY67TX9ZMfWRd8POl2r/Y6fyo= To: Ryan Sleevi , Mike Bishop Cc: DoH WG , Adam Roach , "driu@ietf.org" , Philip Homburg , dnsop WG , Ted Lemon , Patrick McManus , Paul Wouters , Joe Abley , HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Openpgp: preference=signencrypt Autocrypt: addr=petr.spacek@nic.cz; prefer-encrypt=mutual; keydata= xsFNBFhri/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+zDThLtZMvtrehtkjVDPT50xg8TMr68hd3GRWBUJHszMTnlQARAQABzSJQZXRyIMWgcGHE jWVrIDxwZXRyLnNwYWNla0BuaWMuY3o+wsF9BBMBCAAnBQJYa4wfAhsDBQkDwmcABQsJCAcC BhUICQoLAgQWAgMBAh4BAheAAAoJEM6N1qGlCiHkjGoP/3fvimzczcaqPM8lgY9fKKcr2DhH 42HF+fXsj0SvPeEoYDuWwIcsTGna6sdmrhCD/mB6eCNivAOcZYDH7j3YDgdFX2xy1sRY0ylF uyfcOT1Qn1xNTglSaf00gUWDgLBQB/USphB9Of6U1ka4gLJpCWKoZ3cLQe09cUpq9HOZYs/g WSNx9UTr06fcO0rtgZpg+IZJN/R2ORhQBwk4n2Dtx5J+Xyoy7ht1Fwz07BWAGJ4P8oJOhsi1 LukDD8ul3+6IeoSbRvyGpP6boegaMwxPR10VgsrYU2t1cK58iRv/xJ3TClb0JBn5aI3Bmh1j mPROrC55tvxRoeRLmxXHzbPZpWdbRjEcf9SEiAGNTgo9C+eXbubeSETWgisfJhZ4ebhkHnfz e+e+hvbaTSoFyMbKeOlfoYCmaDRBgT53i72HIkvO+HrVcmulZytw/yyOHuwObEFVgn3AeORv rb8I1kiv5W4wnZxDslhCeRR+wMGiKhc9ewU/mg3Rqo6GN+8mT0DHnsHuq1lu3WYslfNYkBSo nFcctFD2KXVozrwpn3vWJ4Qt6qu5XS1lDCD5WshZXh7qoISWnnMqsMyBW/R7WyiABeIz4uOg SkRwT2wSUYr+JtBZIjREy2JQDVhjf18DL1Qa7OxSes8YwWSx1pQAzwbfFx0gzRDyIT/39le4 pX430yTQzsFNBFhri/0BEADFp4ZfxSoKTAad0IkFK9CVoZ6XKywYLFNPPhzw++gbvHL2EX7Q qhEsqbsWMYpH4jc/Kq55OYYU/lIcULuD0Y9oDR26XFQou0FeSNnzRGb607U8OFOPQ+ei92Mm 1YPQ33GPj8GqbQpkAp35sfjJ64TH/EQY38RN33jsHRkhwtWU/6yo+RZs7cFRuihuLl8FuoP0 A5u/x+lNNeIBk8f27LVYrF81NSDDDYjnObCah+QLzGAwGDtjWkBVawpoHWwq58OQSx5piwyO CnFJeFONRcTRgOz239rsEA5LeYfmOGcnNwG6CHoJ5ZdWJw5OV9BoA7UTHG95xVHV5QiEm6q6 igI6wKV2RtFS7Roe0Wt8H7gC41JeqaKTUsGkz6uJraF8mmKyS8E+mSh3djmqdJNHF1pJqKxA xPYA9Y0jPnYWeEH4fPeOR2YvBjztsye9nOv1AuKNu03duzocyU95DfP/lwNJr5SH918Vf1t7 WcJj9dg6J9Jc5LOwg13Qr31TuZijrMdqM7LJKC/0tOkSeXNoMlHJOIqbqm7N414I0HytbENf 7AiyDxNA5TzJKkB0eBPLm2FMQCHLfasJHgbCrQut6nYw3f3Gn3+PDzGEHI9sfQv/mYvO77oR SGw+3Hy1ToxIncIirAyRpa5KdPLklDpADvpfkXjuL6IfZZ0OIWKLSRa/DQARAQABwsFlBBgB CAAPBQJYa4v9AhsMBQkDwmcAAAoJEM6N1qGlCiHkn54P/AgyzrffYzRq6d7vHfFhd8HzHHrU BtOK+5182DME1JX9Aow5Dy9kbfxAfTc4tbCY5EnhoUICbmVAJ5wL5lrGxQPSnulIyF8OmJjc VlGI6zXYvP0VHZ/L8dPcf+RPqhMCPpaxe2+h5XpPxvOkDLlnCrsA4J1bAGW5kpxdGnY4aRrv aKhtGMqgSwSx25l3RnoOROU/hTDV4EHCuTkMRfILmsuNT7It40iL5nyDiJ8o3p1CLjRwUzVn 4r4jE8DXhbWXaKJ0KQZpKiQDVV7qJcJIeBJvZpFfxJ44LxBct9TkC69ROntYhd6M7031DT3P IYW9VyMhLN5dRfzhEdFUc+3AlnoOOKcGwYiCnH2DwDva3ZicOAH8099mWZcwVL/sjKKbJGPo JbdT9C3gSnsoa3uBbsiChRhAno80Jsk/igb4QaMw4PsS3230kfBGkQ/oAPPM0iJ9kn8NXB/9 iBe5cKEUiiYQfSn9x1HyG0sT3/jSYaq3obmBNHJE24w/RKWoPsaKjoyaInAuU5L0cNZ30OWd eWFREIxlajFl2vXb9nCc80/i6PceJySiyJgd5cYEL4hfn/B6RXph9kAJySsqlIZoBhcwneGX mAS0M41jJjuIQdt5pkLhM9XoXjBFMGGtA/CtiicEgitItJfVCxdLG4bZOCrfPmevMGLxpEmB GouQ9dVQ Organization: CZ.NIC Message-ID: <32a1c574-d23f-d38e-546e-baa359e7e108@nic.cz> Date: Wed, 11 Jul 2018 10:23:24 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: X-Mailman-Approved-At: Wed, 11 Jul 2018 05:20:24 -0700 Subject: Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 08:23:34 -0000 On 10.7.2018 20:57, Ryan Sleevi wrote: > > > On Tue, Jul 10, 2018 at 2:09 PM, Mike Bishop > wrote: > > Yes, the multi-CDN case is the scariest aspect of coalescing and the > various DNS tricks we’ve been doing in recent years.  The server may > not be malicious, may not even be misconfigured – site X uses DNS to > dynamically share load between CDNs A and F.  If X decides to start > moving more load to A, F could in all good faith continue to route > clients to itself by providing cached, signed DNS records. > > > Yup. And, at least for browsers that follow a Priority of Constituency > model, it seems more important to ensure that site operators wishes are > respected over that of the CDNs they've used, or for their being a more > explicit signal from the user that it truly intends to ignore the site > operator. >   > > ____ > > __ __ > > The industry norm is that changing the DNS record’s CNAME to a > different CDN is the cut-over, regardless of whether the other CDN > remains configured.  It’s effectively acting as a “hot standby.”  If > it had to provided better proof of freshness, that might be > sufficient, but how fresh is sufficiently fresh?  And does DNSSEC > provide that freshness guarantee? > > > Right, these are questions that need to be answered, and not just with > abstract theoretical mitigations that don't or can't be deployed. Signatures in DNSSEC (i.e. RRSIG records) have validity period with 1-second granularity so in theory it allows fine-tunning. Of course shorter validity means more cryptographic operations to update signatures etc. Taking into account that Cloudflare signs all recorsd on the fly, it is clearly feasible for CDN to generate fresh signatures on every DNS request. Petr Špaček @ CZ.NIC > However, F could do this today with Alt-Svc and have the same > impact.  Secondary Certificates provides another way this might > happen.  So this ship might have already sailed. > > > The ship has only sailed for those foolish enough to ship those features > :) That is, these are real security concerns, they have not been > satisfactorily addressed, and security conscious implementations have > held off implementing these features for precisely this reason. If there > are implementations that have shipped, without understanding or > considering the security harm they're doing, that doesn't seem like a > good argument to keep building more features on the buggy premise. > > If they believe they have sufficiently mitigated those very real and > practical security concerns, they would hopefully be sharing those > concrete strategies and tradeoffs, rather than a Security Considerations > that acknowledges the dragons without adequately describing how to avoid > them (or how not to). From nobody Wed Jul 11 09:25:02 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3DBE130F59; Wed, 11 Jul 2018 09:24:48 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ogre.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 f9i0FTXmC-1o; Wed, 11 Jul 2018 09:24:47 -0700 (PDT) Received: from cosmo.ogre.com (cosmo4.ogre.com [71.6.165.248]) (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 28D7D130F58; Wed, 11 Jul 2018 09:24:47 -0700 (PDT) Received: by cosmo.ogre.com (8.15.2/8.15.2) with ESMTPSA id w6BGOiVN008931 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Jul 2018 09:24:44 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ogre.com; s=03062012; t=1531326285; bh=4epcr6NZvRK6VAwstEbx4ltZJzuEdPI0QD7spVgkygU=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=crrWJBjtd/ISL4gYU6NiricdESriDJW4eq5DgPoeeXCMduztOc3HH72LQ+ymoRx6f 1puQ0zyO6DxcdyR+t6qWkq7Njh1fb7wyr7z1dnk95S+M00fgxFsio9GbdRJXuz9AxI QwLjcHz3qgASTAvUOAJGjVgo9ggdkSO+cl2qG1tU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) From: Leif Hedstrom In-Reply-To: Date: Wed, 11 Jul 2018 10:24:43 -0600 Cc: Joe Abley , Adam Roach , DoH WG , driu@ietf.org, dnsop@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <4C5A84AA-C599-4294-AE55-52B2CC233D40@ogre.com> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> To: Mark Nottingham X-Mailer: Apple Mail (2.3445.8.2) Archived-At: Subject: Re: [Driu] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 16:24:50 -0000 > On Jul 10, 2018, at 7:22 PM, Mark Nottingham wrote: >=20 >=20 >=20 >> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >>=20 >> On Jul 10, 2018, at 18:02, Adam Roach wrote: >>=20 >>> In large part because DNS provides "a richer scheme that = accommodates address families and multiple addresses with priorities". >>=20 >> *cups hand to ear* >>=20 >> Was that the sound of a distant desire to specify use of SRV for = HTTP? >>=20 >=20 > I recently did some digging on this topic, and can try to characterise = what the issues / objections are. >=20 > Would people be interested in a (hopefully brief) side meeting to = discuss and maybe come to a shared understanding of the problem space? Definitely. We (Traffic Server) added some support for SRV a while back, = but it=E2=80=99s mostly a hack. Cheers, =E2=80=94 Leif From nobody Wed Jul 11 12:20:45 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154EE130EDB; Wed, 11 Jul 2018 12:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.622 X-Spam-Level: X-Spam-Status: No, score=-1.622 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, 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 amgDUdEG8A1T; Wed, 11 Jul 2018 12:20:34 -0700 (PDT) Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8101130E57; Wed, 11 Jul 2018 12:20:33 -0700 (PDT) Received: from [169.254.207.132] (90-226-123-103-no2430.tbcn.telia.com [90.226.123.103]) by mail.frobbit.se (Postfix) with ESMTPSA id 517DA22ED4; Wed, 11 Jul 2018 21:20:30 +0200 (CEST) From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" To: "Mark Andrews" Cc: "Mark Nottingham" , "DoH WG" , "Adam Roach" , driu@ietf.org, dnsop@ietf.org, "HTTP Working Group" , "Joe Abley" Date: Wed, 11 Jul 2018 21:20:29 +0200 X-Mailer: MailMate (2.0BETAr6116) Message-ID: <6899AB89-7B85-496E-B231-1CB6B4341166@frobbit.se> In-Reply-To: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <965AE0A9-DBFC-4823-8E54-216BD70D089F@frobbit.se> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=_MailMate_39534259-BFBF-4335-B006-8952B2B46DC6_="; micalg=pgp-sha1; protocol="application/pgp-signature" Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 19:20:38 -0000 This is an OpenPGP/MIME signed message (RFC 3156 and 4880). --=_MailMate_39534259-BFBF-4335-B006-8952B2B46DC6_= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On 11 Jul 2018, at 8:21, Mark Andrews wrote: > As for lib curl, there is not a RFC that says to lookup SRV records for= HTTP or HTTPS. Agree, and I have wanted it to be part of HTTP/2, or at least resolve thi= s mess, but it did not happen. This is my recurring discussion with Daniel when we have beer :-D paf --=_MailMate_39534259-BFBF-4335-B006-8952B2B46DC6_= Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCW0ZYfQ8ccGFmQGZyb2Ji aXQuc2UACgkQrMabGguI182GbwCeMx1GiHJXZOAS2NM/OXmcCGgJtQ0An1ar1f6U nEWOKucUj8qAXhAglCcO =yBaV -----END PGP SIGNATURE----- --=_MailMate_39534259-BFBF-4335-B006-8952B2B46DC6_=-- From nobody Wed Jul 11 14:13:56 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705BB1277BB; Wed, 11 Jul 2018 13:42:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 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, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 mEhFFremXvW0; Wed, 11 Jul 2018 13:42:39 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0703.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe49::703]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D86F130E18; Wed, 11 Jul 2018 13:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AuPPMbGuiP2BK/A6GT1Ed5mpiV1rsFP8iQ5Qmq38fkU=; b=JHgeRrcyDDymIlqoTGuyjTZ9x2Ts2meHeixxxbdy9itn1vUM6clkTt+zmxjpyLH8TsVK0aWf/ppsY5/cRYI/JTIxs2mG0e8PawAVz0heXGL7lZZAj31Rk4AFGtVuWSc/GQrplc06hLNryLTvRV8odFVDvhSNPC2gizsYtyR0nmU= Received: from BYAPR08MB3944.namprd08.prod.outlook.com (52.135.194.30) by BYAPR08MB4887.namprd08.prod.outlook.com (20.176.255.92) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.930.20; Wed, 11 Jul 2018 20:42:34 +0000 Received: from BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::2080:90d4:850e:af3]) by BYAPR08MB3944.namprd08.prod.outlook.com ([fe80::2080:90d4:850e:af3%2]) with mapi id 15.20.0952.017; Wed, 11 Jul 2018 20:42:34 +0000 From: Mike Bishop To: =?utf-8?B?UGV0ciDFoHBhxI1law==?= , Ryan Sleevi CC: DoH WG , Adam Roach , "driu@ietf.org" , Philip Homburg , dnsop WG , Ted Lemon , Patrick McManus , Paul Wouters , Joe Abley , HTTP Working Group Thread-Topic: [Doh] [Driu] [DNSOP] Resolverless DNS Side Meeting in Montreal Thread-Index: AQHUGPBzCI/u0plagkGhGyhgf/ZcS6SKfHmA Date: Wed, 11 Jul 2018 20:42:34 +0000 Message-ID: References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <22df8aac-7b9d-0d0b-5eac-694e52be251d@nostrum.com> <32a1c574-d23f-d38e-546e-baa359e7e108@nic.cz> In-Reply-To: <32a1c574-d23f-d38e-546e-baa359e7e108@nic.cz> 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=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BYAPR08MB4887; 7:gzqzOItI00S+HqG48e1K+TOt7VFKLj70VIBcJjZZFNPwVCYeehc1dYkd0qSOW1+Nd+v6e4xn1J/rbjXn79RyO9ktGjzjUJz7JqU2ByxtQEMSccwMoSeX/wcOCXDupr/tQ6D8+hzlDDuc6RuA5dCrIXwL6wjYmLf2QD/B0mVBf5hQ+WkBcnunAVmCpILGedyNDmNIZ8UPc5B2s+5lm7Ekd098WFUggyo15c2fWj3Md0hVPCbvvdi3owBg4abeeBZq x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: a8502440-8072-41ac-753b-08d5e76ed4f3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652040)(7021125)(8989117)(5600053)(711020)(4534165)(7022125)(4603075)(4627221)(201702281549075)(8990107)(7048125)(7024125)(7027125)(7028125)(7023125)(2017052603328)(7153060)(7193020); SRVR:BYAPR08MB4887; x-ms-traffictypediagnostic: BYAPR08MB4887: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(209352067349851)(192374486261705); x-ms-exchange-senderadcheck: 1 x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(8121501046)(5005006)(10201501046)(3231311)(944501410)(52105095)(3002001)(93006095)(93001095)(149027)(150027)(6041310)(20161123562045)(20161123558120)(20161123564045)(2016111802025)(20161123560045)(6072148)(6043046)(201708071742011)(7699016); SRVR:BYAPR08MB4887; BCL:0; PCL:0; RULEID:; SRVR:BYAPR08MB4887; x-forefront-prvs: 0730093765 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(39830400003)(376002)(346002)(396003)(199004)(189003)(13464003)(74482002)(105586002)(25786009)(81166006)(102836004)(6506007)(229853002)(53546011)(8676002)(81156014)(76176011)(7416002)(256004)(5660300001)(74316002)(68736007)(2900100001)(8936002)(99286004)(33656002)(7736002)(6436002)(97736004)(53936002)(305945005)(14454004)(9686003)(106356001)(7696005)(2906002)(55016002)(4326008)(110136005)(476003)(316002)(93886005)(54906003)(478600001)(14444005)(6116002)(86362001)(11346002)(3846002)(486006)(5250100002)(26005)(446003)(186003)(66066001)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR08MB4887; H:BYAPR08MB3944.namprd08.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:0; MX:1; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) x-microsoft-antispam-message-info: MqriETs1p1yQf89wt096RDlwyExowc2x9L4Vv0gQQ4yTCjBdwCPElbejjhHgdqHMnv327Pu6no3943DtLL3tFlsrb5krpu9smppMKUiiRAP0UnSAa9ekt1ma1OvKMznR0/lg2xQnfSLlUETIvdkFMrGleCUVeL9T3UyVldQT2Z1QJmKlQdin4+eH4G1QIbL1DXf2labXi1orLVAnnMzwtQjWhdh9bvlqgidqO1VSLPJKX7AE89e6BmWwnibJs69nxdqR9WnzUe5dFQ6+xuCeuNmlGrnFGv6m8lqEd6RLfzT5/KfVC//sruYu7vyurPXEbPJfzu9PsYnaog6qHFUpAygqFin+pSEZou3/UuVVB/M= spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: a8502440-8072-41ac-753b-08d5e76ed4f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2018 20:42:34.5785 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR08MB4887 Archived-At: X-Mailman-Approved-At: Wed, 11 Jul 2018 14:13:55 -0700 Subject: Re: [Driu] [Doh] [DNSOP] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 20:42:43 -0000 QnV0IGl0J3Mgbm90IG5lY2Vzc2FyaWx5IHRoZSBDRE4gdGhhdCdzIGdlbmVyYXRpbmcgdGhlIHNp Z25lZCByZWNvcmRzIGluIHRoZSBnZW5lcmFsIGNhc2UuICBZb3UncmUgd2FudGluZyBwcm9vZiB0 aGF0IHRoZSBjdXN0b21lcidzIGRvbWFpbiBpcyBwb2ludGVkIHRvIHRoYXQgQ0ROLCBzbyBpdCdz IHNpZ25lZCBieSB3aG9ldmVyIG1hbmFnZXMgdGhlIEROUyBpbmZyYXN0cnVjdHVyZSBpbnN0ZWFk LiAgVGhhdCBjb3VsZCBiZSBvbmUgb2YgdGhlIENETnMsIG9yIHRoZSBjdXN0b21lcidzIG9wZXJh dGlvbnMgdGVhbSwgb3IgYSB0aGlyZC1wYXJ0eSBwcm92aWRlciBhbHRvZ2V0aGVyLg0KDQpCdXQg eWVzLCBjbGVhcmx5IGl0J3MgcG9zc2libGUgZm9yIGF0IGxlYXN0IHNvbWUgcGFydGllcyB0byBk byBvbmxpbmUgc2lnbmluZyBpbiByZWFsLXRpbWUuICBUaGF0J3MgYXQgdmFyaWFuY2Ugd2l0aCB0 aGUgYWlyZ2FwcGVkIHNpZ25hdHVyZSBrZXkgZGVzaWduIEkndmUgaGVhcmQgaW4gb3RoZXIgY2Fz ZXMuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBQZXRyIMWgcGHEjWVrIFtt YWlsdG86cGV0ci5zcGFjZWtAbmljLmN6XSANClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxMSwgMjAx OCAxOjIzIEFNDQpUbzogUnlhbiBTbGVldmkgPHJ5YW4taWV0ZkBzbGVldmkuY29tPjsgTWlrZSBC aXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPg0KQ2M6IERvSCBXRyA8ZG9oQGlldGYub3JnPjsg QWRhbSBSb2FjaCA8YWRhbUBub3N0cnVtLmNvbT47IGRyaXVAaWV0Zi5vcmc7IFBoaWxpcCBIb21i dXJnIDxwY2gtZG5zb3AtM0B1LTEucGhpY29oLmNvbT47IGRuc29wIFdHIDxkbnNvcEBpZXRmLm9y Zz47IFRlZCBMZW1vbiA8bWVsbG9uQGZ1Z3VlLmNvbT47IFBhdHJpY2sgTWNNYW51cyA8cG1jbWFu dXNAbW96aWxsYS5jb20+OyBQYXVsIFdvdXRlcnMgPHBhdWxAbm9oYXRzLmNhPjsgSm9lIEFibGV5 IDxqYWJsZXlAaG9wY291bnQuY2E+OyBIVFRQIFdvcmtpbmcgR3JvdXAgPGlldGYtaHR0cC13Z0B3 My5vcmc+DQpTdWJqZWN0OiBSZTogW0RvaF0gW0RyaXVdIFtETlNPUF0gUmVzb2x2ZXJsZXNzIERO UyBTaWRlIE1lZXRpbmcgaW4gTW9udHJlYWwNCg0KT24gMTAuNy4yMDE4IDIwOjU3LCBSeWFuIFNs ZWV2aSB3cm90ZToNCj4gDQo+IA0KPiBPbiBUdWUsIEp1bCAxMCwgMjAxOCBhdCAyOjA5IFBNLCBN aWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmUgDQo+IDxtYWlsdG86bWJpc2hvcEBldmVx dWVmb3UuYmU+PiB3cm90ZToNCj4gDQo+ICAgICBZZXMsIHRoZSBtdWx0aS1DRE4gY2FzZSBpcyB0 aGUgc2Nhcmllc3QgYXNwZWN0IG9mIGNvYWxlc2NpbmcgYW5kIHRoZQ0KPiAgICAgdmFyaW91cyBE TlMgdHJpY2tzIHdl4oCZdmUgYmVlbiBkb2luZyBpbiByZWNlbnQgeWVhcnMuwqAgVGhlIHNlcnZl ciBtYXkNCj4gICAgIG5vdCBiZSBtYWxpY2lvdXMsIG1heSBub3QgZXZlbiBiZSBtaXNjb25maWd1 cmVkIOKAkyBzaXRlIFggdXNlcyBETlMgdG8NCj4gICAgIGR5bmFtaWNhbGx5IHNoYXJlIGxvYWQg YmV0d2VlbiBDRE5zIEEgYW5kIEYuwqAgSWYgWCBkZWNpZGVzIHRvIHN0YXJ0DQo+ICAgICBtb3Zp bmcgbW9yZSBsb2FkIHRvIEEsIEYgY291bGQgaW4gYWxsIGdvb2QgZmFpdGggY29udGludWUgdG8g cm91dGUNCj4gICAgIGNsaWVudHMgdG8gaXRzZWxmIGJ5IHByb3ZpZGluZyBjYWNoZWQsIHNpZ25l ZCBETlMgcmVjb3Jkcy4NCj4gDQo+IA0KPiBZdXAuIEFuZCwgYXQgbGVhc3QgZm9yIGJyb3dzZXJz IHRoYXQgZm9sbG93IGEgUHJpb3JpdHkgb2YgQ29uc3RpdHVlbmN5IA0KPiBtb2RlbCwgaXQgc2Vl bXMgbW9yZSBpbXBvcnRhbnQgdG8gZW5zdXJlIHRoYXQgc2l0ZSBvcGVyYXRvcnMgd2lzaGVzIA0K PiBhcmUgcmVzcGVjdGVkIG92ZXIgdGhhdCBvZiB0aGUgQ0ROcyB0aGV5J3ZlIHVzZWQsIG9yIGZv ciB0aGVpciBiZWluZyBhIA0KPiBtb3JlIGV4cGxpY2l0IHNpZ25hbCBmcm9tIHRoZSB1c2VyIHRo YXQgaXQgdHJ1bHkgaW50ZW5kcyB0byBpZ25vcmUgdGhlIA0KPiBzaXRlIG9wZXJhdG9yLg0KPiDC oA0KPiANCj4gICAgIF9fX18NCj4gDQo+ICAgICBfX8KgX18NCj4gDQo+ICAgICBUaGUgaW5kdXN0 cnkgbm9ybSBpcyB0aGF0IGNoYW5naW5nIHRoZSBETlMgcmVjb3Jk4oCZcyBDTkFNRSB0byBhDQo+ ICAgICBkaWZmZXJlbnQgQ0ROIGlzIHRoZSBjdXQtb3ZlciwgcmVnYXJkbGVzcyBvZiB3aGV0aGVy IHRoZSBvdGhlciBDRE4NCj4gICAgIHJlbWFpbnMgY29uZmlndXJlZC7CoCBJdOKAmXMgZWZmZWN0 aXZlbHkgYWN0aW5nIGFzIGEg4oCcaG90IHN0YW5kYnku4oCdwqAgSWYNCj4gICAgIGl0IGhhZCB0 byBwcm92aWRlZCBiZXR0ZXIgcHJvb2Ygb2YgZnJlc2huZXNzLCB0aGF0IG1pZ2h0IGJlDQo+ICAg ICBzdWZmaWNpZW50LCBidXQgaG93IGZyZXNoIGlzIHN1ZmZpY2llbnRseSBmcmVzaD/CoCBBbmQg ZG9lcyBETlNTRUMNCj4gICAgIHByb3ZpZGUgdGhhdCBmcmVzaG5lc3MgZ3VhcmFudGVlPw0KPiAN Cj4gDQo+IFJpZ2h0LCB0aGVzZSBhcmUgcXVlc3Rpb25zIHRoYXQgbmVlZCB0byBiZSBhbnN3ZXJl ZCwgYW5kIG5vdCBqdXN0IHdpdGggDQo+IGFic3RyYWN0IHRoZW9yZXRpY2FsIG1pdGlnYXRpb25z IHRoYXQgZG9uJ3Qgb3IgY2FuJ3QgYmUgZGVwbG95ZWQuDQoNClNpZ25hdHVyZXMgaW4gRE5TU0VD IChpLmUuIFJSU0lHIHJlY29yZHMpIGhhdmUgdmFsaWRpdHkgcGVyaW9kIHdpdGggMS1zZWNvbmQg Z3JhbnVsYXJpdHkgc28gaW4gdGhlb3J5IGl0IGFsbG93cyBmaW5lLXR1bm5pbmcuIE9mIGNvdXJz ZSBzaG9ydGVyIHZhbGlkaXR5IG1lYW5zIG1vcmUgY3J5cHRvZ3JhcGhpYyBvcGVyYXRpb25zIHRv IHVwZGF0ZSBzaWduYXR1cmVzIGV0Yy4NCg0KVGFraW5nIGludG8gYWNjb3VudCB0aGF0IENsb3Vk ZmxhcmUgc2lnbnMgYWxsIHJlY29yc2Qgb24gdGhlIGZseSwgaXQgaXMgY2xlYXJseSBmZWFzaWJs ZSBmb3IgQ0ROIHRvIGdlbmVyYXRlIGZyZXNoIHNpZ25hdHVyZXMgb24gZXZlcnkgRE5TIHJlcXVl c3QuDQoNClBldHIgxaBwYcSNZWsgIEAgIENaLk5JQw0KDQoNCj4gICAgIEhvd2V2ZXIsIEYgY291 bGQgZG8gdGhpcyB0b2RheSB3aXRoIEFsdC1TdmMgYW5kIGhhdmUgdGhlIHNhbWUNCj4gICAgIGlt cGFjdC7CoCBTZWNvbmRhcnkgQ2VydGlmaWNhdGVzIHByb3ZpZGVzIGFub3RoZXIgd2F5IHRoaXMg bWlnaHQNCj4gICAgIGhhcHBlbi7CoCBTbyB0aGlzIHNoaXAgbWlnaHQgaGF2ZSBhbHJlYWR5IHNh aWxlZC4NCj4gDQo+IA0KPiBUaGUgc2hpcCBoYXMgb25seSBzYWlsZWQgZm9yIHRob3NlIGZvb2xp c2ggZW5vdWdoIHRvIHNoaXAgdGhvc2UgDQo+IGZlYXR1cmVzDQo+IDopIFRoYXQgaXMsIHRoZXNl IGFyZSByZWFsIHNlY3VyaXR5IGNvbmNlcm5zLCB0aGV5IGhhdmUgbm90IGJlZW4gDQo+IHNhdGlz ZmFjdG9yaWx5IGFkZHJlc3NlZCwgYW5kIHNlY3VyaXR5IGNvbnNjaW91cyBpbXBsZW1lbnRhdGlv bnMgaGF2ZSANCj4gaGVsZCBvZmYgaW1wbGVtZW50aW5nIHRoZXNlIGZlYXR1cmVzIGZvciBwcmVj aXNlbHkgdGhpcyByZWFzb24uIElmIA0KPiB0aGVyZSBhcmUgaW1wbGVtZW50YXRpb25zIHRoYXQg aGF2ZSBzaGlwcGVkLCB3aXRob3V0IHVuZGVyc3RhbmRpbmcgb3IgDQo+IGNvbnNpZGVyaW5nIHRo ZSBzZWN1cml0eSBoYXJtIHRoZXkncmUgZG9pbmcsIHRoYXQgZG9lc24ndCBzZWVtIGxpa2UgYSAN Cj4gZ29vZCBhcmd1bWVudCB0byBrZWVwIGJ1aWxkaW5nIG1vcmUgZmVhdHVyZXMgb24gdGhlIGJ1 Z2d5IHByZW1pc2UuDQo+IA0KPiBJZiB0aGV5IGJlbGlldmUgdGhleSBoYXZlIHN1ZmZpY2llbnRs eSBtaXRpZ2F0ZWQgdGhvc2UgdmVyeSByZWFsIGFuZCANCj4gcHJhY3RpY2FsIHNlY3VyaXR5IGNv bmNlcm5zLCB0aGV5IHdvdWxkIGhvcGVmdWxseSBiZSBzaGFyaW5nIHRob3NlIA0KPiBjb25jcmV0 ZSBzdHJhdGVnaWVzIGFuZCB0cmFkZW9mZnMsIHJhdGhlciB0aGFuIGEgU2VjdXJpdHkgDQo+IENv bnNpZGVyYXRpb25zIHRoYXQgYWNrbm93bGVkZ2VzIHRoZSBkcmFnb25zIHdpdGhvdXQgYWRlcXVh dGVseSANCj4gZGVzY3JpYmluZyBob3cgdG8gYXZvaWQgdGhlbSAob3IgaG93IG5vdCB0bykuDQoN Cg== From nobody Wed Jul 11 14:24:52 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31CA4130FBB; Wed, 11 Jul 2018 14:24:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.861 X-Spam-Level: X-Spam-Status: No, score=0.861 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, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=2.851] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 lXDXVN-Pjbo7; Wed, 11 Jul 2018 14:24:32 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17CF1130FCB; Wed, 11 Jul 2018 14:24:32 -0700 (PDT) Received: from homiemail-a108.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTP id 95D0D20047613; Wed, 11 Jul 2018 14:24:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=xPKVnZ4/vNP10qcQ0dMbRsKEbkA=; b=dvbs53irB00 eznSocVoVCNHX2rcDhbmBJBxlClzec1bANNMl/xXPwd0cj0QqsWwmje0/jaeFr+K fRNh7kVzRPIuFFjs6HuHUnv5ydtGHAJ0fEPi6NrKeGQxhXnKL/85Sinhrmm6mcNS FJz5Z3NpYlYTZjO1vJ3FPx1Rcj6/Cyu8= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a108.g.dreamhost.com (Postfix) with ESMTPSA id D0D432004760B; Wed, 11 Jul 2018 14:24:29 -0700 (PDT) Date: Wed, 11 Jul 2018 16:24:28 -0500 From: Nico Williams To: Mark Nottingham Cc: Mark Andrews , Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Message-ID: <20180711212427.GA9723@localhost> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 21:24:41 -0000 > > On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: > > > > > > On 11 Jul 2018, at 3:55 am, Joe Abley wrote: > > > > > > > > *cups hand to ear* > > > >=20 > > > > Was that the sound of a distant desire to specify use of SRV for > > > > HTTP? > >=20 > > I think there are three main objections. > >=20 > > 1) Wildcards don=E2=80=99t work with prefixes. > > 2) Additional data isn=E2=80=99t always returned it may require multi= ple round trips. > > 3) Additional data processing doesn=E2=80=99t support negative respon= ses. > >=20 > > All of these issues are trivially easy to fix. It just require willi= ngness to implement. > >=20 > > 1) is addressed by defining a new type(s) rather than using prefixes. While that is correct, and truly, it is trivial to implement, it is not trivial to deploy: too many DNS hosting providers would have to update UIs. Let me add my voice in favor of new RR types by which to replace SRV RRs. URI is one of them, for the sorts of things we do in Kerberos for KDC discovery, but no really appropriate for resolving HTTP authorities. > > 2) is addressed by getting recursive servers to fill in missing addit= ional data before returning. Named has code in review for this for SRV a= s proof of concept. That would be very nice indeed. Unbound will need that too. > > 3) is addressed by adding some signalling between the client and recu= rsive server to indicate if the additional section is complete or not. Well, OK, but as with (2) that requires recursive resolver critical mass. Not necessarily a big deal, though it will take enough time that many apps will need to support falling back to doing multiple queries one by one. Nico --=20 From nobody Wed Jul 11 15:26:07 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5F5912872C for ; Wed, 11 Jul 2018 15:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.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 X-JDzP9lqXtw for ; Wed, 11 Jul 2018 15:25:55 -0700 (PDT) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED138130E73 for ; Wed, 11 Jul 2018 15:25:51 -0700 (PDT) Received: by mail-ua0-x229.google.com with SMTP id q12-v6so17226568ual.2 for ; Wed, 11 Jul 2018 15:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xw/jjrYq+qCbhfhCI8wuejqR6md3s7xQ7PHmneUYKWo=; b=dEeZ4/Z6cYdhqqr5vBOPHSN7LbJLnOQWTk2Pf5N8JeQbR98km1erh0AtndzZF4Exbq k7ThdK/QqOXk+koLnyYE3LxSGYIZn5sUSsbeo8J5oz1kP5xX5ymCOgFAFN2M5DQTyvsJ qMZ16flqwkXodYWoaZ9P31s8QpFBJ7DOCG4/s= 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=Xw/jjrYq+qCbhfhCI8wuejqR6md3s7xQ7PHmneUYKWo=; b=tXBa9b/2+s2kD/o9WurlegPL4ZOLO3kXvk1bhvBeGiR7hAhC34JX/HzEePtIUSrfoB +2j/ecR7odo4VoAGKrexf1cLb9iodABsb3kfy6gZE/daqx/dpG8KHfiknkc/Pkp8BuWL bxWDAH4pe/o5yPyuiO87fv4ZfIsxYAwDXy8aT8c5fP/w75BPUgU8FESBBNqXneNlieEP zUACI6a3O76TS5YQF1V/it1M9DcfhzWCpagH6Nz9Lz9P3Xz/4KtkbBvUNO3BW4+NqxLD 5KknORiFyRoY5W9t+o0qgqKPRlgRyFlVaay0F7WHuxDIh0qtcL/KhUgBh6iM//Byphtc RMKw== X-Gm-Message-State: AOUpUlF6/RPssPUzWboDXsuyJu9krduKecXP2eoUYlRKC1JmUA3AS907 KptKA+Mj25MeYfGjcU2FEuMqP8pY/oJ+nNGwH0+ePQ== X-Google-Smtp-Source: AAOMgpeK4Z0Mh1j5Tda/qfL/lcnZqk8GyR/UQsbH94dECtaKOqgMe1f5d/ACGZTeqX9vIq+U+AqdJ2l0Q9vx5jfaQP4= X-Received: by 2002:ab0:4b17:: with SMTP id h23-v6mr360465uaf.84.1531347950636; Wed, 11 Jul 2018 15:25:50 -0700 (PDT) MIME-Version: 1.0 References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> In-Reply-To: <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> From: Joseph Lorenzo Hall Date: Wed, 11 Jul 2018 18:25:38 -0400 Message-ID: To: Mark Nottingham Cc: marka@isc.org, doh@ietf.org, Adam Roach , driu@ietf.org, dnsop , HTTP Working Group , jabley@hopcount.ca Content-Type: multipart/alternative; boundary="000000000000a017e90570c0ba9f" Archived-At: Subject: Re: [Driu] [Doh] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 22:26:00 -0000 --000000000000a017e90570c0ba9f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm in, but will need to catch up on the convo... I'll do so. BTW, don't look at the Yelp/Foursquare reviews for the social venue... yike= s On Tue, Jul 10, 2018 at 9:32 PM Mark Nottingham wrote: > I didn't find those, but I found many others. > > I'll start collecting. How about Tuesday, say 6:45-7:45pm? > > > > > On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: > > > > > > > >> On 11 Jul 2018, at 11:22 am, Mark Nottingham wrote: > >> > >> > >> > >>> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: > >>> > >>> On Jul 10, 2018, at 18:02, Adam Roach wrote: > >>> > >>>> In large part because DNS provides "a richer scheme that accommodate= s > address families and multiple addresses with priorities". > >>> > >>> *cups hand to ear* > >>> > >>> Was that the sound of a distant desire to specify use of SRV for HTTP= ? > >>> > >> > >> I recently did some digging on this topic, and can try to characterise > what the issues / objections are. > > > > I think there are three main objections. > > > > 1) Wildcards don=E2=80=99t work with prefixes. > > 2) Additional data isn=E2=80=99t always returned it may require multipl= e round > trips. > > 3) Additional data processing doesn=E2=80=99t support negative response= s. > > > > All of these issues are trivially easy to fix. It just require > willingness to implement. > > > > 1) is addressed by defining a new type(s) rather than using prefixes. > > 2) is addressed by getting recursive servers to fill in missing > additional data before returning. Named has code in review for this for > SRV as proof of concept. > > 3) is addressed by adding some signalling between the client and > recursive server to indicate if the additional section is complete or not= . > > > > > >> Would people be interested in a (hopefully brief) side meeting to > discuss and maybe come to a shared understanding of the problem space? > >> > >> Cheers, > >> > >> -- > >> Mark Nottingham https://www.mnot.net/ > >> > >> _______________________________________________ > >> DNSOP mailing list > >> DNSOP@ietf.org > >> https://www.ietf.org/mailman/listinfo/dnsop > > > > -- > > Mark Andrews, ISC > > 1 Seymour St., Dundas Valley, NSW 2117, Australia > > PHONE: +61 2 9871 4742 INTERNET: marka@isc.org > > -- > Mark Nottingham https://www.mnot.net/ > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > --=20 Joseph Lorenzo Hall Chief Technologist, Center for Democracy & Technology [https://www.cdt.org] 1401 K ST NW STE 200, Washington DC 20005-3497 e: joe@cdt.org, p: 202.407.8825, pgp: https://josephhall.org/gpg-key Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 1607 5F86 6987 40A9 A871 --000000000000a017e90570c0ba9f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm in, but will need to catch up on the convo...= I'll do so.

BTW, don't look at the Yelp/F= oursquare reviews for the social venue... yikes

On Tue, Jul 10, 2018 at 9:32 PM Mark No= ttingham <mnot@mnot.net> wrote:<= br>
I didn't find those, but I foun= d many others.

I'll start collecting. How about Tuesday, say 6:45-7:45pm?



> On 11 Jul 2018, at 11:30 am, Mark Andrews <marka@isc.org> wrote:
>
>
>
>> On 11 Jul 2018, at 11:22 am, Mark Nottingham <mnot@mnot.net> wrote:
>>
>>
>>
>>> On 11 Jul 2018, at 3:55 am, Joe Abley <jabley@hopcount.ca> wrote:
>>>
>>> On Jul 10, 2018, at 18:02, Adam Roach <adam@nostrum.com> wrote:
>>>
>>>> In large part because DNS provides "a richer scheme t= hat accommodates address families and multiple addresses with priorities&qu= ot;.
>>>
>>> *cups hand to ear*
>>>
>>> Was that the sound of a distant desire to specify use of SRV f= or HTTP?
>>>
>>
>> I recently did some digging on this topic, and can try to characte= rise what the issues / objections are.
>
> I think there are three main objections.
>
> 1) Wildcards don=E2=80=99t work with prefixes.
> 2) Additional data isn=E2=80=99t always returned it may require multip= le round trips.
> 3) Additional data processing doesn=E2=80=99t support negative respons= es.
>
> All of these issues are trivially easy to fix.=C2=A0 It just require w= illingness to implement.
>
> 1) is addressed by defining a new type(s) rather than using prefixes.<= br> > 2) is addressed by getting recursive servers to fill in missing additi= onal data before returning.=C2=A0 Named has code in review for this for SRV= as proof of concept.
> 3) is addressed by adding some signalling between the client and recur= sive server to indicate if the additional section is complete or not.
>
>
>> Would people be interested in a (hopefully brief) side meeting to = discuss and maybe come to a shared understanding of the problem space?
>>
>> Cheers,
>>
>> --
>> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>>
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org=
>> https://www.ietf.org/mailman/listinfo/dnsop<= br> >
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= INTERNET: marka@isc.org=

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

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--
Jo= seph Lorenzo Hall
Chief Technologist, Center for Democracy & Technol= ogy [https://www.cdt.org<= /a>]
1401 K ST NW STE 200, Washington DC 20005-3497
e: joe@cdt.org, p: 202.407.8825, pgp: <= a href=3D"https://josephhall.org/gpg-key" target=3D"_blank">https://josephh= all.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10 =C2=A01607 5F8= 6 6987 40A9 A871

--000000000000a017e90570c0ba9f-- From nobody Wed Jul 11 15:52:03 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CB30130E5D; Wed, 11 Jul 2018 15:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 ff8MedgjyJ12; Wed, 11 Jul 2018 15:51:48 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 980461274D0; Wed, 11 Jul 2018 15:51:48 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 640033AB044; Wed, 11 Jul 2018 22:51:48 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 4B821160043; Wed, 11 Jul 2018 22:51:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 32CE4160072; Wed, 11 Jul 2018 22:51:48 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id GchlsJqYTP_c; Wed, 11 Jul 2018 22:51:48 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 522C1160043; Wed, 11 Jul 2018 22:51:46 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <20180711212427.GA9723@localhost> Date: Thu, 12 Jul 2018 08:51:43 +1000 Cc: Mark Nottingham , Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <0D94DD5C-944F-46EC-BFC0-9D84B5CE4C2E@isc.org> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <20180711212427.GA9723@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jul 2018 22:51:51 -0000 > On 12 Jul 2018, at 7:24 am, Nico Williams = wrote: >=20 >>> On 11 Jul 2018, at 11:30 am, Mark Andrews wrote: >>>=20 >>>>> On 11 Jul 2018, at 3:55 am, Joe Abley wrote: >>>>>=20 >>>>> *cups hand to ear* >>>>>=20 >>>>> Was that the sound of a distant desire to specify use of SRV for >>>>> HTTP? >>>=20 >>> I think there are three main objections. >>>=20 >>> 1) Wildcards don=E2=80=99t work with prefixes. >>> 2) Additional data isn=E2=80=99t always returned it may require = multiple round trips. >>> 3) Additional data processing doesn=E2=80=99t support negative = responses. >>>=20 >>> All of these issues are trivially easy to fix. It just require = willingness to implement. >>>=20 >>> 1) is addressed by defining a new type(s) rather than using = prefixes. >=20 > While that is correct, and truly, it is trivial to implement, it is = not > trivial to deploy: too many DNS hosting providers would have to update > UIs. Garbage. There really isn=E2=80=99t. People keep saying something = can=E2=80=99t be done because there are too many X. X get replaced. X get updated. As for = DNS hosting providers that support a given type, we create a site and report what software by version and date and what DNS hosting providers support the type native or unknown formats. We also don=E2=80=99t have to achieve 100%. People can move to DNS = hosters that do support the type or host their own DNS. Every DNS hoster that = provides slave/secondary services already supports they type as UNKNOWN has been = out there so long. > Let me add my voice in favor of new RR types by which to replace SRV > RRs. URI is one of them, for the sorts of things we do in Kerberos = for > KDC discovery, but no really appropriate for resolving HTTP = authorities. >=20 >>> 2) is addressed by getting recursive servers to fill in missing = additional data before returning. Named has code in review for this for = SRV as proof of concept. >=20 > That would be very nice indeed. Unbound will need that too. >=20 >>> 3) is addressed by adding some signalling between the client and = recursive server to indicate if the additional section is complete or = not. >=20 > Well, OK, but as with (2) that requires recursive resolver critical > mass. Not necessarily a big deal, though it will take enough time = that > many apps will need to support falling back to doing multiple queries > one by one. They can do the queries in parallel, that 2 RTTs. > Nico > --=20 --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Wed Jul 11 17:48:48 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108C2130E97; Wed, 11 Jul 2018 17:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.861 X-Spam-Level: X-Spam-Status: No, score=0.861 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, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=2.851] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.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 jS1a9811JnNQ; Wed, 11 Jul 2018 17:48:39 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (homie-sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE3B5130DE3; Wed, 11 Jul 2018 17:48:39 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 0BCE03000271F; Wed, 11 Jul 2018 17:48:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to:content-transfer-encoding; s= cryptonector.com; bh=XUvykv0i+MVCLEuiTnSgoj3pEdc=; b=aNxOtNF46AC b9z/WAA977x+krL+m+XxaE5gYb0QW6dNSEXgotPxZcYydOohemLaPKWjaQUYZh+v hTyF2tCe4LJj22ygmT6SJiLmI1bvz9UQ+EgaSt9Vpg85wde7WDML5b+29/wWy50W gwUpIarzhfS8mUQo1FmFgD746Soek8SA= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id 475E63000271E; Wed, 11 Jul 2018 17:48:38 -0700 (PDT) Date: Wed, 11 Jul 2018 19:48:36 -0500 From: Nico Williams To: Mark Andrews Cc: Mark Nottingham , Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Message-ID: <20180712004835.GB9723@localhost> References: <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <20180711212427.GA9723@localhost> <0D94DD5C-944F-46EC-BFC0-9D84B5CE4C2E@isc.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <0D94DD5C-944F-46EC-BFC0-9D84B5CE4C2E@isc.org> User-Agent: Mutt/1.5.24 (2015-08-30) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 00:48:42 -0000 On Thu, Jul 12, 2018 at 08:51:43AM +1000, Mark Andrews wrote: > >>> 1) is addressed by defining a new type(s) rather than using prefixe= s. > >=20 > > While that is correct, and truly, it is trivial to implement, it is n= ot > > trivial to deploy: too many DNS hosting providers would have to updat= e > > UIs. >=20 > Garbage. There really isn=E2=80=99t. People keep saying something can= =E2=80=99t be done > because there are too many X. X get replaced. X get updated. As for = DNS > hosting providers that support a given type, we create a site and repor= t > what software by version and date and what DNS hosting providers suppor= t > the type native or unknown formats. I didn't mean to say not to go this way. On the contrary, we should. Just that this is an issue. > We also don=E2=80=99t have to achieve 100%. People can move to DNS hos= ters that > do support the type or host their own DNS. Every DNS hoster that provi= des > slave/secondary services already supports they type as UNKNOWN has been= out > there so long. Ah yeah, that's true -- not a great UI, but it works. > >>> 2) is addressed by getting recursive servers to fill in missing add= itional data before returning. Named has code in review for this for SRV= as proof of concept. > >=20 > > That would be very nice indeed. Unbound will need that too. > >=20 > >>> 3) is addressed by adding some signalling between the client and re= cursive server to indicate if the additional section is complete or not. > >=20 > > Well, OK, but as with (2) that requires recursive resolver critical > > mass. Not necessarily a big deal, though it will take enough time th= at > > many apps will need to support falling back to doing multiple queries > > one by one. >=20 > They can do the queries in parallel, that 2 RTTs. Yes, that's a big deal. From nobody Wed Jul 11 18:30:38 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 221DE130DC7; Wed, 11 Jul 2018 18:30:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 q1UkgWiTfb9x; Wed, 11 Jul 2018 18:30:23 -0700 (PDT) Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF9512F1A2; Wed, 11 Jul 2018 18:30:23 -0700 (PDT) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id EC7313AB03F; Thu, 12 Jul 2018 01:30:21 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D5F39160076; Thu, 12 Jul 2018 01:30:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id C0567160075; Thu, 12 Jul 2018 01:30:21 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vorCVgjZ3GOH; Thu, 12 Jul 2018 01:30:21 +0000 (UTC) Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 71EEA160043; Thu, 12 Jul 2018 01:30:19 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Andrews In-Reply-To: <20180712004835.GB9723@localhost> Date: Thu, 12 Jul 2018 11:30:16 +1000 Cc: Mark Nottingham , Joe Abley , dnsop@ietf.org, DoH WG , Adam Roach , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: References: <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <20180711212427.GA9723@localhost> <0D94DD5C-944F-46EC-BFC0-9D84B5CE4C2E@isc.org> <20180712004835.GB9723@localhost> To: Nico Williams X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Driu] [DNSOP] SRV and HTTP X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jul 2018 01:30:25 -0000 > On 12 Jul 2018, at 10:48 am, Nico Williams = wrote: >=20 > On Thu, Jul 12, 2018 at 08:51:43AM +1000, Mark Andrews wrote: >>>>> 1) is addressed by defining a new type(s) rather than using = prefixes. >>>=20 >>> While that is correct, and truly, it is trivial to implement, it is = not >>> trivial to deploy: too many DNS hosting providers would have to = update >>> UIs. >>=20 >> Garbage. There really isn=E2=80=99t. People keep saying something = can=E2=80=99t be done >> because there are too many X. X get replaced. X get updated. As = for DNS >> hosting providers that support a given type, we create a site and = report >> what software by version and date and what DNS hosting providers = support >> the type native or unknown formats. >=20 > I didn't mean to say not to go this way. On the contrary, we should. > Just that this is an issue. >=20 >> We also don=E2=80=99t have to achieve 100%. People can move to DNS = hosters that >> do support the type or host their own DNS. Every DNS hoster that = provides >> slave/secondary services already supports they type as UNKNOWN has = been out >> there so long. >=20 > Ah yeah, that's true -- not a great UI, but it works. >=20 >>>>> 2) is addressed by getting recursive servers to fill in missing = additional data before returning. Named has code in review for this for = SRV as proof of concept. >>>=20 >>> That would be very nice indeed. Unbound will need that too. >>>=20 >>>>> 3) is addressed by adding some signalling between the client and = recursive server to indicate if the additional section is complete or = not. >>>=20 >>> Well, OK, but as with (2) that requires recursive resolver critical >>> mass. Not necessarily a big deal, though it will take enough time = that >>> many apps will need to support falling back to doing multiple = queries >>> one by one. >>=20 >> They can do the queries in parallel, that 2 RTTs. >=20 > Yes, that's a big deal. It=E2=80=99s a self correcting problem though. Recursive nameservers do = get upgraded. If we could have got people on board back when I first submitted https://datatracker.ietf.org/doc/draft-andrews-http-srv/ everyone would = be using it and I suspect recursive servers would have been optimised to fetch = the additional data before returning. There is nothing in the RFC=E2=80=99s that says = you can=E2=80=99t stall the response to fetch additional data. This isn=E2=80=99t hard. It just = requires people to stop arguing and =E2=80=9CJust Do It=E2=80=9D. Also writing documentation that says =E2=80=9Cif the query has these = properties, fetch missing additional data=E2=80=9D will help. We could have done 5 or 6 transitions since 2000 on both the DNS and = HTTP sides. While there are long tails most of the world upgrades within 3 years. --=20 Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org From nobody Mon Jul 16 07:29:44 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF60130EE8; Mon, 16 Jul 2018 07:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=f4JYfvGw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=uFJqdxZh Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VFNSlrcAvWit; Mon, 16 Jul 2018 07:29:41 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07318131066; Mon, 16 Jul 2018 07:29:41 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 690A321C1B; Mon, 16 Jul 2018 10:29:40 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Mon, 16 Jul 2018 10:29:40 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=NUYyW+RlAusd7DdGyNwOXaRoVY1Km v9zD4VDHkOqB1c=; b=f4JYfvGwLBnEAFDpK1c4ly4zaKNBB+JexwsaRc8mV8g9E COUN9YCacdVWfgJiZB2c81XytAIHoMiJmH6U96rk91IDSVEZwl/YbSYeoMpJC5yb pVy6O6pj/iprCkdiOdgEUuvHERLa5ATEk9lyo5r4rYh47NWqBDGW69pE11aSnew+ 4kCykZb21nsGD0IJCxUVF9IMVnOZp8/XUrMj5LcokQ5MFBX/wEretNLmfdHWKKLH qx6/+rZ47bAbuEFWHSld+eLyETqhrbINUG3F+etTRo+gcvmf2A9GqaDgeBO9HkxA INA7tBsvG/8zAZ1he++GUUHE0hG0LComwY9JUj5OQ== 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=NUYyW+ RlAusd7DdGyNwOXaRoVY1Kmv9zD4VDHkOqB1c=; b=uFJqdxZhn+x26v/myz4Dib vcVUCUJ+xXJRboUN7jQfKVdqS5i7mVesdWjgKYAEEM4pRTTd+9+1ACeCrJudpwuk fZBQ8ORynGLnrokmu6IuCxWs4pJ/D26agyX8Dre3QwRzlSM1Ki+gEcX+QonmsbXm srd2D25JW/yYY4PoQ3AcpQlOhbBTCaYhWt/oq56bng8MciB7pIXLSviyUFwqX1v4 b4CO96krSapxRO1xiSVr6HJvt0unPkqSp+1XJtVJpyRDWtQtv4bR/socm+bJJnGY Cj/RfZzbkH9NYyL1vWF6APAf24KaYcrACVSgY/q+t0XOKxafcJHZP/NOuorLHwYA == X-ME-Proxy: X-ME-Sender: Received: from dhcp-9c22.meeting.ietf.org (dhcp-9c22.meeting.ietf.org [31.133.156.34]) by mail.messagingengine.com (Postfix) with ESMTPA id 1D76A10261; Mon, 16 Jul 2018 10:29:39 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Nottingham In-Reply-To: <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> Date: Mon, 16 Jul 2018 10:29:38 -0400 Cc: DoH WG , Adam Roach , driu@ietf.org, dnsop@ietf.org, HTTP Working Group , Joe Abley Content-Transfer-Encoding: quoted-printable Message-Id: <8840E959-EB84-4D60-BB4B-B8D944BF13AF@mnot.net> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> <23365.25333.904112.575031@gro.dd.org> <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> To: Dave Lawrence X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Driu] SRV and HTTP - 18:30 Tuesday (room change) X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jul 2018 14:29:43 -0000 Room change - we're now in Square Dorchester (the bigger room). Cheers, > On 10 Jul 2018, at 10:25 pm, Mark Nottingham wrote: >=20 > Sure, with the understanding that we'll probably start a few minutes = after that, given the session end at 16:20 (I'm chairing then, it = usually takes a little while to get out). >=20 > I've reserved Barre Oblique from 18:30 until 19:30 on Tuesday. >=20 > Cheers, >=20 >=20 >> On 11 Jul 2018, at 11:52 am, Dave Lawrence wrote: >>=20 >> Dave Lawrence writes: >>> Mark Nottingham writes: >>>> I'll start collecting. How about Tuesday, say 6:45-7:45pm? >>>=20 >>> Last session ends at 6:20 and social starts at 7, not sure how late >>> the last bus (if any?) will be leaving the hotel. >>=20 >> Nevermind, walking distance to social, under 1km. Maybe still though >> shifting it a little earlier, like 18:30. >>=20 >> _______________________________________________ >> DRIU mailing list >> DRIU@ietf.org >> https://www.ietf.org/mailman/listinfo/driu >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jul 17 16:43:27 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6570A130E2E; Tue, 17 Jul 2018 16:43:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.88 X-Spam-Level: X-Spam-Status: No, score=-0.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, 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 BalmXVON2zoL; Tue, 17 Jul 2018 16:43:18 -0700 (PDT) Received: from time-travellers.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0C0C128BAC; Tue, 17 Jul 2018 16:43:17 -0700 (PDT) Received: from [2001:67c:370:128:72e7:8f03:3ad9:63f1] by time-travellers.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ffZei-00016W-TR; Tue, 17 Jul 2018 23:45:21 +0000 Cc: DoH WG , driu@ietf.org, dnsop@ietf.org, HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> <23365.25333.904112.575031@gro.dd.org> <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> <8840E959-EB84-4D60-BB4B-B8D944BF13AF@mnot.net> From: Shane Kerr Message-ID: <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> Date: Tue, 17 Jul 2018 19:43:13 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <8840E959-EB84-4D60-BB4B-B8D944BF13AF@mnot.net> Content-Type: multipart/mixed; boundary="------------FC0954ACC0D8D1366B9E07A1" Content-Language: en-US Archived-At: Subject: Re: [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (room change) X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 23:43:19 -0000 This is a multi-part message in MIME format. --------------FC0954ACC0D8D1366B9E07A1 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit All, I took some random notes at the meeting. Apologies for any errors or misstatements. Cheers, -- Shane --------------FC0954ACC0D8D1366B9E07A1 Content-Type: text/markdown; name="srv-vs-http.md" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="srv-vs-http.md" 2018-07-17 Bar BoF with about 35 people. Mark Nottingham leads the discussion. Why not SRV for HTTP? Some work before: * draft-andrews-srv-http * New URI scheme also died. Use cases for SRV: 1. Load balancing 2. Service on alternate port Mark Andrews: Gets around CNAME at apex issue in DNS. Ray Bellis: Missing wildcard support, HTTPS only, more stuff. Mark Nottingham: From the web side, we have constraints. Have to be backwards compatible and cannot have a flag day. On the web it is critical to maintain security boundary based on the name. Martin Thompson: When we are talking about an unauthenticated method (DNSSEC notwithstanding), we are uncomfortable although that is changing. Ray Bellis: No reason not to have a record that matches this requirement. Mark Nottingham: Assumption was "just use SRV", but if we mean "SRV done right" then it is a different discussion. Cullen Jennings: What about getting it in a way that you can use it in every operating system? Mark Andrews: That is dead easy. If your resolver code does not support unknown RTYPEs then you are not compliant. Olafur Gudmondsson: One pain point is provisioning systems, the other is various libraries. Steward Cheshire: Within a C API it is easy. If Javascript it is more difficult. Mark Nottingham: I didn't see many web people concerned about how hard it is to set up a new record type. Erik Nygren: The performance hit of looking it up does not justify the work. But there is a new record type called ALTSVC is like an extensible SRV that covers additional use cases. It negotiates what port to use, and some other things which are actively being looked at (such as encrypted SNI). Mark Nottingham: This allows different name treated as the same origin. Not a working group document - being considered. Tale: About performance... that has been a major obstacle. Vendors want to get answers as quickly as possible. You could do server-side processing, but this doesn't help across boundaries and also, server-sides RR more difficult to get out. Patrick McManus: Protocol version negotiation in the DNS is attractive in many ways. But blocking is a real thing. ALTSVC fixes this by allowing connection to be made after or while connected to the primary service. Ben Schwartz: two modes, totally asynchronous or blocking. Tale: Asynchronous does not really address the same problem as SRV, since you have to connect to the primary origin which may be what you want to address. Ask Hansen: Server operators can get much better control, and clients implemented correctly can also get better behavior. ..... Paul Hoffman: What would you like now? We could do stuff. Mark Nottingham: Now that we have use cases, what are the appropriate paths now. Ray Bellis: SRV is for service type to target mapping. CNAME is supposed to be for hostname mapping, and that means every service. SRV is service-specific. Erik Nyren: Things that have transitional properties are very important. Always be a need for A and AAAA records at least for some decades. Mark Andrews: I have always expected legacy clients. [ discussion about deprecating technologies ] Kazuho Oku: Key distributed via DNS is a separate record, and also cannot handle the multiple CDN record since key cannot be shared. Ray Bellis: ANAME shifts work to resolvers; a really bad idea. Ben Schwartz: There are certain cases in TCP where you can risk a SYN/ACK, one RTT. Mark Nottingham: Interaction between web and DNS folks. I am not expecting a lot, but we should talk together and work better and learn the pain points and so on. Martin Thompson: Unfiltered messages coming through. We actually get TTL's from platforms (except Windows). This is a transition problem and we need to look at this in terms of transition problems. Browsers have an influence but they are not the only HTTPS clients. Mark Andrews: SPF working group did not give themselves enough time to switch from TXT to SPF. It requires libraries to be upgraded, along with browsers, and whatever else needs to be upgraded. This takes 3 or 4 years. Mark Nottingham: I am hearing that we don't know how to get from now to the end state. We need a roadmap. We need to meet security and performance while transitioning. Ben Schwartz: Some people seem to think transition is infinite. I think that it is large but probably finite. Are are there alternative means to reach our goals that cost less? Martin Thompson: I was not proposing that it was intractable transition. The apex problem is a pain, and externalizes the problem in various awful ways, and it would be better if we had a different system. HTTP is everywhere, embedded in all sorts of things. If the goal is to exterminate the current resolution... I don't see how every single person could be motivated to move. I can see some of them - certainly a browser - but there is a lot of HTTP out there. Patrick McManus: Service versus host in the industry is not a very important distinction. Load balancing solved in other ways. Apex issue may be an issue. Ray Bellis: Add an experimental type to BIND and just try it out. Kazuho Oku: I would prefer defining it in a way that provides consistency to convert to the same set of A or CNAME records. Ask Hansen: More like EDNS client subnet than MX records. Small percentage of servers that need it. Mark Nottingham: No specific actions. Where to discuss? [ everyone wants to discuss somewhere ] Action: Adam Roach will set up a mailing list. --------------FC0954ACC0D8D1366B9E07A1-- From nobody Tue Jul 17 16:44:35 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5925F128BAC; Tue, 17 Jul 2018 16:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUCoO0nimX5e; Tue, 17 Jul 2018 16:44:17 -0700 (PDT) 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 8F06B130E4F; Tue, 17 Jul 2018 16:44:17 -0700 (PDT) Received: from dhcp-99b3.meeting.ietf.org (dhcp-99b3.meeting.ietf.org [31.133.153.179]) (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 80FDD2420FDE; Tue, 17 Jul 2018 23:44:15 +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: <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> Date: Wed, 18 Jul 2018 00:44:12 +0100 Cc: dnsop@ietf.org, DoH WG , driu@ietf.org, HTTP Working Group Content-Transfer-Encoding: quoted-printable Message-Id: <48D7628C-8984-4210-80EE-EF8D41BCFE01@rfc1035.com> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> <23365.25333.904112.575031@gro.dd.org> <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> <8840E959-EB84-4D60-BB4B-B8D944BF13AF@mnot.net> <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> To: Shane Kerr X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (room change) X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jul 2018 23:44:20 -0000 > On 18 Jul 2018, at 00:43, Shane Kerr = wrote: >=20 > I took some random notes at the meeting. Apologies for any errors or = misstatements. Many thanks Shane!= From nobody Tue Jul 17 18:55:13 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34DB0130F04; Tue, 17 Jul 2018 18:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (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 pO3C5kYIPYR9; Tue, 17 Jul 2018 18:54:56 -0700 (PDT) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DC27130EDD; Tue, 17 Jul 2018 18:54:56 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id o11-v6so1112917wmh.2; Tue, 17 Jul 2018 18:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=swIbP99lbMlE18rsde009tjZxF39Sd4AXNd5LtW8okA=; b=Je3IyU3AqGap3pAkYJmNcLVCyeOFoPx4E1neopqd+PBb3MlW232Y/UKmw9u0XfuOcu HOoMz81Db5BdrS1DUmWV8dYc8C7JEUYU8pBlFNAH9uI2KcYFIXDyanRWJR3Xpd0JnIOx vUosM0zNTadmenIpcWcxyec0Lckjfn8stDIhsEcC2x+xvSg8AqWG1EXkdbmRj5/+FWBu qsD0QklmvYXYdgibeLgGXHItGOP3HXDJw15mCBvgFnVy89E7rDWiRx2jFf/74F5Q2Vsr FBYF9vXQmVISu6jLOd7rfFkPO9IK+Jc0IpWKiQepZwzSXqa825MUfs0qx5+amGqM/PHn 5yOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=swIbP99lbMlE18rsde009tjZxF39Sd4AXNd5LtW8okA=; b=GFz1kyb2/GekaUSwLsXJTyrOSsPOFlF9FzcQ2GSZYUgh4QXv3tMp4winyHvGQ9i6/j GlxvaFmFHa8ETzLJuaxP96mOP6FbBNlQXZkYEpO6Wc7JNgLuiV8hQ+B4qzWVwFGU7W7H dvDAxaaXdeHG21Xl/0cPh9yGSnUGpBYdtwXB29seOZIn5mxoRQOA2EqSr1NGKQrDM7Xq kqW/FUIepZwAbBIyllATldqPvVJJYvdVpF7kLpY78JHTUyzKJPUxsHf80eoK8YBguDvE WHIo8ZRvsdU7tzy5yUTicv21qxsizgK8uO7c4m/DkrI5fwqr9rRj2oB7u9/Sm6OJm9yL 0l9Q== X-Gm-Message-State: AOUpUlF79vQmhEggw/Vf9l3Zg6pjjMkfU/OwnvpwPHtqhXFabYoG9GB4 p9zF2L4IIHdXgj9nO/E/bnQkpvqbzI95hFH4A+R0ig== X-Google-Smtp-Source: AAOMgpeFdxEV6o6Z3VBcMH+Ysml56QN8qgQQrlSUHhTik4cnJYKKeLHNk2tk2RH94ckgn4OOUEGhKPZlY0j2kCxHmq0= X-Received: by 2002:a1c:b584:: with SMTP id e126-v6mr296664wmf.136.1531878895181; Tue, 17 Jul 2018 18:54:55 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:adf:a414:0:0:0:0:0 with HTTP; Tue, 17 Jul 2018 18:54:54 -0700 (PDT) In-Reply-To: <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> <23365.25333.904112.575031@gro.dd.org> <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> <8840E959-EB84-4D60-BB4B-B8D944BF13AF@mnot.net> <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> From: Tim Wicinski Date: Tue, 17 Jul 2018 21:54:54 -0400 Message-ID: To: Shane Kerr Cc: dnsop , DoH WG , driu@ietf.org, HTTP Working Group Content-Type: multipart/alternative; boundary="00000000000062e16005713c5998" Archived-At: Subject: Re: [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (room change) X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 01:55:00 -0000 --00000000000062e16005713c5998 Content-Type: text/plain; charset="UTF-8" These are great notes Shane. We're going to talk about APEX records in the DNSOP session in the morning. Tim On Tue, Jul 17, 2018 at 7:43 PM, Shane Kerr wrote: > All, > > I took some random notes at the meeting. Apologies for any errors or > misstatements. > > Cheers, > > -- > Shane > > _______________________________________________ > Doh mailing list > Doh@ietf.org > https://www.ietf.org/mailman/listinfo/doh > > --00000000000062e16005713c5998 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
These are great notes Shane.=C2=A0

We&#= 39;re going to talk about APEX records in the DNSOP session in the morning.= =C2=A0

Tim


On Tue, Jul 17, 2018 at 7= :43 PM, Shane Kerr <shane@time-travellers.org> wrote= :
All,

I took some random notes at the meeting. Apologies for any errors or missta= tements.

Cheers,

--
Shane

_______________________________________________
Doh mailing list
Doh@ietf.org
https://www.ietf.org/mailman/listinfo/doh


--00000000000062e16005713c5998-- From nobody Wed Jul 18 05:31:33 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D960131160; Wed, 18 Jul 2018 05:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 1YZSytCytc5q; Wed, 18 Jul 2018 05:31:19 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3DAD913115F; Wed, 18 Jul 2018 05:31:19 -0700 (PDT) Received: from bh-rezlocal-wmc1-vlan104.gw.mcgill.ca ([192.197.121.70]:57736 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fflbt-0004ye-E0 (Exim 4.72) (return-path ); Wed, 18 Jul 2018 13:31:13 +0100 To: Shane Kerr Cc: dnsop@ietf.org, DoH WG , driu@ietf.org, HTTP Working Group References: <4a845808-5348-d6e4-dda2-59aaf0e85c14@nostrum.com> <3DF5A66C-CCBF-4116-A1FC-35CF8E05808B@hopcount.ca> <82099DED-CCB6-4CDC-BFE6-97B1AB3EB0A4@isc.org> <7A9000F5-0772-49FC-BDBB-862C8141BA54@mnot.net> <23365.25230.573067.921128@gro.dd.org> <23365.25333.904112.575031@gro.dd.org> <1F3A6A86-3520-4AC9-BA2C-0A462F42BB60@mnot.net> <8840E959-EB84-4D60-BB4B-B8D944BF13AF@mnot.net> <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> From: Ray Bellis Message-ID: Date: Wed, 18 Jul 2018 08:31:13 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <10038742-b65c-7d38-0628-315c34555619@time-travellers.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Driu] [Doh] SRV and HTTP - 18:30 Tuesday (room change) X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jul 2018 12:31:22 -0000 On 17/07/2018 19:43, Shane Kerr wrote: > Ray Bellis: ANAME shifts work to resolvers; a really bad idea. correction here - what I actually said was that in the transitional phase ANAME shifts work to * authoritatives *. Ray From nobody Thu Jul 19 06:24:21 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5EDF129619; Thu, 19 Jul 2018 06:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsEqPQxPCiwJ; Thu, 19 Jul 2018 06:24:08 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 733C9130DCE; Thu, 19 Jul 2018 06:24:08 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id y5-v6so7112420qti.12; Thu, 19 Jul 2018 06:24:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:openpgp:autocrypt:to:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=3o/RwpN0E+Fy18PGNFM3uj4cOmjFivFruX8aWs/zrbA=; b=aoAEyMGvZTlvT0WUfOZbThjIfpXspvCpQno08kz7341GZPfIvZA8BqSK57zahefJHh kFs8L9B0/NtAdDK9P2xNVqV426+H8v/3vcnZillE+Yre4mvKfXzgrqtZhAOeJs4kIKlh o4BHxwOHakdR2xk4nP48UEyJU4006CNw79LGZRcm+Vrxv6/+lTzitNQc1sQhduV0sEE7 sRqQOMBLhGOAqhwSu1zywlyBl4pyn8cTyZ7CuH3W2iasmL0frWhYNUeso3TnaduUotgj xB7THY+fICf5tJA2zWk6yXpT0RMA3xSsgrWfegZmMVkS4f/gwkph/E3rm0FYorLNL7zA OJvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:openpgp:autocrypt:to:subject:message-id :date:user-agent:mime-version:content-language :content-transfer-encoding; bh=3o/RwpN0E+Fy18PGNFM3uj4cOmjFivFruX8aWs/zrbA=; b=f4NHbbQbMpw7AxrVl9ISm7KPXeMID5XGAXUzuS4NvapIPYfJjQyaLO1fS1WVsS2sAY OEsyBTedS3L+lFRk3QG6b+tWZJRc2y9WKf2447A8h1XLECOKXpReu3dhDBmtWdXZTQ3b i7lBFu2K1YAGJpbb1jYdVX7m7xlAST0ZEtFuJanC2UJ+0GPjUHifFmYHCOEqC01lKuD+ FjbfYQaq7R37J0DBu1hMz6+X4C4oKHDGXPEeDE4wECPpPX1XK05xX/kgmZguUlscKA1S Fc5HfiuzHWAfSKnJ6Jl42ohPvshiTELS/ktYckaxN5Ock20wipN7C9/bnZVVtdHl/tIp retQ== X-Gm-Message-State: AOUpUlG3Ey8onGtVWtm+6EqfK7xuRRlA54Oi5FmXpOYwLNUhknedb/mu 4TgDdpPDyK5hMnHD3krFx0kJCDFnm5g= X-Google-Smtp-Source: AAOMgpcO/J5zPP8cXuKJLyubLQyw2bo3Fj0yqSBtvDvtRz9Af+N2b6gaZ/cXPwwYzJcQcAdjb1atZQ== X-Received: by 2002:ac8:31cd:: with SMTP id i13-v6mr9634814qte.144.1532006647058; Thu, 19 Jul 2018 06:24:07 -0700 (PDT) Received: from [192.168.0.149] (modemcable106.203-177-173.mc.videotron.ca. [173.177.203.106]) by smtp.gmail.com with ESMTPSA id t1-v6sm4277224qkf.16.2018.07.19.06.24.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Jul 2018 06:24:06 -0700 (PDT) From: Tomek Mrugalski Openpgp: preference=signencrypt Autocrypt: addr=tomasz.mrugalski@gmail.com; prefer-encrypt=mutual; keydata= xsFNBFnoiMwBEADTmiPRnreg9BKxRAq5IixkTT6sMqpueC9kf3UGP3KAeO032wLkEdLd/ELW bhXv2Z0k2Jeq8N9qSsn0uiwlizPz1trH/lad/xQolv6529jhMdWvpt9iNpmjY/M0bdwG8E3e pSpYLg2p9TSa/N3XOIJYqcMHlWaqTlU+//5w2KXQd585+X68bfWmLJQvA371kUAp75PzwHJt zmL6SI5jZOhONPrisUnvEic1cW/VVLQ0RUc6O9+fmpyzoDKKXO/mKxjXScyE7hGmZI2Yr3X5 bf+wixXRnM6mYSocRbMYtPSotWo9UNRQCM3ns4Q8wf99Hbpy0kdLL3aD1NdgdJbIDcbONBj4 YX0bDiaWMKBuUsbBXe1wEUsmkwYxFSdKKJGiOQpDaOFSbiyn0HXAjj9iOcEOSjls03RHS0RV F59Ra0HTaIQIoqgPimjzZK3D7Yee8UKgzNQ/kvowJvom2H+GI6c4YXhluyDE1k869V/EIRO/ kxyznUaXT1kgD+v8YZESm/s5JG6gPYf2Whxp4zW0mRwJE1nJWUdrR/T5aYJatBhwdiYqhOzt qJm6HRihoAz7DxebsVtv/pH/EdX9K0yMdjw4y9cElrXQkUa5jFiPk5fhYcJFp1lxcMy+IZps FR4JUYUkB2gEKbLRp3o7g3PlA1DmeGOv3ojMAWOw9l1l9UDxHwARAQABzSBUb21layBNcnVn YWxza2kgPHRvbWFzekBpc2Mub3JnPsLBlAQTAQgAPhYhBBGZCpIDRNb+ndZDaYPU7qyYlWHJ BQJZ6IjMAhsjBQkJZgGABQsJCAcCBhUICQoLAgQWAgMBAh4BAheAAAoJEIPU7qyYlWHJ4d0Q AL46OqfV4zKmAqnHykElhm8hXmWkHHeIhkNIsmX5LdnkigxqAhg/K4nws74Zq9U53T1CBaTa SlxOGnWf+4LW/ZGN6mfp7IS5RcUL7O4O523dY+QRAy/goLBvnzzYL3wXFzmFRNyCoSUHJzwY h2R7PEeGZ8IpEuQA4lNodIKSXK3+iGQAi1kpWfuxD/Nd7bMtpvdmDJ74ZdtuOfgCqQPwvNMN xECTzDEM7K8+1AZtJ9Vk2YR5qNmlHSq/eQoyG3gAQ57Ym/duPTc2qacoJHFO6KGwHpbcnUo8 k5RZYPW5Cr84d4TXg0JmkgIMkDxrc+CgWMJDFIlbC2eS9TmOG3OALjqQ/0iy9athCkCPlq46 PJMKuMHbM5zhwkxJ4nPieLjpGtkewmkTMrQJUWcyuxJNLMdlIvZuioXrXcN9a5/N+UISaWaf tpZAhEK7J8LGTJzVfKP4j0CBRyFklKsuxw4mbZloJYe7JGEybwIArXF1LgXnFUS6S4xV4wyV mfZtd08nugTo407c2snWgNUHjt7g4VvKEXfss4cSg0B2MnBD8BSKcjCp16CDKZCOOKuNJELj outedf2FEGRMsSs26Xiz9uiS4UPjzuv9ZFGSL6fZ0cGaN3isKF4oDXG/YvXIoGwmRdzt+w7N OnU6rB7icW0fyccScFRxqFfImGdXZO20x8lIzsFNBFnoiMwBEADBPSEGUwIayl//i6LJWoy+ xJaMSdsiCvcIKcUUSFFRPvbpJ5vYeqoVVRr+EvobpwEYeoy9MGGXamPO6jC8E2Ufq/pxZAof 5x7Kt5GYs/qEgbJyLvQ+Fc9PADhfoJAZQU5Jm/oQ8lIl0CLPmIv62jtYlAPesK/YjPYoFzdQ fS9jOVso/WJrYVkKIG3+0RN8LOonR82Z1NIm1TXDuXVDLjLAr+M0k3UZwviup3eT/lh6xJkT Sg8/+DXIWv0SNtEkvNjxZPQwPB9WuvtqD/5SVR7QJifyqqq9T0EovFg0KHZognMPqIKiYfuZ 7SGFHBQZut58Fdg7C9kKwv3QoSwJc9jkMfMw2vcPJUoj41JwATAPSwF28Xqa4hBFHZZ/nY3p /3oJOXFW9ubYyf+YrsCbN30FxFN2bCerSZRahb2vkSgibxNjjvemM7YyuabUFfd5MXqBwS6M zFjeUEI/CWMAxfWWFykMisGT+w+rTAC9/YusuoeEAFldvOrSgN4anmQ85CHWGEx3lqNNCLEn hSi9W62MOptfHSGoLLJTz5V2AvGgXX1r4AKhr0upea3ALwXHB41/+wQYPD4uBGQvMb9wFavq 3bSglBZ9gvnk+P0EZ2Sfw8BU+AywDJF0PkFwK4on7zLMntgr73B6RNbsIDzWxXEUq1g94PEL B9nE7O+zEi7N1wARAQABwsF8BBgBCAAmFiEEEZkKkgNE1v6d1kNpg9TurJiVYckFAlnoiMwC GwwFCQlmAYAACgkQg9TurJiVYcmkeg/9Ha9VvXZFUEAEdiKlYJd+nSwdq3QVp5C44EHopblM /AO43OxJREaelc+OPeRo7OaAGtNosLNb1+ocYG6azZjaGyB8UcGXUpKakqzGapJZxbe5ugiI g2HgWsQx2cshfMLAz00z+gYjVkvvrffJeATnVSRJ3/VDxNfXt1SRNp20aw2r6FPTkMq+wQYj HKi4rW3NXMnnTVJd3zNepXEdaLl4o5wggOeWePKFN1bTpLZiBTJG7aWTltrRLzYC1z+4WIut GO1ytQbQV5PDtWncbsbcjtiegpJqNu6q8ThvzvHn1UyP/lx25Sjhgp9/5wOwiyDbZbrrNTks NtHkC36ObM9rRw+CfOkf+aTcM+zZB7TUlj924XzuhzqlLQcjuJZ1Tq4foNz2EeRVDvovZfyh JqO81nNEND4MQi8yumTm4G60IdMPSmJCl4TyIPQJ886h+omcE8hSpbEaMAuV0sLyNKcW3Zgs cQqyaeqX3EB3uHhT7cw6NEOkgzyN9tURCMtfnpVGKFA2fSZh1rXhB1yftxOxaBYTw1Wxp2KN DGllsvKOXjz57O9EI4dhqpd+Wl8z+q1jFc5+8g5Fkv8PWvFNF9h2C/knfNm+qj9w5PCcjkXJ EH3imij2e89rWloVAkSQK14sZNuAykzIUSjQv5gpcUPUpNqIJN4G7PqTiVUOrUt+SYc= To: dhcwg@ietf.org, driu@ietf.org Message-ID: <375c9e1d-1911-630d-efc0-7e045052299e@gmail.com> Date: Thu, 19 Jul 2018 09:24:04 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: [Driu] Comments on draft-pusateri-dhc-dns-driu-00 X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 13:24:11 -0000 Hi, I have read the draft-pusateri-dhc-dns-driu-00 draft and I like it. A lot. Here are some improvement suggestions. There are quite a few of them, but they are mostly editorial in nature and easy to fix. The basic proposal sounds good, at least from the DHCP perspective. Options are well designed and mostly follow guidelines of RFC7227. What should the client do if the options are no longer sent by the server when renewing or the server sends different values? Section 3: Each encapsulating option should be specified in a separate section for easier referencing. Section 4: The text suggests the options defined in 4.1-4.3 can appear only in DNS_TLS option, which is not true as they can also appear in DNS_DTLS. The text also incorrectly mentions four options (three are defined). Section 4.1: OPTION_IPV6 is not a good name. The name should be reasonably descriptive, so when looked upon on an all DHCP options list users would have some fighting chance to guess what this option is about. How about OPTION_DNSS_ADDR? The same applies to other names (OPTION_PORT and OPTION_URI). Adding the same prefix (DNSS? SDNS?) to all of them would be useful. When browsing a list of options it would be then immediately obvious that all of them serve similar goal and are supposed to be used together. Section 4.2: This text "The use of OPTION_ADN by the server is OPTIONAL but strongly encouraged." should use a stronger normative language, i.e. be rephrased to use SHOULD. Makes a lot of a difference for server implementors (we can print warnings when not configured) and test implementors (it's tricky to write reasonable testes for OPTIONAL and MAY). Section 4.3: "It defaults to port 853 as defined in Section 3.1 of [RFC7858]." We don't do option defaults in DHCPv6. This needs to be clarified. Do you want the server, when not explicitly configured, to send this option with a value of 853 or the client to assume value of 853 when the option is not sent by the server? These are two different things. The former would require extra per-option logic to be implemented on the server side and that's something the DHCP community likes to avoid. Having default client behavior is fine, though. I think this text should be moved to a separate client/server section. See the explanation below. Section 7: These are well written security considerations. Thanks for putting them out clearly. One aspect not mentioned here is time-based attack, such as using expired (or not yet valid) DNSSEC keys. I wish I could offer a solution to this problem. Mandating NTP_SERVER option wouldn't help much, it would just increase the attack complexity (a perpetrator would need to also spoof NTP server). Section 10.1: Why these all normative references? As a DHCP implementor, do I really need to read and understand the whole DoT and DoH to implement those options? I think most of them are informational, except 2119, 3315. There should be new client behavior and server behavior sections added. These sections are very useful for implementors and also help a lot avoiding confusion which side is supposed to do what. Also, that's what RFC7227 recommends (and provides some boiler plate text). The client behavior section should offer some guidance with relation to plain DNS options (RFC3646). Perhaps something like the following would make sense: "A client requesting DNS_TLS, DNS_DTLS and/or DNS_HTTPS SHOULD also request OPTION_DNS as a fallback mechanism. In legacy networks that do not support any of the new mechanisms, the client will receive only OPTION_DNS values. In such case the client should do X". I'm not sure what X would be. Perhaps adding a non-normative text explaining that a client can either chose to use plain servers and losing benefits of TLS/HTTPS or discard them and be left with unusable connection. The client behavior section should clarify the client is supposed to request only the container options, not the options within them. The RFC3315bis is around the corner (in RFC-Ed queue right now) and it will add two extra columns to the DHCPv6 options list. First specifies whether an option is a singleton (your draft already clearly says that multiple options are allowed). The second column is whether an option code can appear in ORO. My recommendation is to request only the container options. The A.1 appendix uses non-RFC3849 addresses. Thank you for using ISC software. Overall, with a bit of easy tweaking this draft will be in a great shape. It's been a long time since a new draft appeared in the DHC WG with such a well defined purpose, reasonable proposed solution and this level of maturity at -00. Finally, one comment with my DHC co-chair hat on. If the DRIU BoF turns out to be a WG forming one, this draft should be adopted there, not in DHC. However, if there is no better suited WG, we'll need to talk with our AD and will likely be able to do adoption call in DHC. Thank you for this work. Let me know if you need any help. Tomek Mrugalski From nobody Thu Jul 19 11:59:53 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB7CD130F0F; Thu, 19 Jul 2018 11:59:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 hCtBurbyX8qC; Thu, 19 Jul 2018 11:59:44 -0700 (PDT) Received: from oj.bangj.com (amt0.gin.ntt.net [129.250.11.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30600130E8B; Thu, 19 Jul 2018 11:59:44 -0700 (PDT) Received: from dhcp-9458.meeting.ietf.org (dhcp-9458.meeting.ietf.org [31.133.148.88]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 3DA25E1F; Thu, 19 Jul 2018 14:57:49 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Tom Pusateri In-Reply-To: <375c9e1d-1911-630d-efc0-7e045052299e@gmail.com> Date: Thu, 19 Jul 2018 14:59:41 -0400 Cc: dhcwg@ietf.org, driu@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <96A3B5BD-B4B6-4BAB-9C16-834EB2C517A6@bangj.com> References: <375c9e1d-1911-630d-efc0-7e045052299e@gmail.com> To: Tomek Mrugalski X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Driu] Comments on draft-pusateri-dhc-dns-driu-00 X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 18:59:47 -0000 > On Jul 19, 2018, at 9:24 AM, Tomek Mrugalski = wrote: >=20 > Hi, >=20 > I have read the draft-pusateri-dhc-dns-driu-00 draft and I like it. > A lot. >=20 > Here are some improvement suggestions. There are quite a few of them, > but they are mostly editorial in nature and easy to fix. The basic > proposal sounds good, at least from the DHCP perspective. Options are > well designed and mostly follow guidelines of RFC7227. >=20 > What should the client do if the options are no longer sent by the > server when renewing or the server sends different values? >=20 > Section 3: Each encapsulating option should be specified in a separate > section for easier referencing. >=20 > Section 4: The text suggests the options defined in 4.1-4.3 can appear > only in DNS_TLS option, which is not true as they can also appear in > DNS_DTLS. The text also incorrectly mentions four options (three are > defined). >=20 > Section 4.1: OPTION_IPV6 is not a good name. The name should be > reasonably descriptive, so when looked upon on an all DHCP options = list > users would have some fighting chance to guess what this option is > about. How about OPTION_DNSS_ADDR? The same applies to other names > (OPTION_PORT and OPTION_URI). Adding the same prefix (DNSS? SDNS?) to > all of them would be useful. When browsing a list of options it would = be > then immediately obvious that all of them serve similar goal and are > supposed to be used together. >=20 > Section 4.2: This text "The use of OPTION_ADN by the server is = OPTIONAL > but strongly encouraged." should use a stronger normative language, > i.e. be rephrased to use SHOULD. Makes a lot of a difference for = server > implementors (we can print warnings when not configured) and test > implementors (it's tricky to write reasonable testes for OPTIONAL and > MAY). >=20 > Section 4.3: "It defaults to port 853 as defined in Section 3.1 of > [RFC7858]." We don't do option defaults in DHCPv6. This needs to be > clarified. Do you want the server, when not explicitly configured, to > send this option with a value of 853 or the client to assume value of > 853 when the option is not sent by the server? These are two = different > things. The former would require extra per-option logic to be > implemented on the server side and that's something the DHCP community > likes to avoid. Having default client behavior is fine, though. I = think > this text should be moved to a separate client/server section. See the > explanation below. >=20 > Section 7: These are well written security considerations. Thanks for > putting them out clearly. One aspect not mentioned here is time-based > attack, such as using expired (or not yet valid) DNSSEC keys. I wish I > could offer a solution to this problem. Mandating NTP_SERVER option > wouldn't help much, it would just increase the attack complexity (a > perpetrator would need to also spoof NTP server). >=20 > Section 10.1: Why these all normative references? As a DHCP = implementor, > do I really need to read and understand the whole DoT and DoH to > implement those options? I think most of them are informational, = except > 2119, 3315. >=20 > There should be new client behavior and server behavior sections = added. > These sections are very useful for implementors and also help a > lot avoiding confusion which side is supposed to do what. Also, that's > what RFC7227 recommends (and provides some boiler plate text). >=20 > The client behavior section should offer some guidance with relation = to > plain DNS options (RFC3646). Perhaps something like the following = would > make sense: "A client requesting DNS_TLS, DNS_DTLS and/or DNS_HTTPS > SHOULD also request OPTION_DNS as a fallback mechanism. In legacy > networks that do not support any of the new mechanisms, the client = will > receive only OPTION_DNS values. In such case the client should do X". > I'm not sure what X would be. Perhaps adding a non-normative text > explaining that a client can either chose to use plain servers and > losing benefits of TLS/HTTPS or discard them and be left with unusable > connection. >=20 > The client behavior section should clarify the client is supposed to > request only the container options, not the options within them. The > RFC3315bis is around the corner (in RFC-Ed queue right now) and it = will > add two extra columns to the DHCPv6 options list. First specifies > whether an option is a singleton (your draft already clearly says that > multiple options are allowed). The second column is whether an option > code can appear in ORO. My recommendation is to request only the > container options. >=20 > The A.1 appendix uses non-RFC3849 addresses. Thank you for using ISC > software. >=20 > Overall, with a bit of easy tweaking this draft will be in a great > shape. It's been a long time since a new draft appeared in the DHC WG > with such a well defined purpose, reasonable proposed solution and = this > level of maturity at -00. >=20 > Finally, one comment with my DHC co-chair hat on. If the DRIU BoF = turns > out to be a WG forming one, this draft should be adopted there, not in > DHC. However, if there is no better suited WG, we'll need to talk with > our AD and will likely be able to do adoption call in DHC. >=20 > Thank you for this work. Let me know if you need any help. >=20 > Tomek Mrugalski Thanks for the encouraging feedback. We will be glad to make the = recommended changes. Tom From nobody Thu Jul 19 15:55:21 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFBAE130EA7 for ; Thu, 19 Jul 2018 15:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (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 myIwX13cSJQ5 for ; Thu, 19 Jul 2018 15:55:18 -0700 (PDT) Received: from mx4.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE61F130DD2 for ; Thu, 19 Jul 2018 15:55:17 -0700 (PDT) Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx4.open-xchange.com (Postfix) with ESMTPS id 91F066A27C for ; Fri, 20 Jul 2018 00:55:15 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1532040915; bh=xRHezSnMZ0znuE414QWyX2f7oATrCLQSWtrncad7Kjs=; h=Date:From:To:Subject:From; b=uJy6tqM+dnD10IsI3qP5EXG6Nf3PuDhtljwd85sVy+ZYG2lYMP2x7JciIlXFXVkEm HA0GZT9rWIwy0q4cvk5qBoZfjDi2xvuV0f/v8EAGfohWqJxQR4RySlJDsXvgTocXX5 NJodgOHOMo0iIJCStwzAJa+LkMkh781HAtQcPTFMHTLA6SGN9PKlHoskz3Pltu+Wf0 OTTDsjAj3O4sovgQJPOGvPWE/nWzZa6D7Lh9VpFw3AZsaf+Gh63Fol7e+1wvE1w4P2 mO74U4XyqbMSDum4YYl4NJt+TRw7suVmoZTYeqiwxWVT4fOLPm8K1mDUpfM65jciO4 nal6pHVZRMciA== Received: from null (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 8432F3C102F for ; Fri, 20 Jul 2018 00:55:15 +0200 (CEST) Date: Fri, 20 Jul 2018 00:55:15 +0200 (CEST) From: Vittorio Bertola To: driu@ietf.org Message-ID: <2065665402.3.1532040915491@appsuite.open-xchange.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Medium X-Mailer: Open-Xchange Mailer v7.10.0-Rev10 X-Originating-Client: open-xchange-appsuite Archived-At: Subject: [Driu] DoH Digests and privacy risks X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:55:20 -0000 Hello, =C2=A0 this started as a comment on Mark Nottingham's DoH Digests draft as present= ed today in the BoF, but in the end it deals with more fundamental issues w= ith DoH, so I'm sharing it with the list. I am a DNS policy guy, not an HTTP guy, and have not been involved in DoH u= ntil now. So I was struck by some statements: 1) While encrypted DNS transport removes the potential for MITM eavesdroppi= ng, it cannot do anything against privacy breaches by the entity running th= e resolver. The presentation mentioned, as the intended consequence of DoH,= that possibly we will get our name resolution from "big websites". Unfortu= nately, the business model of most big websites today relies on user data m= onetization, targeted advertising and so on; so these people would actually= have an economic incentive to log and correlate the user's DNS query histo= ry with other information that they gather elsewhere, much more than the ne= twork access providers. So IMHO in this regard DoH is threatening the user'= s privacy, rather than increasing it. 2) The draft, right in section 1, assumes that it's the "application's vend= or" that gets to vet which DoH servers are good for the user. One would exp= ect that it's rather the user that has the right decide who to trust with t= heir data - this is also the principle underlying most privacy laws around = the globe. The user is of course free to delegate that decision to a truste= d application vendor or to anyone else, but in the end, the architecture sh= ould be conceptually designed to empower the users, not application vendors= . Also, if one thinks at how many applications are responsible for user dat= a mistreatment and abuse, this looks like another dangerous policy decision= . So, either I do not understand the privacy threat model that is meant to be= addressed by DoH, or such model is perhaps incomplete; yes it's great to e= ncrypt DNS traffic so that no one can sniff or alter it, but that's not the= main source of privacy abuses today on the Internet; tracking, centralizat= ion and correlation of user activities across multiple services are. I looked into the main DoH draft as well, but at first sight, notwithstandi= ng the final sections, I could not find any analysis of these security and = privacy issues. So while in the end I really like the idea of spreading DoH= traffic across multiple services to make tracking and correlation harder, = I would first make sure that we have a shared understanding of all the priv= acy risks that have to be mitigated in this "new DNS ecosystem", and we wor= k on an architecture that addresses them all. Regards, --=20 Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy From nobody Thu Jul 19 15:57:42 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C894130ED1 for ; Thu, 19 Jul 2018 15:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQEy_LrbC2Cw for ; Thu, 19 Jul 2018 15:57:37 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE5D6130EE8 for ; Thu, 19 Jul 2018 15:57:34 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id k81-v6so18016279oib.4 for ; Thu, 19 Jul 2018 15:57:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=iOQo43nSJ7AIMe97yNTiWw91GCYOVcn1lGG2KEGQJYA=; b=WmSTyPeZfj/y/8HzRKR36J9mm3OaA9CT4DYbBke3mX5DMerXjYO3XuQ7I0fzQvYRHM DO2X67ptPkcN87KzkpXOHHAFNdWBfwSg5w8BCgLHJaQgwreamKRsg38RLiu2fAZJbYa3 fViFnPniQ0FjfqGzLjmiC656ZwUHWRvfAi7LtHFe7rsIKh+TPakQfAt8d7SZQ528Oppg x/OLPoFkig2G8mjuzkQEkinmDoGp0ySk7WvRHxnXtAJgdOqnI+YB0fe0aCoIDPVOx/cd hJ4sUYDmUoFW9zUijKIiAxFqj48OI3C0YH8adE+LsQTtkEgaQ7ylUpqiiJos6cq64hme wUTA== 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=iOQo43nSJ7AIMe97yNTiWw91GCYOVcn1lGG2KEGQJYA=; b=Ga2kuEGvqCWYorqXFb6OLmirpgXzHeT0gUCw9FXmTAYUSvnD6yb797X3cOnuaKChT4 AFLyoHnEeMg9Fq0iRnbGgSMaZVJkjvnBEQ9Deg/47rdKeupzWbhYHDQVOSrleIwJyNKT uj6PL1T44doh1qGhepiKOJrp0QSZsV23NJRUZV1U2rDghb8JvNW2ZU9MVteYCQhGo402 H02Qy6xBnFkC2pPHNSj5XusIzUeMvNANu7aJ1CiWdWZclPq8933eVTGAOaeGaRvhA4C8 aXdRut+wCDLuGiyfPDmkQKm2hwrXQ8757UDpvouvCX9hWg0enHvc56mQvGn/PyGOoebf XHfA== X-Gm-Message-State: AOUpUlHXl5fjWIMmc1XheETTV94tU9rxakBH+BkDF2PJ5D6eGxmpmy5E b4S+nL9xS2Mcyygz1LPWmgmvnzdABIh220wF6jOz661f X-Google-Smtp-Source: AAOMgpd3zCK9cYY/sSa19HcDt/JHqOIY3VR2UuD573SLvEg/uxf5g9iu/hozgUadOlgSe+JfFNiQywZgZUbLbPkMMA4= X-Received: by 2002:aca:2c83:: with SMTP id s125-v6mr29134ois.103.1532041053405; Thu, 19 Jul 2018 15:57:33 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:66d9:0:0:0:0:0 with HTTP; Thu, 19 Jul 2018 15:57:02 -0700 (PDT) From: Ted Hardie Date: Thu, 19 Jul 2018 18:57:02 -0400 Message-ID: To: driu@ietf.org Content-Type: multipart/alternative; boundary="000000000000c507730571621a36" Archived-At: Subject: [Driu] Query distribution vs. query routing X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jul 2018 22:57:40 -0000 --000000000000c507730571621a36 Content-Type: text/plain; charset="UTF-8" Howdy, The mic line interaction and related jabber traffic around Mark's draft were interesting, and they nicely illustrated just how confused I can be. Sorry for sharing that experience with the group. Where I think it's useful to dive in a little further is in the distinction between query distribution and query routing. Let's start by making a parallel: a device on a lan with a single router has a default next hop destination; that router may also have a default next hop destination. In both cases, all traffic leaving one device will go through the other (lan device to lan router; lan router to default upstream destination). In the router case, it's pretty common for there to be two different upstream possibilities, with the router making the choice between upstream possibilities for packets as they arrive from the device. That choice may be a simple algorithm that load balances between them, like ECMP, or it may be made by consulting a mapping that tells it which upstream is a better route to a specific destination network (that mapping being derived from data distributed by some routing protocol). At a hideously gross approximation, a host talking to a recursive resolver is in a parallel situation. It can have a single upstream resolver it talks to, or it can have more than one. If it has more than one, it may direct queries to them as a load balancing function, or as a function of the names one serves usually because one is configured to serve the local names in a split DNS situation. That configuration is the simple routing information in the parallel here. What I heard in the jabber room as explanatory text was that this proposal suggests allowing the default upstream server to name other default upstream servers, who could share the load of the query stream. There would be benefits to the upstreams in load-shedding and benefits to the device in reducing the information revealed to any particular upstream. I have some serious concerns there about whether the default upstream servers it names could be scoped to avoid this becoming a DOS vector, but even putting that aside, I think the incentive is poor. The local device already has a known good upstream with an established TCP/TLS/HTTP session going, and it's going to want to avoid the latency of establishment of load balancing in a lot of cases. What I originally thought was in the proposal was closer to distributing routing information. There, the server isn't distributing new default servers, it is distributing information about servers that are suited to answering queries about specific names. The choice to use them, in other words, wouldn't be based on load balancing, but on query routing--sending a query to the best available query responder from a latency or authority perspective. There's a whole bunch of work around securing routing information that we'd have to import if we went down this path. Down this path split DNS becomes fragmented DNS, in which you may find some answers are "reachable" and some are not. I can also read the document to be recommending a hybrid mode, in which every DOH responder agrees to be a default query path but still tells you which names it is well suited to resolve (giving you a situation like that in which a router gets multiple routing announcements that include both specific networks and a default route). There are a bunch of interesting possibilities there, both in optimizations and attacks. Ultimately, though, the incentive works only when this actually results in quicker connection setups and when both the DOH client and DOH responder care a great deal about that timing. What I think that turns out to mean, and this is from a very dusty crystal ball, is that a DOH responder will have to maintain a very robust DNS recursive resolver infrastructure if it agrees to be a default query path in order to attract query traffic bound for its network. That means a big cache, good connections to other DNS services, the lot. If it doesn't, its delays in responding to "default upstream" queries will be slower than those from other potential services, and a DNS client will eventually cease using them (presuming it is still testing optimization by query response time). If it still gets any queries, it will be along the "fragmented DNS" query model, where it gets only queries where the latency of its answers for specific networks is very important. I think those later in the line that were pointing out the risks of consolidation were right, in other words, and maybe didn't even go far enough. I think the end game of this model is that the user has no control over where the queries go and the heuristic system underneath them ends up sending them to site willing to offer the highest number of names (more specific routes) and the biggest DNS query infrastructure. That's going to land everything behind a few CDNS, unless I miss my guess. I'm sure I've made several additional howlers in this note, for which I apologize early, Ted --000000000000c507730571621a36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

The mic line interact= ion and related jabber traffic around Mark's draft were interesting, an= d they nicely illustrated just how confused I can be.=C2=A0 Sorry for shari= ng that experience with the group.

Where I think i= t's useful to dive in a little further is in the distinction between qu= ery distribution and query routing.

Let's star= t by making a parallel: a device on a lan with a single router has a defaul= t next hop destination; that router may also have a default next hop destin= ation.=C2=A0 In both cases, all traffic leaving one device will go through = the other (lan device to lan router; lan router to default upstream destina= tion).=C2=A0 In the router case, it's pretty common for there to be two= different upstream possibilities, with the router making the choice betwee= n upstream possibilities for packets as they arrive from the device.=C2=A0 = That choice may be a simple algorithm that load balances between them, like= ECMP, or it may be made by consulting a mapping that tells it which upstre= am is a better route to a specific destination network (that mapping being = derived from data distributed by some routing protocol).

=
At a hideously gross approximation, a host talking to a recursiv= e resolver is in a parallel situation.=C2=A0 It can have a single upstream = resolver it talks to, or it can have more than one.=C2=A0 If it has more th= an one, it may direct queries to them as a load balancing function, or as a= function of the names one serves usually because one is configured to serv= e the local names in a split DNS situation.=C2=A0 That configuration is the= simple routing information in the parallel here.

<= div>What I heard in the jabber room as explanatory text was that this propo= sal suggests allowing the default upstream server to name other default ups= tream servers, who could share the load of the query stream.=C2=A0 There wo= uld be benefits to the upstreams in load-shedding and benefits to the devic= e in reducing the information revealed to any particular upstream.=C2=A0 I = have some serious concerns there about whether the default upstream servers= it names could be scoped to avoid this becoming a DOS vector, but even put= ting that aside, I think the incentive is poor.=C2=A0 The local device alre= ady has a known good upstream with an established TCP/TLS/HTTP session goin= g, and it's going to want to avoid the latency of establishment of load= balancing in a lot of cases.=C2=A0

What I or= iginally thought was in the proposal was closer to distributing routing inf= ormation.=C2=A0 There, the server isn't distributing new default server= s, it is distributing information about servers that are suited to answerin= g queries about specific names.=C2=A0 The choice to use them, in other word= s, wouldn't be based on load balancing, but on query routing--sending a= query to the best available query responder from a latency or authority pe= rspective.=C2=A0 There's a whole bunch of work around securing routing = information that we'd have to import if we went down this path.=C2=A0 D= own this path split DNS becomes fragmented DNS, in which you may find some = answers are "reachable" and some are not.

I can also read the document to be recommending a hybrid mode, in whi= ch every DOH responder agrees to be a default query path but still tells yo= u which names it is well suited to resolve (giving you a situation like tha= t in which a router gets multiple routing announcements that include both s= pecific networks and a default route).=C2=A0 There are a bunch of interesti= ng possibilities there, both in optimizations and attacks.=C2=A0 Ultimately= , though, the incentive works only when this actually results in quicker co= nnection setups and when both the DOH client and DOH responder care a great= deal about that timing.=C2=A0

What I think t= hat turns out to mean, and this is from a very dusty crystal ball, is that = a DOH responder will have to maintain a very robust DNS recursive resolver = infrastructure if it agrees to be a default query path in order to attract = query traffic bound for its network.=C2=A0 That means a big cache, good con= nections to other DNS services, the lot.=C2=A0 If it doesn't, its delay= s in responding to "default upstream" queries will be slower than= those from other potential services, and a DNS client will eventually ceas= e using them (presuming it is still testing optimization by query response = time).=C2=A0 If it still gets any queries, it will be along the "fragm= ented DNS" query model, where it gets only queries where the latency o= f its answers for specific networks is very important.

<= /div>
I think those later in the line that were pointing out the risks = of consolidation were right, in other words, and maybe didn't even go f= ar enough.=C2=A0 I think the end game of this model is that the user has no= control over where the queries go and the heuristic system underneath them= ends up sending them to site willing to offer the highest number of names = (more specific routes) and the biggest DNS query infrastructure. That's= going to land everything behind a few CDNS, unless I miss my guess.
<= div>
I'm sure I've made several additional howlers in= this note, for which I apologize early,

Ted
--000000000000c507730571621a36-- From nobody Fri Jul 20 11:19:19 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E726130F6F for ; Fri, 20 Jul 2018 11:19:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 ETsyOTecIzXj for ; Fri, 20 Jul 2018 11:19:07 -0700 (PDT) Received: from mail-oi0-x243.google.com (mail-oi0-x243.google.com [IPv6:2607:f8b0:4003:c06::243]) (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 2D919130F3C for ; Fri, 20 Jul 2018 11:19:07 -0700 (PDT) Received: by mail-oi0-x243.google.com with SMTP id b15-v6so22874392oib.10 for ; Fri, 20 Jul 2018 11:19:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=TpYex4ZWK4YgRPeiRLYX/mkbZtFbJSn7tdC68QCNYtk=; b=mT3bikQ0Pxv7kWnKuMRXUIJObJWSOJzSWwycmaGoOiBv7img+6Riel0vpSosh0vM4X neqWGfBoCvsxu9/p9GmWbHRV6wxfxbOcfUTSRS/neo9Px6d024AULe9U9pjWPijIH6Pn eS9feC5Gyr0hs3gwMazQNyPpE8IRw2gEABMoGp3viAjPL9HAl3EWMN0CBy6PZq44bmvW KR5GnjKFBv0P12exmmJhYp1T03CXd0xeLG/pgLlDkMqzvHC84zo0xH06WW4YmR1r2ihH WKtzvd0E47AiIyif0fpi0kaVt8RV1e8qQUD428leeWc9zhno45FTZeZ1FjSZVsIdVh8x s6Tg== 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=TpYex4ZWK4YgRPeiRLYX/mkbZtFbJSn7tdC68QCNYtk=; b=XPk7HvFrT0BbPKucapBjnpoZEdHCU1wLs2VHjRODpP8R20Oc8pQJwI1K263wbWX7yp yb3IJKMDmJJKbzBoJLvq1Ed6sGawsMlkJxul4Mf30PFicxuYHfv4zpYat91awtVqZ/Qz EDzJyWB1+6HWgCvyUtg6V9r7Eu8hl61aBo9+Cjc8AbfY+g9r0ejStROWiDXmsFSA0ik5 llvqzfYCiiGG3bDVAVVQSnpE7/95bS24YB+fiNZNoGgxvN+w5DUEGpaahVtOcrQYrN8P czZj2ZEeLlQfyrV1/b1+ihf0MIR3jNNelwFF76p1e6nA7sM5t7LwEoMFM3xtDqDiq+sA YvEw== X-Gm-Message-State: AOUpUlFnKuDHDQ8ahiw1PxxMiGmD4javv0MaEYFsjIOHROB0czFP16Qo jF8cY9TOX+ylPI33S+n5U9aNOEr9uC/QXmhGRerPLJ4i X-Google-Smtp-Source: AAOMgpdVr7e+W+Yzns4LpNkqto8dIcIQ6WuERT6XLrNJyUc8opaW7QwT90WywncNvnJpNGHLQDUAcg4yrl+jQ5J1MfY= X-Received: by 2002:aca:5155:: with SMTP id f82-v6mr62127oib.272.1532110746366; Fri, 20 Jul 2018 11:19:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Martin Thomson Date: Fri, 20 Jul 2018 14:18:55 -0400 Message-ID: To: Ted Hardie Cc: driu@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Driu] Query distribution vs. query routing X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jul 2018 18:19:18 -0000 Thanks for sharing this Ted. I think that this is a conversation that this group needs to address before it gets to the point that any new work in this area is mature enough to be considered for a WG-forming BOF. One caution though: though DoH might have precipitated this conversation, and so it should take some of the blame for these issues, this is not a problem unique to DoH. It's a consequence of the notion that discovery is a fundamental part of DNS. On Thu, Jul 19, 2018 at 6:57 PM Ted Hardie wrote: > > Howdy, > > The mic line interaction and related jabber traffic around Mark's draft w= ere interesting, and they nicely illustrated just how confused I can be. S= orry for sharing that experience with the group. > > Where I think it's useful to dive in a little further is in the distincti= on between query distribution and query routing. > > Let's start by making a parallel: a device on a lan with a single router = has a default next hop destination; that router may also have a default nex= t hop destination. In both cases, all traffic leaving one device will go t= hrough the other (lan device to lan router; lan router to default upstream = destination). In the router case, it's pretty common for there to be two d= ifferent upstream possibilities, with the router making the choice between = upstream possibilities for packets as they arrive from the device. That ch= oice may be a simple algorithm that load balances between them, like ECMP, = or it may be made by consulting a mapping that tells it which upstream is a= better route to a specific destination network (that mapping being derived= from data distributed by some routing protocol). > > At a hideously gross approximation, a host talking to a recursive resolve= r is in a parallel situation. It can have a single upstream resolver it ta= lks to, or it can have more than one. If it has more than one, it may dire= ct queries to them as a load balancing function, or as a function of the na= mes one serves usually because one is configured to serve the local names i= n a split DNS situation. That configuration is the simple routing informat= ion in the parallel here. > > What I heard in the jabber room as explanatory text was that this proposa= l suggests allowing the default upstream server to name other default upstr= eam servers, who could share the load of the query stream. There would be = benefits to the upstreams in load-shedding and benefits to the device in re= ducing the information revealed to any particular upstream. I have some se= rious concerns there about whether the default upstream servers it names co= uld be scoped to avoid this becoming a DOS vector, but even putting that as= ide, I think the incentive is poor. The local device already has a known g= ood upstream with an established TCP/TLS/HTTP session going, and it's going= to want to avoid the latency of establishment of load balancing in a lot o= f cases. > > What I originally thought was in the proposal was closer to distributing = routing information. There, the server isn't distributing new default serv= ers, it is distributing information about servers that are suited to answer= ing queries about specific names. The choice to use them, in other words, = wouldn't be based on load balancing, but on query routing--sending a query = to the best available query responder from a latency or authority perspecti= ve. There's a whole bunch of work around securing routing information that= we'd have to import if we went down this path. Down this path split DNS b= ecomes fragmented DNS, in which you may find some answers are "reachable" a= nd some are not. > > I can also read the document to be recommending a hybrid mode, in which e= very DOH responder agrees to be a default query path but still tells you wh= ich names it is well suited to resolve (giving you a situation like that in= which a router gets multiple routing announcements that include both speci= fic networks and a default route). There are a bunch of interesting possib= ilities there, both in optimizations and attacks. Ultimately, though, the = incentive works only when this actually results in quicker connection setup= s and when both the DOH client and DOH responder care a great deal about th= at timing. > > What I think that turns out to mean, and this is from a very dusty crysta= l ball, is that a DOH responder will have to maintain a very robust DNS rec= ursive resolver infrastructure if it agrees to be a default query path in o= rder to attract query traffic bound for its network. That means a big cach= e, good connections to other DNS services, the lot. If it doesn't, its del= ays in responding to "default upstream" queries will be slower than those f= rom other potential services, and a DNS client will eventually cease using = them (presuming it is still testing optimization by query response time). = If it still gets any queries, it will be along the "fragmented DNS" query m= odel, where it gets only queries where the latency of its answers for speci= fic networks is very important. > > I think those later in the line that were pointing out the risks of conso= lidation were right, in other words, and maybe didn't even go far enough. = I think the end game of this model is that the user has no control over whe= re the queries go and the heuristic system underneath them ends up sending = them to site willing to offer the highest number of names (more specific ro= utes) and the biggest DNS query infrastructure. That's going to land everyt= hing behind a few CDNS, unless I miss my guess. > > I'm sure I've made several additional howlers in this note, for which I a= pologize early, > > Ted > _______________________________________________ > DRIU mailing list > DRIU@ietf.org > https://www.ietf.org/mailman/listinfo/driu From nobody Sun Jul 22 17:36:53 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22473130FA9 for ; Sun, 22 Jul 2018 17:36:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 SVpBCEgriKaz for ; Sun, 22 Jul 2018 17:36:50 -0700 (PDT) Received: from out.west.pexch112.icann.org (out.west.pexch112.icann.org [64.78.40.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CFF5130E09 for ; Sun, 22 Jul 2018 17:36:50 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Sun, 22 Jul 2018 17:36:48 -0700 Received: from PMBX112-W1-CA-1.pexch112.icann.org ([64.78.40.21]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([64.78.40.21]) with mapi id 15.00.1367.000; Sun, 22 Jul 2018 17:36:48 -0700 From: Paul Hoffman To: "driu@ietf.org" Thread-Topic: Minutes from the meeting Thread-Index: AQHUIh09HSZiytStH0mTuusrIKjQkg== Date: Mon, 23 Jul 2018 00:36:48 +0000 Message-ID: <7BF044A1-26E4-49FF-814C-6E9ACAFF69BB@icann.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [Driu] Minutes from the meeting X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 00:36:52 -0000 My cut at the minutes are at: https://datatracker.ietf.org/doc/minutes-102-driu/ Please let me know if I got any of that wrong. --Paul Hoffman From nobody Mon Jul 23 07:51:15 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C11C8130EAB for ; Mon, 23 Jul 2018 07:51:12 -0700 (PDT) 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=mnot.net header.b=FwzLK+dR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=B4HC8iWT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id alkDyZzTf115 for ; Mon, 23 Jul 2018 07:51:09 -0700 (PDT) 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 ACE22130EB0 for ; Mon, 23 Jul 2018 07:51:09 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 167AB21A49; Mon, 23 Jul 2018 10:51:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 23 Jul 2018 10:51:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm3; bh=kY3zaWEF1/9N3ygypBqWxfEYV7hEo NwmN7RWefM3ptA=; b=FwzLK+dR6EkjVqI2tplDMY7KSJz8+cRRl9Sv9nG7k70Vy yYRgAR9/xWzwg4i7tWTCXjcwVUCfRnBFDzHy3sV1IFMw7Rk34jHNpSSWr9p4sm6L ttgnGElLkqStwV3bo38DJwhFWYvYO5INvyekiiLeTahbFqToaXd+cXw7wob84pDu zzD9RLYv8SScVVzSZb2snrlhssVra1Zh/NUVJdsSXW0p3kclG1tBqO7sG5f4NYx7 Swp15UF6ruEYZZUkrhFB0jP3+pvOAxB5tPPq88i4ESLUMfgBCwfmADyhUhJES3CN 3KJwB+xeHm0DwIsTGRoBk8kPBQdS6r33lKQaqaMlw== 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-sender:x-me-sender:x-sasl-enc; s=fm3; bh=kY3zaW EF1/9N3ygypBqWxfEYV7hEoNwmN7RWefM3ptA=; b=B4HC8iWTy8r2+aR80v8frX ZeYQjx5IOgPp8almQYtzbF69bGgHVZpNeyuMNBF8ZQoAJ5ycrhO2pXuJQ46INFNU BHP6XVPOl3su2j3sfwM77kbmfDrV6LBgR1HF7Sl25AEA31nybcwvLpdLsTHSyigm KS+HDklTXfynVOurok5s2+6hV6wL3/+Qgv5iQ+GZxDodwJEXgtLEVm9+xAClalKH mh/g2aQQtfXZCBo2JJdmg+8hr5e3iYyF44T/ojKrJlvHCECN51KvxRfz0Jdz+fd3 Jx0PKCE54+5/pfTMtE8yi3BMRogm/cCVDO2cRPkSuBFx+KZ+RP6jQPEOITz1/9+g == X-ME-Proxy: X-ME-Sender: Received: from [10.114.21.149] (68-64-217-58.static.forethought.net [68.64.217.58]) by mail.messagingengine.com (Postfix) with ESMTPA id C2BA6E4513; Mon, 23 Jul 2018 10:51:07 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Mark Nottingham In-Reply-To: <7BF044A1-26E4-49FF-814C-6E9ACAFF69BB@icann.org> Date: Mon, 23 Jul 2018 08:51:06 -0600 Cc: "driu@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4DC7815B-130D-4E6B-B2C6-DC13671155F1@mnot.net> References: <7BF044A1-26E4-49FF-814C-6E9ACAFF69BB@icann.org> To: Paul Hoffman X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Driu] Minutes from the meeting X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jul 2018 14:51:13 -0000 Hi Paul, > encourage large web sites to host DoH servers, and that > those sites could advertise that they could act as DoH servers for = other sites > as well. I'd say that as: """ Encourage large web sites to host DoH servers by giving clients = information about what hostnames they also serve HTTP traffic for. """ Cheers, > On 22 Jul 2018, at 6:36 pm, Paul Hoffman = wrote: >=20 > My cut at the minutes are at: > https://datatracker.ietf.org/doc/minutes-102-driu/ > Please let me know if I got any of that wrong. >=20 > --Paul Hoffman >=20 > _______________________________________________ > DRIU mailing list > DRIU@ietf.org > https://www.ietf.org/mailman/listinfo/driu -- Mark Nottingham https://www.mnot.net/ From nobody Thu Jul 26 09:22:37 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 542151310C3 for ; Thu, 26 Jul 2018 03:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, TVD_SPACE_RATIO=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 fdZad8dv4RSi for ; Thu, 26 Jul 2018 03:48:39 -0700 (PDT) Received: from hydrogen.portfast.net (hydrogen.portfast.net [188.246.200.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD6DB1310E3 for ; Thu, 26 Jul 2018 03:48:39 -0700 (PDT) Received: from [88.212.170.147] (port=50442 helo=rays-mbp.local) by hydrogen.portfast.net ([188.246.200.2]:465) with esmtpsa (fixed_plain:ray@bellis.me.uk) (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) id 1fidoz-0006pb-Ab (Exim 4.72) for driu@ietf.org (return-path ); Thu, 26 Jul 2018 11:48:37 +0100 To: "driu-request@ietf.org" From: Ray Bellis Message-ID: Date: Thu, 26 Jul 2018 11:48:38 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Thu, 26 Jul 2018 09:22:35 -0700 Subject: [Driu] subscribe X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jul 2018 10:48:42 -0000 From nobody Sat Jul 28 09:32:37 2018 Return-Path: X-Original-To: driu@ietfa.amsl.com Delivered-To: driu@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A48313112F; Sat, 28 Jul 2018 09:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_SOFTFAIL=0.665, 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 1LHR9oc1sEUa; Sat, 28 Jul 2018 09:32:06 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id C8006131058; Sat, 28 Jul 2018 09:32:05 -0700 (PDT) Received: from mail-oi0-f48.google.com (mail-oi0-f48.google.com [209.85.218.48]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3E0353A01E; Sat, 28 Jul 2018 12:32:04 -0400 (EDT) Received: by mail-oi0-f48.google.com with SMTP id 13-v6so14401967ois.1; Sat, 28 Jul 2018 09:32:04 -0700 (PDT) X-Gm-Message-State: AOUpUlEgs9tLYUFMInrRu5Ed1/r6qRSyB9pQWcfS2V6E6xBmqwyb/Ddh h/hGbAcvoEI/gIA442lIIaxCH5f9LC0tBR7Wkhk= X-Google-Smtp-Source: AAOMgpe3GfMsU8IPLMBVMGcTYzO5YR2A132mu6+fScl/bN/My52Qoncd98FN47XywI0p+XDbx93EUAyTeO21dD3DrRA= X-Received: by 2002:aca:31c6:: with SMTP id x189-v6mr11878333oix.213.1532795523956; Sat, 28 Jul 2018 09:32:03 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:8a22:0:0:0:0:0 with HTTP; Sat, 28 Jul 2018 09:32:02 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Sat, 28 Jul 2018 12:32:02 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Patrick McManus , DNS Privacy Working Group Cc: Ben Schwartz , Daniel Kahn Gillmor , DoH WG , driu@ietf.org, HTTP Working Group , dnsop Content-Type: multipart/mixed; boundary="000000000000b82213057211c474" Archived-At: Subject: Re: [Driu] Resolverless DNS Side Meeting in Montreal X-BeenThere: driu@ietf.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: "DNS Resolver Identification and Use \(DRIU\)." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Jul 2018 16:32:16 -0000 --000000000000b82213057211c474 Content-Type: multipart/alternative; boundary="000000000000b8220f057211c472" --000000000000b8220f057211c472 Content-Type: text/plain; charset="UTF-8" Hi All - This is a wrap-up email for the Resolverless DNS meeting held on July 16 in Montreal. We had, by my rough count, about 50 people and two sets of minutes are attached. If you attended, contributed, or took minutes (Thanks Shane and Ben!) thank you - it was, imo, a productive, professional, and even pretty focused discussion. We identified a next step: using an AD sponsored list (See Below!), identify one minimal context or use case that provides value for using DNS information without direct recursive resolver contact, and enumerate the concerns and potential mitigations for those concerns. If we can focus on that and make some progress then we might have a proposal for a future BoF - if we cannot make progress then that is also telling. Adam and Warren have setup a list for us to use. I apologize to the various working group's cc'd on this so far (and thank them for their indulgence) - future communications should move to the new list. New List Info ------------------- https://www.ietf.org/mailman/listinfo/resolverless-dns -Patrick On Mon, Jul 9, 2018 at 10:49 PM, Patrick McManus wrote: > Hi All, > > I am organizing an ad-hoc Side Meeting regarding 'Resolverless DNS' in > Montreal. > > We have often talked about the benefits and concerns of DNS information > obtained from sources that are, shall we say, less globally trusted than a > recursive a resolver. The central use case is DoH when pushed from an > endpoint that isn't a recursive resolver but there have been other > proposals. > > For example www.example.com pushes you a AAAA record for img1.example.com. > Should you use it? What if it is for img1.img-example.com ? Do the > relationship between these domains matter? What kind of relationship (i.e. > it could be a domain relationship, or in the context of a browser it might > be a first-party tab like relationship, etc..)? What are the implications > of poison? Trackers? Privacy of requests never made? Speed? Competitive > shenanigans or DoS attacks? > > This was out of scope for DoH. > > *We'll do the meeting over 1 hour in the Dorchester room from 16:30 to > 17:30 on Monday July 16th.* > > This is a meeting of interested folks looking to see if we can agree on > next steps - we're not going to work out the details (nor should a side > meeting try and do so). so we'll have a tight agenda that I suggest > organizaing as follows: > > 1] What forms of transport could be in scope? HTTP/2 push is one such > vector, but I've heard others. Spray paint for example. > > 2] What needs to be considered when using such data? (signatures? scope? > etc?) > > 3] Who are the stakeholders for 1 + 2? > > 4] Is there enough interest to explore further? Next steps as output > > I hope you can come! > > -Patrick > > --000000000000b8220f057211c472 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All -

This is a wrap-up email for=20 the Resolverless DNS meeting held on July 16 in Montreal. We had, by my rou= gh count, about 50 people and two sets of minutes are attached. If you attended,=20 contributed, or took minutes (Thanks Shane and Ben!) thank you - it was, imo, a productive, professional, and even pretty focused discussion.
=

We identified a next step: using an AD sponsored list (See Below!),=20 identify one minimal context or use case that provides value for using=20 DNS information without direct recursive resolver contact, and enumerate the concerns and potential mitigations for those concerns. If we can=20 focus on that and make some progress then we might have a proposal for a future BoF - if we cannot make progress then that is also telling.

Adam and Warren have setup a list for us to use. I apologize to the various=20 working group's cc'd on this so far (and thank them for their=20 indulgence) - future communications should move to the new list.
=
New List Info
-------------------

<= br>
-Patrick



On Mon, Jul 9= , 2018 at 10:49 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
Hi All,

I am organizing an ad-hoc Side Meeting regar= ding 'Resolverless DNS' in Montreal.

We ha= ve often talked about the benefits and concerns of DNS information obtained= from sources that are, shall we say, less globally trusted than a recursiv= e a resolver. The central use case is DoH when pushed from an endpoint that= isn't a recursive resolver but there have been other proposals.
<= div>
For example www.example.com pushes you a AAAA record for img1.example.com. Should you use i= t? What if it is for img1.img-example.com ? Do the relationship between these domains ma= tter? What kind of relationship (i.e. it could be a domain relationship, or= in the context of a browser it might be a first-party tab like relationshi= p, etc..)? What are the implications of poison? Trackers? Privacy of reques= ts never made? Speed? Competitive shenanigans or DoS attacks?
This was out of scope for DoH.

We&#= 39;ll do the meeting over 1 hour in the Dorchester room from 16:30 to 17:30= on Monday July 16th.

This is a meeting of int= erested folks looking to see if we can agree on next steps - we're not = going to work out the details (nor should a side meeting try and do so). so= we'll have a tight agenda that I suggest organizaing as follows:
=

1] What forms of transport could be in scope? HTTP/2 pu= sh is one such vector, but I've heard others. Spray paint for example.<= br>

2] What needs to be considered when using such= data? (signatures? scope? etc?)

3] Who are the st= akeholders for 1 + 2?

4] Is there enough interest = to explore further? Next steps as output

I hop= e you can come!

-Patrick


--000000000000b8220f057211c472-- --000000000000b82213057211c474 Content-Type: text/plain; charset="US-ASCII"; name="side_meeting_notes.txt" Content-Disposition: attachment; filename="side_meeting_notes.txt" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jjpujtvq1 UGF0cmljazogTXkgZ29hbCBpcyB0byBmaW5kIHdoZXRoZXIgdGhlcmUgYXJlIGVub3VnaCBpbnRl cmVzdGVkIHBlb3BsZSB0byB0cnkgdG8gc29sdmUgc29tZXRoaW5nLgpNeSB1c2UgY2FzZSBpcyB2 ZXJ5IHNpbXBsZTogc2tpcHBpbmcgYW4gb24tdGhlLXdpcmUgRE5TIGV4Y2hhbmdlIGNhbiBwcm92 aWRlIGJldHRlciBzZWN1cml0eSwgcHJpdmFjeSwgYW5kIHBlcmZvcm1hbmNlLiAgQ2FuIHdlIGRv IGl0IHNhZmVseT8KClBhcnQgMTogV2hhdCBhcmUgdGhlIHBvc3NpYmxlIHVzZSBjYXNlcyBhbmQg dHJhbnNwb3J0cz8gIEhUVFAvMiBQVVNIPwpQYXJ0IDI6IFdoZW4gaXMgaXQgc2FmZSB0byB1c2Ug dGhlc2UgcmVjb3Jkcz8KCkRLRzogSSB0aGluayB0aGlzIGlzIHBvdGVudGlhbGx5IHVzZWZ1bCBp biBhIGxvdCBvZiBkaWZmZXJlbnQgcGxhY2VzLiAgV2UgbmVlZCB0byBiZSB2ZXJ5IGNsZWFyIGFi b3V0IHRoZSBjb250ZXh0IG9mIHRoZSBkYXRhLiAgTm90IG9ubHkgImlzIGl0IGFjY2VwdGFibGUg ZGF0YT8iLCBidXQgIndoZW4gbWlnaHQgdGhpcyBkYXRhIGJlIHVzYWJsZT8iLiAgSW4gVExTLCB3 ZSB3ZXJlIGp1c3QgdGFsa2luZyBhYm91dCBETlNTRUMtY2hhaW4gVExTIGV4dGVuc2lvbiwgYnV0 IHRoZXJlIHdpbGwgYmUgbWFueSBvdGhlciBvcHBvcnR1bml0aWVzLiAgV2UgaGF2ZSB0bwoKSm9o biBSaWNoYXJkc29uOgpJJ20gcmVhbGx5IGNvbmNlcm5lZCB0aGF0IGRvaW5nIEROUyBvdmVyIERP SCBpbnRyb2R1Y2VzIHRoZSBwb3NzaWJpbGl0eSBvZiB0aGUgaW50ZXJuZXQgbG9va2luZyBkaWZm ZXJlbnQgZGVwZW5kaW5nIG9uIHdoaWNoIHdlYnBhZ2UgeW91J3JlIHVzaW5nIGF0IGEgZ2l2ZW4g dGltZS4gIFdlIG5lZWQgdG8gdGFsayBhYm91dCB3aGV0aGVyIHdlIHdpbGwgaG9ub3IgdGhlIHRy YWRpdGlvbmFsIHNpbmdsZSByb290IG9mIEROUy4KClBhdWwgSG9mZm1hbjoKSSB0aGluayB3ZSdy ZSBnb2luZyB0byBoYXZlIGFuIGlzc3VlIHRoYXQgdGhlIHN1YmplY3QgbGluZSBzYWlkICJSZXNv bHZlcmxlc3MiLCBhbmQgaW4gRE9IIHRoZXJlIGlzIGEgcmVzb2x2ZXIgKHRoZSBIVFRQIHNlcnZl cikuICBXZSBoYXZlIHR3byB1c2UgY2FzZXMgaGVyZTogdGhlIG9uZSB0aGF0J3MgYWN0dWFsbHkg InJlc29sdmVybGVzcyIgYW5kIERPSCB3aGVyZSB0aGVyZSBpcy4KCkRLRzogSSB0aGluayB3ZSdy ZSB0YWxraW5nIGFib3V0IGdldHRpbmcgRE5TIGZyb20gcGxhY2VzIHdoZXJlIHdlIGhhdmVuJ3Qg Z290dGVuIEROUyBpbiB0aGUgcGFzdCwgZS5nLiBIVFRQLzIgUFVTSCBmcm9tIGEgcmFuZG9tIHdl YnNpdGUuICBJIGRpZG4ndCBhc2sgZm9yIHRob3NlIHJlY29yZHMuCgpQYXVsIEhvZmZtYW46IFRo YXQgc2l0ZSB3YXMgbm90IGEgY29uZmlndXJlZCBET0ggc2VydmVyLgoKUGF0cmljazogUmlnaHQs IHRoaXMgaXMgYWJvdXQgYSBjYXNlIHdoZXJlIHlvdSBnZXQgYSByZWNvcmQgZnJvbSBhIHNlcnZl ciB0aGF0IGlzIG5vdCBjb25maWd1cmVkLiAgRG8gd2Ugd2FudCB0byB0YWtlIGEgbmV4dCBzdGVw IHRvIGdpdmUgdGhhdCBzb21lIG1lYW5pbmcuCgpKb2huOgpZb3UgdGFsa2VkIGFib3V0ICJ3aGVy ZSB0aGUgRE5TIGNvbWVzIGZyb20iLiAgRG8geW91IG1lYW4gdGhlIHNlcnZlciwgb3IgdGhlIHpv bmU/ICBJbiBteSBtaW5kLCBpdCBjb21lcyBmcm9tIHRoZSBhdXRob3JpdGF0aXZlIHNlcnZlci4K CkRLRzoKSSBtZWFudCB0aGF0IHRoZSBjaGFubmVsIGJ5IHdoaWNoIHRoZSBhcHBsaWNhdGlvbiBy ZWNlaXZlZCB0aGUgcmVjb3JkIG1heSBub3QgYmUgaW5kaWNhdGl2ZSBvZiBob3cgcmVsaWFibGUg aXQgaXMuCgpUYWxlOgpZb3UgZG9uJ3QgbmVjZXNzYXJpbHkgbmVlZCBhIHJlc29sdmVyIGluIHRo YXQgcGlwZWxpbmUuICBJZiB5b3UncmUgdGFsa2luZyB0byBhIENETiwgdGhleSBjYW4gdGVsbCB5 b3UgaW5mb3JtYXRpb24gYWJvdXQgem9uZXMgdGhhdCB0aGV5IGhvc3QsIHdpdGggRE5TU0VDIHNp Z25hdHVyZXMsIHdpdGhvdXQgZXZlciBoYXZpbmcgdG8gYXNrIGEgcmVzb2x2ZXIgYmVjYXVzZSB0 aGV5IGFscmVhZHkgaGF2ZSB0aGUgbWFwcGluZy4gIEl0IHNob3VsZCBiZSBjb25zaXN0ZW50IHdp dGggd2hhdCB5b3Ugd291bGQgZ2V0IGlmIHlvdSBhc2tlZCBvdmVyIHRoZSBETlMgcHJvdG9jb2wu CgpNaWtlIEJpc2hvcDoKQW5kIHRoYXQncyB3aGVyZSB3ZSBnZXQgaW50byBzb21lIGRldGFpbHMs IGJlY2F1c2UgZGVwZW5kaW5nIG9uIGNsaWVudCBJUCB5b3UncmUgZ29pbmcgdG8gZ2V0IGRpZmZl cmVudCByZXNwb25zZXMgZGVwZW5kaW5nIG9uIHdobyBhc2tzLiAgV2l0aCBBbHQtU3ZjIHlvdSBj YW4gYWxyZWFkeSBnZXQgYW5zd2VycyB0aGF0IHlvdSBtaWdodCBuZXZlciBnZXQgdGhyb3VnaCB0 aGUgRE5TLiAgQW4gZXhhbXBsZSBpcyBjb2FsZXNjaW5nOiBSRkMgNzU0MCBzYXlzIHRvIGNoZWNr IHRoZSBETlMgcmVjb3JkcyBiZWZvcmUgeW91IGNvYWxlc2NlIGV2ZW4gaWYgdGhleSdyZSBhbGwg b24gdGhlIHNhbWUgY2VydGlmaWNhdGUuICBCdXQgc29tZSBwcm9wZXJ0aWVzIHdvdWxkIGxpa2Ug dG8gcm91dGUgZGlmZmVyZW50IHVzZXJzIHRvIGRpZmZlcmVudCBJUCBhZGRyZXNzZXMgYnV0IGFs c28gYWxsb3cgY29hbGVzY2luZy4KClNhcmE6ClRoaXMgaXMgYSB2ZXJzaW9uIG9mIHNwbGl0IGhv cml6b24uCgpUYWxlOgpDb25zaXN0ZW50IHdpdGggdGhlIEROUyBidXQgbm90IGlkZW50aWNhbC4g IFRvIHRoZSBleHRlbnQgdGhhdCB5b3UgYXJlIG1ha2luZyBhbiBhdHRlc3RhdGlvbiBhYm91dCBh IG5hbWUgdW5kZXIgYSBwYXJ0aWN1bGFyIGRvbWFpbiwgdGhhdCBjb21lcyBmcm9tIHRoZSBJQ0FO TiBzdXBlcnN0cnVjdHVyZS4KClBhdHJpY2s6CkluIEhUVFBTLCBXZWJQS0kgaXMgdGhlIHNlY3Vy aXR5IHN5c3RlbS4gIFdlIGFsbG93IElQIE1JVE0gYmVjYXVzZSB0aGF0J3Mgbm90IHBhcnQgb2Yg dGhlIGF1dGhlbnRpY2F0aW9uIG1vZGVsLiAgSWYgdGhhdCdzIHlvdXIgc2VjdXJpdHkgbW9kZWws IHlvdSBtYXkgbm90IGJlIGFsbCB0aGF0IGNvbmNlcm5lZCBhYm91dCBhdHRlc3RhdGlvbi4gIFRo ZXJlIG1heSBiZSBvdGhlciBjb25jZXJucywgYnV0IGl0J3Mgbm90IG5lY2Vzc2FyaWx5IGFib3V0 IGF1dGhlbnRpY2F0aW9uIG9mIHlvdXIgcGVlci4gIENvbmNlcm5zIGxpa2UgY29tcGV0aXRpdmUg aXNzdWVzIChjYXB0dXJpbmcgdHJhZmZpYyksIGVudGl0aWVzIGJlaW5nIGFibGUgdG8gYWRkIHRo ZW1zZWx2ZXMgdG8gdGhlIHBhdGgsIGFtcGxpZmljYXRpb24gb2YgbG9zcyBvZiBjZXJ0aWZpY2F0 ZSBpc3N1ZXMuICBCdXQgdGhlIHVzZSBjYXNlIG9mIGFsbG93aW5nIGV4YW1wbGUuY29tIHRvIHNl bmQgYSByZWNvcmQgZm9yIGFuYWx5dGljcy5leGFtcGxlLmNvbSBpcyBoaWdobHkgdmFsdWFibGUu Cgo6CldlIG5lZWQgdG8gc2VwYXJhdGUgdGhlIGlkZWEgb2YgYXV0aG9yaXRhdGl2ZW5lc3MuICBZ b3UgbWlnaHQgZ2V0IGEgY29tcGxldGVseSBkaWZmZXJlbnQgYW5zd2VyIHRoaXMgd2F5IHZzIHBv cnQgNTMuICBJZiB3ZSBjYW4gbWFrZSBpdCB0aWVkIHRvIHRoYXQgd2ViIHNlc3Npb24sIHRoZW4g d2hvIGNhcmVzIGlmIGl0J3MgZGlmZmVyZW50PyAgVGhleSdyZSBhbHJlYWR5IGRvaW5nIGdlb2xv Y2F0aW9uIHN0ZWVyaW5nLCBzbyB0aGlzIGlzIGp1c3QgZG9pbmcgdGhhdCBvbiBzdGVyb2lkcy4g IFlvdSBtYXkgd2VsbCBnZXQgc29tZXRoaW5nIGJhY2sgd2l0aCBhIEROU1NFQyBzaWduYXR1cmUu CgpQYXVsOgpUbyBhbXBsaWZ5IHdoYXQgeW91IHNhaWQsIHdlIG1heSBiZSByYXRob2xpbmcgZWFy bHkgb24gdGhlIEROU1NFQyBhbmQgYXV0aG9yaXRhdGl2ZW5lc3MuICBCYWQgaWRlYSBmYWlyeTog d2UgY291bGQgYWRkIGFuIEVETlMwIG9wdGlvbiBpbmRpY2F0aW5nIHdoaWNoIGFzcGVjdHMgb2Yg dGhpcyBhbnN3ZXIgYXJlIHVuaXZlcnNhbCwgYW5kIGNhbiBiZSBzcHJheXBhaW50ZWQgb24gYSB3 YWxsLgoKREtHOgpJJ3ZlIGdvdCBzcHJheXBhaW50IGluIG15IGJhZyByaWdodCBub3cuCgpTaGFu ZToKRG8gd2UgaGF2ZSBpbnR1aXRpb24gZm9yIGhvdyB0aGlzIGNoYW5nZSB0byBhcmNoaXRlY3R1 cmUgaXMgZ29pbmcgdG8gYWZmZWN0IHRoZSBuZXR3b3JrIGF0IGxhcmdlPyAgUmVzb2x2ZXJzIGNh Y2hlLCB0aGV5J3JlIGVmZmljaWVudC4gIFdpbGwgdGhpcyBuZXcgYXJjaGl0ZWN0dXJlIGJlIG1v cmUgUDJQIGFuZCBzY2FsZSBldmVuIGJldHRlcj8gIE9yIG5vdD8KCk1pa2U6CklmIHlvdSBoYXZl IEgyIHB1c2hpbmcgYSByZXNvdXJjZSwgeW91IGhhdmUgdWx0aW1hdGUgY2FjaGluZywgYmVjYXVz ZSB0aGUgc2VydmVyIHdpbGwgdXBkYXRlIGl0cyByZXNvdXJjZSBldmVyeSAxNSBtaW51dGVzLCBh bmQgcHVzaCB0aGF0IHJlc291cmNlIHRvIGFsbCBjbGllbnRzLgoKU2hhbmU6CkJ1dCB5b3UgY291 bGQgYmUgcXVlcnlpbmcgM3JkIHBhcnR5IGRhdGEgdG9vLgoKTWlrZToKWW91IGNvdWxkLgoKU3Vi b2RoOgpUaGUgY29tcGVsbGluZyB1c2UgY2FzZSBmb3IgdXMgaXMgdGFyZ2V0aW5nLiAgV2UgZG8g RE5TLWJhc2VkIHRhcmdldGluZyBvZiB1c2VycyB3aGVuIHRoZXkgY29tZSBpbiBmcm9tIGEgc3Bl Y2lmaWMgSVAgc3VibmV0LCB3ZSBwdXNoIHJlY29yZHMgZm9yIHRoYXQgdXNlciB0byB2aXNpdCBh IFBPUCBuZWFyIHRoYXQgdXNlciwgaW5jbHVkaW5nIElTUCBwcmVmZXJlbmNlcyBmb3IgcGVlcmlu ZyBvciB0cmFuc2l0LCB3aGVyZSB0aGUgbGlua3MgaGF2ZSBjYXBhY2l0eSwgZXRjLiAgVGhpcyB3 b3VsZCBhbGxvdyB1cyB0byBtYWtlIG1vcmUgZmluZS1ncmFpbmVkIGRlY2lzaW9ucy4gIFRoZSBp bml0aWFsIEROUyBtaWdodCBiZSBzbG93ZXIgdnMuIHRoZSBJU1BzIGxvY2FsIGNhY2hpbmcgcmVz b2x2ZXIsIGJ1dCB0aGUgc3Vic2VxdWVudCByZXF1ZXN0cyBtaWdodCBiZWNvbWUgd2F5IGZhc3Rl ciBiZWNhdXNlIHRoZXkgd2VudCB0byBhIFBPUCB0aGF0IHdhcyBjbG9zZXIgb3IgbW9yZSBvcHRp bWFsLgoKREtHOwpJIGRvbid0IHRoaW5rIGFueW9uZSBpcyBwcm9wb3NpbmcgZG9pbmcgYXdheSB3 aXRoIHRoZSByZXNvbHZlcnMuICBObyBvbmUgaXMgaW1hZ2luaW5nIHJhZGljYWxseSByZXNoYXBp bmcgdGhlIGVudGlyZSBpbnRlcm5ldC4KClNoYW5lOgpJIHRoaW5rIGlmIHlvdSdyZSBlbnZpc2lv bmluZyBhbnkga2luZCBvZiBzdWNjZXNzIHRoZW4geW91IGRvIG5lZWQgdG8gdGhpbmsgYWJvdXQg aGF2aW5nIG1vcmUgYW5kIG1vcmUgdHJhZmZpYyBzaGlmdCB0byB0aGlzIG1vZGVsLiAgSWYgeW91 IHJlYWxseSBleHBlY3QgdGhpcyB0byBiZXVzZWZ1bCBpbiB0aGUgZ2VuZXJsYSBjYXNlIHRoZW4g eW91IG5lZWQgb3QgaW1hZ2luZSBpdCB0YWtpbmcgb3ZlciBhIHNpZ25pZmljYW50IGFtb3VudCBv ZiB0cmFmZmljOgoKVGFsZToKVGhpcyBoYXMgbWFqb3IgaW1wbGljYXRpb25zIGZvciB0aGUgYmln IHByb3ZpZGVycyBtYWtpbmcgdGhlaXIgbG9hZCBhbmQgZGVtYW5kIGVzdGltYXRlcywgY2FjaGUg aW50ZXJhY3Rpb25zLCBldGMuICBJdCBoYXMgc2lnbmlmaWNhbnQgYXJjaGl0ZWN0dXJhbCBpbXBs aWNhdGlvbnMgdGhhdCB3aWxsIHRlbmQgdG8gZmF2b3Igc29tZSBidXNpbmVzcyBtb2RlbHMgb3Zl ciBvdGhlcnMuCgpFcmlrOgpUd28gY2xhc3NlcyBvZiBwcm9ibGVtcywgcmVzb2x2ZXIgaXMgYSBy ZWQgaGVycmluZy4gIERvIHlvdSBrbm93IGdvIHRocm91Z2ggdGhlIGF1dGhvcml0YXRpdmUgcmVz b2x2ZXJzPyAgT3IgZG8geW91IHRyZWF0IHRoaXMgYXMgdGhlIGtpbGxlciBhcHAgZm9yIEROU1NF QywgaS5lLiB2ZXJpZmllZCByZWNvcmRzIGFyZSBnb29kIG5vIG1hdHRlciBob3cgeW91IGdldCB0 aGVtPyAgVGhhdCdzIG9uZSBjbGFzcyBvZiB0b3BpY3MuICBUaGUgb3RoZXIgY2xhc3MgaXM6IGhv dyBkbyB3ZSBoYW5kbGUgdHJhZmZpYyByb3V0aW5nIGlmIGEgY2xpZW50IGhhcyBhIG5hbWUgYW5k IHdhbnRzIHRvIGdldCBhIHJlc291cmNlPyAgSXQgc2VlbXMgbGlrZSB0aGVyZSdzIGEgbmV3IHR5 cGUgb2YgY2FtZWwgZm9ybWluZyBoZXJlLCBiZXR3ZWVuIEVDUywgQWx0LVN2YywgRE9ILCBETlM2 NC4gIEhhcHB5IGV5ZWJhbGwgdmFyaWFudHMsIGhhbmRsaW5nIG1hbnkgUlJzLCBjaG9vc2luZyBi ZXR3ZWVuIFFVSUMgYW5kIEgyLiAgTG90cyBvZiB3YXlzIHRvIGdvIGZyb20gYSBuYW1lIHRvIGEg Y29ubmVjdGlvbiAoY29ubmVjdGlvbiBjb2FsZXNjaW5nISkuICBDb21wbGV4aXR5IHRoZXJlIGlz IGdyb3dpbmcsIGFuIGVtZXJnZW50IHByb3BlcnR5IHdpdGggbm8gc2luZ2xlIHdvcmtpbmcgZ3Jv dXAuCgpCYXJyeSBHcmVlbjoKVGhlIGVuZCBnb2FsOiBXZSBidWlsdCB0aGUgRE5TIGluIGFuIGVy YSB3aGVuIG5ldHdvcmtzIHdlcmUgbm90IHZlcnkgc3RhYmxlLiAgSWYgYSBodXJyaWNhbmUgY29t ZXMgdGhyb3VnaCBhbmQgdGFrZXMgYW4gSVNQIG9mZmxpbmUsIHRoaW5ncyBzaG91bGQgd29yay4g IElmIG15IEROUyBpcyBhbGwgaGFuZGxlZCBpbi1hcHAgb3ZlciBIVFRQIGJ5IGV2ZXJ5IGFwcCwg dGhlbiBJIGhhdmUgYW4gZXh0ZXJuYWwgZGVwZW5kZW5jeSBmb3IgcmVzaWxpZW5jZSBvZiBteSBu ZXR3b3JrLiAgTGV0cyBkbyBhbGwgRE5TIGxvb2t1cCBmb3IgV2hhdHNhcHAgaW4gV2hhdHNhcHAs IGJ1dCBpbiBhIGh1cnJpY2FuZSwgd2hhdCdzIG15IHJlY292ZXJ5IG1vZGVsPwoKV2hhdCdzIHRo ZSBlbmQgZ29hbD8gIFdoZXJlIGFyZSB3ZSBoZWFkaW5nIHdpdGggdGhpcz8KCkRLRzoKSSBlbnZp c2lvbiB0aGlzIGFzIGFuIGFkZGl0aXZlIHNldCBvZiBwbGFjZXMgd2hlcmUgSSdtIHdpbGxpbmcg dG8gYWNjZXB0IEROUyByZWNvcmRzLiAgSXQgc291bmRzIHRvIG1lIGxpa2UgeW91J3JlIHNheWlu ZyB0aGF0IGlmIHdlIG1ha2UgdGhpcyB3b3JrLCB0aGVuIEknbSBnb2luZyB0byBsb3NlIG15IHRy YWRpdGlvbmFsIEROUyBjaGFubmVsLiAgSSBkb24ndCBrbm93IHdoeSB3ZSB3b3VsZCBsb3NlIGl0 LgoKU2FyYToKT24gRE5TU0VDOiBvbmUgb2YgdGhlIHVzZSBjYXNlcyBpcyBjb21wbGV0ZSB1bnNp Z25lZCBkYXRhLCBzbyBJJ2QgbGlrZSB0byBjbGVhciB0aGF0IHVwLgoKUGF0cmljazoKTm8gbGlt aXRzIGluIHRoaXMgY29udmVyc2F0aW9uLCBidXQgaW4gYSBXRyB3ZSBjb3VsZCBtYWtlIEROU1NF QyBtYW5kYXRvcnksIHRoYXQgd291bGQgYmUgaW4gc2NvcGUuCgpTYXJhOgpJIHRoaW5rIFNoYW5l J3MgcmlnaHQ6IGlmIHRoaXMgd29ya3MsIHdoeSB3b3VsZCB5b3UgZ28gdG8gdGhlIG90aGVyIGNo YW5uZWwgdW5sZXNzIHlvdSdyZSBpbiBhIGRpc2FzdGVyIG1vZGU/ICBJZiBldmVyeSBhcHAgZG9l cyB0aGlzLCB3aGF0J3MgbGVmdCB0byB0aGUgc3lzdGVtIHJlc29sdmVyPwoKSm9objoKV2hhdCBk byB5b3UgbWVhbiBieSBjb250ZXh0PyAgQXJlIHdlIHRhbGtpbmcgYWJvdXQgYSB3ZWJwYWdlLCBv ciB0aGUgY29udGV4dCBvZiB0aGUgd2hvbGUgb3BlcmF0aW5nIHN5c3RlbT8KClBhdWw6Ckl0IHNv dW5kcyBsaWtlIHRoZSBtYWluIHVzZSBjYXNlIGlzICJmYXN0ZXIiLiAgVGhpcyBpcyBhIHNlcnZl ciBwdXNoaW5nIHJlY29yZHMgdG8gbWFrZSB0aGluZ3MgZmFzdGVyLgoKUGF0cmljazoKRmFzdGVy IGFuZCBtb3JlIHByaXZhdGUuCgpQYXVsOgpMZXQncyBzcGxpdCB0aG9zZSBvdXQuICAiZmFzdGVy IiBjb3VsZCBiZSBoYW5kbGVkIGJ5IGRvdWJsZS1jaGVja2luZyB0aHJvdWdoIHRoZSByZWd1bGFy IEROUy4gIFRoYXQgZG9lc24ndCB3b3JrIGZvciAicHJpdmF0ZSIuICBUaGVyZSBtaWdodCBiZSBj bGFzc2VzIG9mIGRhdGEgdGhhdCBhcmVuJ3QgcHJpdmFjeS1zZW5zaXRpdmUgdGhvdWdoLiAgTGV0 J3Mgbm90IHRlbGwgdGhlIHVzZXJzIHdoYXQgdGhlaXIgdXNlIGNhc2VzIGFyZS4KCk15IGZpcnN0 IGd1ZXNzIGlzIHRoYXQgcGVvcGxlIHdhbnQgdG8gcHVzaCB0aGlzIGZvciAiZmFzdGVyIiwgYW5k IHByaXZhY3kgaXMgYSBzZWNvbmRhcnkgY29uc2lkZXJhdGlvbiwgYnV0IHRoZXJlIGFyZSBhbHNv IHBlb3BsZSB3aG8gd2FudCB0aGlzIGZvciBwcml2YWN5IGZpcnN0LgoKUGF0cmljazoKSSB0aGlu ayB0aGUgcXVlc3Rpb24gb2YgY29udGV4dCBvciBzY29wZSBpcyBhIGRlc2lnbiBxdWVzdGlvbi4g IE9uZSBwb3RlbnRpYWwgY29udGV4dCBpcyAiaHR0cHMgd2l0aGluIGEgd2ViIGJyb3dzZXIgdGFi IiwgaS5lLiBzZXBhcmF0ZWQgZnJvbSBvdGhlciBwYXJ0cyBvZiB0aGUgYnJvd3Nlci4gIEFub3Ro ZXIgaXMgIndob2xlIGJyb3dzZXIiIG9yICJ3aG9sZSBPUyIsIGFuZCB0aG9zZSBhcmUgdmVyeSBk aWZmZXJlbnQuCgpBcyBmb3IgdG90YWxseSByZW1vdmluZyByZXNvbHZlci1iYXNlZCBETlMsIHNl cnZlcnMgZG9uJ3Qga25vdyBhbGwgdGhlIG5hbWVzIHlvdSB3aWxsIG5lZWQuICBUaGV5IGtub3cg dGhlIG1vc3Qgb2J2aW91cyBvbmVzLiAgVGhlcmUgd2lsbCBhbHdheXMgYmUgbWlzc2VzLCBzbyB3 ZSdsbCBhbHdheXMgbmVlZCByZXNvbHZlcnMuCgo/Pz86CkN1cnJlbnRseSwgc3R1YnMgYXJlIGR1 bWIgd2l0aCByZXNwZWN0IHRvIEROU1NFQy4gIFdpbGwgd2UgZ2l2ZSBhcHBsaWNhdGlvbnMgdGhl IGFiaWxpdHkgdG8gdmFsaWRhdGUgRE5TU0VDPyAgQXMgYSBjbGllbnQgSSB3b3VsZCBsaWtlIHRv IGRvIGl0IG15c2VsZi4gIElzIHRoYXQgcG9zc2libGU/CgpQYXVsOgpZZXMuCgpSYXk6CmlmIHdl IGRvIGhhdmUgdGhlIHNpdHVhdGlvbiBvZiBzZXJ2ZXJzIHB1c2hpbmcgcmVjb3Jkcywgd2UnbGwg bG9zZSBSUFouICBJdCdzIGNvbW1vbiBmb3IgcGVvcGxlIHRvIHVzZSBETlMgc2VydmVycyB0aGF0 IGZpbHRlciBETlMgZm9yIGJvdG5ldHMuCgpTdWJvZGg6CkluIGFkZGl0aW9uIHRvIHByaXZhY3kg YW5kICJmYXN0Iiwgd2UgYWxzbyBuZWVkIHRvIHRhbGsgYWJvdXQgZGl2ZXJzaXR5LiAgQXMgd2Ug Z28gaW50byB0aGUgRE9IIHNwYWNlLCB3ZSBvbmx5IGhhdmUgb25lIGJyb3dzZXIgYW5kIG9uZSBy ZXNvbHZlciByaWdodCBub3cuICBOb3QgY2xlYXIgaG93IHdlIHdvdWxkIGdldCBtb3JlIGFuZCBi b290c3RyYXAgdGhlbS4gIFRoaXMgaXMgb25lIHBhdGggdG8gZ2V0IGJvb3RzdHJhcHBpbmcgYW5k IGdldCBtb3JlIEROUyBlbnRyaWVzLgoKRXJpazoKT24gdGhlIFJQWiBxdWVzdGlvbiwgdGhhdCdz IGNlcnRhaW5seSByZWxldmFudCBoZXJlLCBidXQgaXQncyBhbHNvIHJlbGV2YW50IHRvIERPSC4g IEZvciB0aGUgbm9ybWFsIHVzZSBjYXNlLCBpcyB0aGVyZSBhIHN0YW5kYXJkaXplZCB3YXkgdG8g Y29uZmlndXJlIGEgY2xpZW50IHRvIHVzZSBhIHRydXN0ZWQgcmVzcG9uc2UgcG9saWN5IHNlcnZl cj8gIE90aGVyd2lzZSwgZW50ZXJwcmlzZSBvciBob21lIGZpbHRlcmluZyB3aWxsIGxvc2UgdGhl IHVzZSBvZiBETlMgaGFzIGEgcG9saWN5IHRvb2wuICBXZSBuZWVkIGhvb2tzIHNvIHRoZSBwZW9w bGUgd2hvIGNvbnRyb2wgdGhvc2UgZW5kcG9pbnRzIGRvbid0IGxvc2UgdGhhdC4KClJheToKSSB3 b3VsZG4ndCBsaWtlIHRvIGhhdmUgdGhlIFJQWiBjaG9pY2UgZGVsZWdhdGVkIHRvIHRoZSBjbGll bnQuCgpQYXRyaWNrOgpXZSBoYXZlIHN0YWtlaG9sZGVycyByZXByZXNlbnRlZCBmb3IgQ0ROcywg YnJvd3NlcnMsIGFuZCB3ZWJzaXRlIG9wZXJhdG9ycywgYnV0IG5vdCBJU1BzIG9yIG5ldHdvcmsg b3BlcmF0b3JzLgoKTW5vdDoKV2hlbiBsZXNzIGluZm9ybWF0aW9uIGlzIGV4cG9zZWQsIElTUHMg YWx3YXlzIHNlZW0gdG8gc2F5IHRoZXkgZG9uJ3QgY2FyZS4gIEl0J3MgZW50ZXJwcmlzZXMsIHNj aG9vbHMsIGhvbWVzLCBhbmQgcHJpc29ucyB3aG8gYXJlIGdvaW5nIHRvIGNhcmUgbW9yZSB0aGFu IElTUHMuCgpQYXRyaWNrOgpEbyB5b3UgdGhpbmsgcmVzb2x2ZXJsZXNzIEROUyBpcyBpbnRlcmVz dGluZyBpbiBhbiBpbmNyZW1lbnRhbCB3YXkgdG8gdGhlIHVzZSBvZiBvcGVuIHJlc29sdmVycywg b3IgaXMgaXQgYSBkaWZmZXJlbnQgcHJvYmxlbT8gIEkgdGhpbmsgaXQncyB0aGUgc2FtZSBwcm9i bGVtLgoKTU5PVDoKWWVzLCBpZiBJIGJsb2NrIHBvcnQgNTMgZm9yIG15IGtpZHMsIHRoZW4gRE9I IGlzIGFscmVhZHkgYSBwcm9ibGVtLgoKOgpOQVQ2NCBpcyBhbHNvIGEgcHJvYmxlbSwgaW4gYWRk aXRpb24gdG8gUlBaLiAgVGhpcyBpcyBhbGwgdHJ5aW5nIHRvIGdldCBwYXN0IHRoYXQsIGFuZCBp dCdzIGdvaW5nIHRvIGVuZCB1cCBicmVha2luZy4gIFdlJ3ZlIGZpeGVkIGEgbG90IG9mIHRoaW5n cyBieSBicmluZ2luZyB0aGUgZml4ZXMgY2xvc2UgYW5kIHlvdSd2ZSBnb3QgdG8gYmUgY2FyZWZ1 bCBoZXJlLgoKQmFycnk6CldpdGggb3BlcmF0b3IgaGF0IG9uLCBJIHRoaW5rIHlvdXIgcGVyc3Bl Y3RpdmUgaXMgVVMvRVUuICBUaGUgQVBBQyBvcGVyYXRvcnMgYXJlIG1hbmlwdWxhdGluZyBETlMg Zm9yIGZpbHRlcmluZyBhbmQgY2Vuc29yc2hpcCwgc28gaWYgeW91IHNheSB5b3UncmUgZ29pbmcg dG8gYnlwYXNzIHRoYXQgdGhlIG9wZXJhdG9ycyBhcmUgZ29pbmcgdG8gY29tcGxhaW4uICBBbm90 aGVyIGNvbnN0aXR1ZW50IHdlIG5lZWQgdG8gaW5jbHVkZSBpcyBteSBtb20sIHdobyBpcyBnb2lu ZyB0byB3YW50IHRvIGtub3cgd2h5IHNvbWV0aGluZyBkb2Vzbid0IHdvcmsgaW4gb25lIHBhcnRp Y3VsYXIgdGFiPyAgVGhpcyBpcyBjcmVhdGluZyBjb21wbGV4aXR5IHBlci1hcHAsIHBlci10YWIg dGhhdCB3aWxsIGJlIGhhcmQgdG8gc3VwcG9ydC4KClBhdHJpY2s6Ckl0J3MgYSB0cnVpc20gdGhh dCBldmVyeSBsZXZlbCBpbiBhbiBpbnRlcm5ldCBleGNoYW5nZSBjbGFpbXMgdGhhdCB0aGUgY3Vz dG9tZXIgY2FsbHMgdGhlbSBmaXJzdC4KClBhdWw6CldlIHN0YXJ0ZWQgd2l0aCAid2hlcmUgbWln aHQgd2UgYmUgZ2V0dGluZyB0aGlzIGRhdGEiPyAgTGV0J3MgbGltaXQgdGhpcyB0byBIVFRQLgoK REtHOgpJIHRoaW5rIHRoYXQgYW4gaW50ZXJlc3RpbmcgdGhvdWdodCBleHBlcmltZW50IHdvdWxk IGJlIHRvIGRlZmluZSB0aGUgbmFycm93ZXN0IHBvc3NpYmxlIHNjb3BlIHdoZXJlIHNvbWV0aGlu ZyBsaWtlIHRoaXMgbWlnaHQgYmUgaW50ZXJlc3RpbmcuICBJZiB0aGF0IG1lYW5zICJ3aXRoaW4g b25lIHRhYiIsIEhUVFBTLW9ubHksIEROU1NFQy1zaWduZWQsIGhvcGVmdWxseSBhdCBzb21lIHBv aW50IHdlIGNhbiBmaW5kIHNvbWV0aGluZyB0aGF0IGRvZXNuJ3QgbWFrZSB0b28gbWFueSBvYmpl Y3Rpb25zLCBhbmQgdGhlbiBtYXliZSB3ZSBjYW4gd2FsayBpdCBvdXQuCgpQYXRyaWNrOgpXaXRo IGRlbGVnYXRlZCBzaG9ydC1saXZlZCBjZXJ0cy4KClN1Ym9kaDoKQmV5b25kICJETlNTRUMgd2ls bCBzb2x2ZSBhbGwgb3VyIHByb2JsZW1zIiwgdGhlIG90aGVyIHRoaW5nIGlzIHRoZSBPUklHSU4g ZnJhbWUgZGlzY3Vzc2lvbnMuICBJZiB3ZSdyZSBzY29waW5nIHRoaXMgdG8gSFRUUC1vbmx5LCB0 aGVuIHdlIG1pZ2h0IHdhbnQgdG8gYXBwbHkgdGhlIHNhbWUgY29uc2lkZXJhdGlvbnMgYXMgT1JJ R0lOIGZyYW1lLCBwbHVzIG1heWJlIHNvbWV0aGluZyBmb3Igd2lsZGNhcmQgaGFuZGxlcnMuICBJ dCBpcyBzbGlnaHRseSBkaWZmZXJlbnQgaW4gdGVybXMgb2Ygd2hvIGNhbiBtb3VudCBhbiBhdHRh Y2suCgpQYXRyaWNrOgpleGFtcGxlLmNvbSBjb3VsZCBwdXNoIGEgRE5TU0VDLXNpZ25lZCByZWNv cmQgZm9yIGdtYWlsLmNvbS4gIE90aGVyd2lzZSBpdCB3b3VsZCByZWx5IG9uIFdlYlBLSS4gIEl0 IGNvdWxkIHB1Ymxpc2ggdGhlIElQIG9mIGl0c2VsZiwgd2hpY2ggZXhhbXBsZS5jb20gY291bGQg bm90IHByb2R1Y2UgYSB2YWxpZCBjZXJ0IGZvciwgYnV0IGl0IGNvdWxkIGZvcndhcmQgdGhlIHBh Y2tldHMgdG8gZ21haWwgYW5kIGFjdCBhcyBhIG5ldHdvcmstbGV2ZWwgTUlUTS4gIE1heWJlIHRo YXQncyB3aHkgd2Ugd2FudCBETlNTRUMuCgpTdWJvZGg6CkRvaW5nIHRoaXMgYXQgc2NhbGUgd291 bGQgYmUgaGFyZAoKUGF0cmljazoKQnV0IHlvdSBjYW4gdGFyZ2V0IHRoaXMuCgpFcmlrOgpUbyBE S0dzIHRob3VnaHQgZXhwZXJpbWVudDogaWYgeW91IHRoaW5rIG9mIGV2ZXJ5dGhpbmcgaW4gYSB0 YWIgYXMgc3RhdGVsZXNzIGl0IG1pZ2h0IHdvcmssIGJ1dCBvbmNlIHlvdSBoYXZlIHN0YXRlIGl0 IGdldHMgbWVzc2llci4gIFdoYXQgaWYgYSByZXNvdXJjZSBpbiB0aGUgdGFiIGFsdGVycyB0aGUg b3JpZ2luIHN0YXRlPyAgTm93IHlvdSBoYXZlIGEgc2l0dWF0aW9uIHdoZXJlIGFuIGFkIHBpeGVs IGxlYWtzIGluZm9ybWF0aW9uIHRvIG90aGVyIHRhYnMuCgpUaGF0IG1pZ2h0IGJlIHNvbWV0aGlu ZyB3aGVyZSB3ZSBuZWVkIHRvIGxvb2sgZXZlbiBuYXJyb3dlciwgZS5nLiBvbmx5IHRvIHByaXZh dGUgYnJvd3NpbmcgbW9kZS4gIFRoYXQgbWlnaHQgYmUgYSBwbGFjZSB0byBsb29rIGF0IGZpcnN0 LiAgVGhpcyBhbHNvIGdvZXMgdG8gdGhlIG9yaWdpbmFsIG1vdGl2YXRpb24gZm9yIHRoZSBPUklH SU4gZnJhbWU6IHNvbWUgd2FudGVkIHRvIGV4cGFuZCB0aGUgb3JpZ2luLCBhbmQgc29tZSB3YW50 ZWQgdG8gc2hyaW5rIGl0IGR1ZSB0byBjb3JuZXIgY2FzZXMgd2l0aCBjb25uZWN0aW9uIGNvYWxl c2NpbmcuICBGb3IgZXhhbXBsZSwgc29tZSBicm93c2VycyB3aWxsIGNvYWxlc2NlIGlmIHRoZSBS UnNldHMgb3ZlcmxhcCwgZXZlbiBpZiB0aGUgYWN0dWFsIElQIGluIHVzZSBpc24ndCBhdmFpbGFi bGUgaW4gYm90aC4gIE9yIGNvYWxlc2NpbmcgaW4gSVBWNiB3aGVuIGl0IG9ubHkgd29ya3MgaW4g SVB2NC4gIFRoaXMgaXMgYSBncmVhdCB1c2UgY2FzZSBmb3IgT1JJR0lOIGZyYW1lLgoKUGF0cmlj azoKVG8gdGhlIGV4dGVudCB0aGF0IE9SSUdJTgoKQmVuOgpXZSBuZWVkIHRvIGNvbnNpZGVyIGEg c3VwZXJjb29raWUgYXR0YWNrLCB3aGVyZSBhIHNlcnZlciBwdXNoZXMgYSAoRE5TU0VDLXNpZ25l ZCkgcmVjb3JkIHRoYXQncyB1bmlxdWUgZm9yIGVhY2ggY2xpZW50LCBhbmQgdGhlbiB1c2VzIGEg dHJhY2tpbmcgcGl4ZWwgZm9yIHRoZSBkb21haW4gdG8gY3JlYXRlIGEgc3VwZXJjb29raWUgdGhh dCBmb2xsb3dzIHRoZW0gYXJvdW5kIHRoZSB3ZWIuICBCcm93c2VyIHNvY2tldCBwb29scyBtaWdo dCBub3QgYmUgZGVzaWduZWQgdG8gbGltaXQgdGhlIHVzZSBvZiBhIEROUyByZWNvcmQgdG8gYSBz cGVjaWZpYyBzY29wZSwgc28gZGVmZW5kaW5nIGFnYWluc3QgdGhpcyB3b3VsZCByZXF1aXJlIGFk ZGluZyBhIG5ldyBmZWF0dXJlIHRvIHRoZSBzb2NrZXQgcG9vbHMgdG8gcHJldmVudCByZXF1ZXN0 IGNvYWxlc2NpbmcgZnJvbSBkaWZmZXJlbnQgY29va2llIHNjb3BlcyBvbiB0aGVzZSBzb2NrZXRz LgoKREtHOgpXb3VsZG4ndCBBbHQtU3ZjIGFscmVhZHkgaGF2ZSB0aGlzIHByb2JsZW0/CgpNTk9U OgpGaW5nZXJwcmludGluZyBpc3N1ZSBpcyB0b3VnaC4gIFNlZ3JlZ2F0aW5nIHNvY2tldHMgaXMg Y29udHJvdmVyc2lhbC4gIEl0J3Mgd29ydGggdGFsa2luZyBhYm91dC4gIEkgYWxzbyBrbm93IHRo YXQgc29tZSBtZW1iZXJzIG9mIENocm9tZSBTZWN1cml0eSBoYXZlIGZhaXJseSBkZWVwbHkgaGVs ZCBiZWxpZWZzIGFib3V0IHRoZSB3aXNkb20gb2YgdGhpcyBhcHByb2FjaC4gIFdlIHNob3VsZCBt YWtlIHN1cmUgdG8gZ2V0IHRoZWlyIGlucHV0LgoKREtHOgpJIHdhbnRlZCB0byBvYnNlcnZlIGEg ZGlmZmVyZW50IGJldHdlZW4gIkROU1NFQy1zaWduZWQgcmVjb3JkcyBmb3IgdGhlIC82NCIgdnMu IEFsdC1TdmMuICBJZiBnZXQgdGhlIHNpZ25lZCByZWNvcmRzIEkgY2FuIHJlcGxheSB0aGF0IHRv IGFueWJvZHkgZWxzZSwgd2hpY2ggY291bGQgZ2VuZXJhdGUgY29uZnVzaW9uIGFuZCByZW1vdmUg dGhlIGlkZW50aWZpZXIuICBJZiB3ZSdyZSBhc2tpbmcgZm9yIEROU1NFQy1zaWduZWQgcmVjb3Jk cy4gIFRoYXQgZ2l2ZXMgdXMgdGhlIG9wcG9ydHVuaXR5IHRvIHVzZSBzb21lIGtpbmQgb2YgdHJh bnNwYXJlbmN5IG1vZGVsIHRvIHRyeSB0byBkZXRlY3QgYmFkIGJlaGF2aW9yLgoKUGF0cmljazoK SSB3b3VsZCBsaWtlIHRvIGdldCBhIG1haWxpbmcgbGlzdCB0byBmb2N1cyBvbiBES0cncyBjb25z aWRlcmF0aW9uIG9mIHRoZSBtaW5pbXVtIHVzZWZ1bCBjYXNlLiAgSWYgd2UgY2FuIGZpbmQgYSBt aW5pbWFsIGNhc2UgdGhhdCdzIHdvcnRoIGFkdmFuY2luZyB0aGVuIG1heWJlIHdlIGNhbiBoYXZl IGEgQm9GLgoKSm9objoKV2h5IG5vdCBET0g/CgpQYXRyaWNrOgpUaGlzIHdvcmsgaXMgc3BlY2lm aWNhbGx5IG91dCBvZiBjaGFydGVyIGZvciBET0guCgpQYXVsOgpXZSdyZSBob3BpbmcgdG8gc2h1 dCBkb3duIHRoZSBET0ggd29ya2luZyBncm91cC4gIEkgdGhpbmsgYSBuZXcgbWFpbGluZyBsaXN0 IGlzIGFwcHJvcHJpYXRlLgoKUGF0cmljazoKSSBhbHNvIHdvdWxkIGxpa2UgYW4gQUQgdG8gYmUg YXdhcmUgb2YgdGhpcyB3b3JrLgo= --000000000000b82213057211c474 Content-Type: application/octet-stream; name="resolverless.md" Content-Disposition: attachment; filename="resolverless.md" Content-Transfer-Encoding: base64 X-Attachment-Id: f_jjpuhr5e0 IyBSZXNvbHZlcmxlc3MgRE5TDQoNCjIwMTgtMDctMTYgMTY6MzAgRURUDQoNCiJUb3RhbGx5IiBp bmZvcm1hbA0KDQpBYm91dCA0MCBhdHRlbmRlZXMNCg0KMS4gV2hhdCBmb3JtcyBvZiB0cmFuc3Bv cnQgY291bGQgYmUgaW4gc2NvcGU/IEhUVFAvMiBwdXNoIGlzIG9uZSBzdWNoDQogICB2ZWN0b3Is IGJ1dCBJJ3ZlIGhlYXJkIG90aGVycy4gU3ByYXkgcGFpbnQgZm9yIGV4YW1wbGUuDQoNCjIuIFdo YXQgbmVlZHMgdG8gYmUgY29uc2lkZXJlZCB3aGVuIHVzaW5nIHN1Y2ggZGF0YT8gKHNpZ25hdHVy ZXM/DQogICBzY29wZT8gZXRjPykNCg0KMy4gV2hvIGFyZSB0aGUgc3Rha2Vob2xkZXJzIGZvciAx ICsgMj8NCg0KNC4gSXMgdGhlcmUgZW5vdWdoIGludGVyZXN0IHRvIGV4cGxvcmUgZnVydGhlcj8g TmV4dCBzdGVwcyBhcyBvdXRwdXQNCg0KDQpka2c6IFBvdGVudGlhbGx5IHVzZWZ1bCBpbiBhIGxv dCBvZiBzcGFjZXMuIFBvcnQgNTMgYmVpbmcgdGhlIG9ubHkgd2F5DQp0byBnZXQgRE5TIGlzIHJl YWxseSB3cm9uZyB0b2RheS4gV2hlcmUgdGhlIGRhdGEgZ2V0cyBvZmYgdGhlIG5ldHdvcmsNCmlz IG5vdCBhbiBpbmRpY2F0b3Igb2YgaW50ZWdyaXR5LiBXZSBzaG91bGQgYmUgdGhpbmtpbmcgYWJv dXQgd2hlbiB0aGUNCmRhdGEgbWlnaHQgYmUgdXNhYmxlLiBETlNTRUMgY2hhaW4gaXMgYSBzaW5n bGUgdXNlIGNhc2UuDQoNCkpvaG4gRGlja2Vuc29uOiBDb25jZXJuZWQgYWJvdXQgdGhlIHBvc3Np YmxlIHVzZSBvZiBETlMgaW50cm9kdWNlcyB0aGUNCnBvc3NpYmlsaXR5IG9mIGFsdGVybmF0ZSBy b290cy4NCg0KUGF1bCBIb2ZmbWFuOiBTdWJqZWN0IGxpbmUgc2FpZCAicmVzb2x2ZXJsZXNzIiwg YW5kIGluIERvSCB0aGVyZSBpcyBhDQpyZXNvbHZlci4gIFR3byB1c2UgY2FzZXM6IHRydWUgcmVz b2x2ZXJsZXNzLCBidXQgaW4gRG9IIHRoZXJlIGlzIHNvcnQNCm9mIGEgcmVzb2x2ZXIuDQoNCmRr ZzogR2V0dGluZyBETlMgZnJvbSBwbGFjZXMgd2UgaGF2ZSBub3QgZ290dGVuIEROUyBmcm9tIGlu IHRoZSBwYXN0Lg0KVGhpbmtpbmcgYWJvdXQgdGhlICJzZXJ2ZXIgcHVzaCIgc2NlbmFyaW8uDQoN CkpvaG4gRGlja2Vuc29uOiAiV2hlcmUgdGhlIEROUyBjb21lcyBmcm9tPyIgbWVhbnMgdGhlIHJl c29sdmVyIG9yIHRoZQ0KYWN0dWFsIEROUyByZWNvcmRzPyBETlMgZnJvbSBhIHdlYiBzZXJ2ZXIg YW5kIG5vdCBhIEROUyBzZXJ2ZXI/DQoNCmRrZzogQ2hhbm5lbCB0aGUgYXBwbGljYXRpb24gY29t ZXMgZnJvbSBtYXkgbm90IGluZGljYXRlIGhvdyByZWxpYWJsZQ0KaXQgaXMuDQoNClRhbGU6IERv bid0IG5lY2Vzc2FyaWx5IG1lYW4gcmVzb2x2ZXIgaW4gdGhlIHBpcGVsaW5lLiBTZXJ2ZXJzIChD RE4ncykNCmNhbiB0ZWxsIHlvdSBhYm91dCByZWNvcmRzIHRoZXkgaG9wZSB5b3Ugd2lsbCB3YW50 LiBCdXQgdGhlIGFuc3dlcg0Kc2hvdWxkIGJlIGNvbnNpc3RlbnQgd2l0aCB3aGF0IHlvdSB3b3Vs ZCBnZXQgaWYgeW91IGFza2VkIHRoZSBETlMuDQoNCk1pa2UgQmlzaG9wOiBXZSBhbHJlYWR5IGhh dmUgZGlmZmVyZW50IGFuc3dlcnMgYmFzZWQgb24gY2xpZW50IElQLiBJbg0KSFRUUCB5b3UgbWF5 IGdldCBhbiBhbnN3ZXIgdGhhdCBpcyBub3QgaW4gdGhlIEROUyBiZWNhdXNlIG5vIGNsaWVudA0K Y2FuIGFzayB0aGF0Lg0KDQpTYXJhIERpY2tlbnNvbjogSXMgdGhpcyBsaWtlIGEgInZpZXciIG9m IEROUz8NCg0KVGFsZTogIkNvbnNpc3RlbnQgd2l0aCIgZG9lcyBub3QgbWVhbiAiaWRlbnRpY2Fs IHRvIi4gQnV0IHdlIG5lZWQgdG8NCnRhbGsgYWJvdXQgd2hvIGlzIGF1dGhvcml0YXRpdmUuDQoN ClBhdHJpY2sgTWNNYW51czogSXMgdGhhdCBkZWNpc2lvbiBwYXJ0IG9mIHRoZSBzZWN1cml0eSBt b2RlbCBvZiB0aGUNCmNvbnRleHQ/IFRoZSBETlMgaXMgbm90IGFsd2F5cyBjdXJyZW50LiBUaGVy ZSBtYXkgYmUgb3RoZXIgY29uY2VybnMNCmJ1dCBpdCBtYXkgbm90IGJlIGFib3V0IGF1dGhlbnRp Y2F0aW5nIHlvdXIgcGVlci4gSXNzdWVzIGFyb3VuZCBsb3NzDQpvZiBjZXJ0aWZpY2F0ZXMuIEdl dHRpbmcgYmFjayB0byB0aGUgdXNlIGNhc2Ugb2YgZ29pbmcgdG8NCiJleGFtcGxlLmNvbSIgYW5k IG5vdCBoYXZlICJhbmFseXRpY3MuY29tIiBhbmQgbm90IGhhdmluZyBhbnl0aGluZw0KbGVhay4N Cg0KSmltIFJlaWQ6IFdlYiBicm93c2VyIG5hbWUgbWF5IGJlIGNvbXBsZXRlbHkgZGlmZmVyZW50 IHRoYW4gRE5TIG5hbWUuDQpTaG91bGRuJ3QgYmUgdG8gcHVyZSBhYm91dCB3ZWIgdnMuIEROUy4N Cg0KUGF1bCBIb2ZmbWFuOiBXZSBtYXkgaGF2ZSBzdGFydGVkIHRvIHJhdGhvbGUgZWFybHkuIFNl cnZlciBrbm93cyB0aGUNCmNvbnRleHQgb2Ygd2hhdCBpcyBhc2tlZC4gV2UgY2FuIGFkZCBhbiBF RE5TMCBvcHRpb24gZm9yIGNvbnRleHQNCnNwZWNpZmljIGluZm9ybWF0aW9uLCBzdWNoIGFzICJJ IHdvdWxkIGdpdmUgdGhpcyBhbnN3ZXIgYW55d2hlcmUiDQp2ZXJzdXMgInRoaXMgaXMgZm9yIHlv dSIuIEJ1dCBJIGRvbid0IHRoaW5rIHdlIG5lZWQgdG8gZ28gdGhlcmUuDQoNClNoYW5lIEtlcnI6 IERvIHdlIGtub3cgaG93IHRoaXMgY2hhbmdlcyB0aGUgYXJjaGl0ZWN0dXJlIGFuZCB0aGUNCmlt cGFjdD8NCg0KTWlrZSBCaXNob3A6IENhY2hpbmcgd2lsbCBiZSB1bHRpbWF0ZS4NCg0KU3Vib2Ro IEl5ZW5nYXI6IFB1c2hpbmcgaXMgbmljZSwgYW5kIGFsc28gdGFyZ2V0aW5nLiBDYW4gYmUgbW9y ZSBvcHRpbWFsLg0KDQpka2c6IE5vYm9keSBpcyB0YWxraW5nIGFib3V0IGRvaW5nIGF3YXkgd2l0 aCByZXNvbHZlcnMuDQoNClNoYW5lIEtlcnI6IEkgYW0hIElmIGl0IGlzIHN1Y2Nlc3NmdWwgdGhl biBpdCBtYXkgcmVwbGFjZSBtb3N0IG9yIGFsbA0Kb2YgcmVzb2x2ZXIgdHJhZmZpYy4NCg0KVGFs ZTogSXQgaGFzIHRoZSBwb3RlbnRpYWwgdG8gaGF2ZSBzaWduaWZpY2FudCBpbXBhY3Qgb24gdHJh ZmZpYywgYW5kDQpvdGhlciBhcmNoaXRlY3R1cmFsIGltcGxpY2F0aW9ucy4gVGhpcyB3aWxsIGZh dm9yIHNvbWUgbW9kZWxzIG92ZXINCm90aGVycy4NCg0KRXJpayBOeWdyZW46IFR3byBjbGFzc2Vz IG9mIHByb2JsZW1zIGluZGVwZW5kZW50IG9mIGVhY2ggb3RoZXIuIE9uZQ0KZGltZW5zaW9uIGlz IHdhbGtpbmcgdGhlIGF1dGhvcml0eSB0cmVlLCB3aGV0aGVyIHRoZSBjbGllbnQgb3IgdGhlDQpy ZXNvbHZlci4gVGhlIG90aGVyIG9wdGlvbiBpcyB0aGVyZSBvdGhlciB3YXlzIHRvIGdldCB0aGUg aW5mb3JtYXRpb24NCi0ga2lsbGVyIGFwcCBmb3IgRE5TU0VDLiBHZXR0aW5nIEROU1NFQyBkYXRh IGluIGFub3RoZXIgY2hhbm5lbC4NCg0KRXJpayBOeWdyZW46IExhcmdlciBjYW4gb2Ygd29ybXMg Zm9yIGhvdyB3ZSByb3V0ZSB0cmFmZmljIGJhc2VkIG9uIGENCm5hbWUgdG8gYSBjbGllbnQuDQoN CkJhcnJ5IEdyZWVuZTogRE5TIHdhcyBidWlsdCBpbiBhbiBlcmEgd2l0aCB1bnN0YWJsZSBuZXR3 b3Jrcy4NClByb3ZpZGVycyB3aWxsIGdhaW4gYSBuZXcgZXh0ZXJuYWwgZGVwZW5kZW5jeSB0aGF0 IHRoZXkgY2Fubm90IGNvbnRyb2wNCnNpbmNlIGFwcGxpY2F0aW9ucyB3aWxsIGhhdmUgdGhlaXIg b3duIEROUyBvdmVyIERvSCBvciB3aGF0ZXZlci4NCg0KZGtnOiBJdCBzZWVtcyBsaWtlIHlvdSBh cmUgc2F5aW5nIHRoYXQgaWYgd2UgbWFrZSBpdCBzbyB0aGF0IGl0IHdvcmtzLA0KaXQgd2lsbCBt YWtlIEROUyBvYnNvbGV0ZS4gVGhhdCBpcyBub3Qgd2hhdCBJIGltYWdpbmUuDQoNClNhcmEgRGlj a2Vuc29uOiAuLi4NCg0KUGF0cmljayBNY01hbnVzOiBTY29wZSBvZiBkaXNjdXNzaW9uIGlzIHdo YXRldmVyIHdlIHdhbnQgaXQgdG8gYmUuDQoNClNhcmEgRGlja2Vuc29uOiBJZiB0aGVyZSBpcyBh IGdvb2QgY2hhbm5lbCwgaXQgd2lsbCBiZSBzd2l0Y2hlZCB0by4NCg0KSm9obiBEaWNrZW5zb246 IElzIGNvbnRleHQgYmVpbmcgb24gYSB3ZWIgcGFnZSBhbmQgdGFsa2luZyB0byB0aGF0DQpwYWdl LCBvciB0aGUgd2hvbGUgb3BlcmF0aW5nIHN5c3RlbT8NCg0KUGF1bCBIb2ZmbWFuOiBUaGUgbWFp biB1c2UgY2FzZSBpcyAiZmFzdGVyIi4gQSBzZXJ2ZXIgcHVzaGluZyByZWNvcmRzDQppcyBmYXN0 ZXIuDQoNCmRmazogTXkgbWFpbiBpZGVhIGlzIG5vdCB0aGF0Lg0KDQpQYXVsIEhvZmZtYW46IE9y IG1vcmUgcHJpdmF0ZS4gTGV0cyBzcGxpdCB0aGVtIG91dC4gV2UgY2FuIGRvdWJsZQ0KY2hlY2sg ImZhc3RlciIgYWdhaW5zdCByZWd1bGFyIEROUywgYnV0IHRoYXQgZG9lc24ndCB3b3JrIGZvciBw cml2YXRlLg0KVGhlcmUgbWlnaHQgYmUgbXVsdGlwbGUgbW9kZXMuIExldHMgbm90IHRlbGwgdGhl IHVzZXIgd2hhdCB0aGVpciB1c2UNCmNhc2VzIGFyZS4NCg0KUGF0cmljayBNY01hbnVzOiBJIGRv bid0IHRoaW5rICJ3aGF0IGlzIHRoZSBjb250ZXh0IiBpcyBhIHBvaW50IG9mDQpjb25mdXNpb24s IEkgdGhpbmsgd2UgbmVlZCB0byBkZWNpZGUgdGhhdC4gT25lIGNvbnRleHQgaXMgSFRUUFMNCndp dGhpbiBhIHdlYiBicm93c2VyLiBBbm90aGVyIG1pZ2h0IGJlIGFsbCBIVFRQUy4gDQoNClBhdHJp Y2sgTWNNYW51czogQXMgZm9yIHJlbW92aW5nIGFsbCBETlMuIFNlcnZlcnMgZG8gbm90IGtub3cg YWxsIHRoZQ0KbmFtZXMgdGhhdCBIVFRQIGNsaWVudHMgd2lsbCB3YW50Lg0KDQpSYW1pIEFsLURh bGt5OiBXaXRoIEROU1NFQywgc3R1YiByZXNvbHZlcnMgcmVseSBvbiByZXNvbHZlcnMuIElmIHdl DQpjYW5ub3QgZG8gdGhpcywgd2lsbCB3ZSBnaXZlIGFwcGxpY2F0aW9ucyB0aGUgYWJpbGl0eSB0 byB2YWxpZGF0ZT8NCg0KUGF1bCBIb2ZmbWFuOiBZZXMuIEFscmVhZHkgdGhlcmUuDQoNClJheSBC ZWxsaXM6IFdlIGhhdmUgdGhlIGNhc2Ugb2Ygc2VydmVycyBwdXNoaW5nIGRhdGEgdG8gRE5TLCBp biBSUFouDQpUaGF0IGhhcyBub3QgY2F1c2VkIGFyY2hpdGVjdHVyYWwgcHJvYmxlbXMuDQoNClN1 Ym9kaCBJeWVuZ2FyOiBXaXRoIGRpdmVyc2l0eSwgd2UgaGF2ZSBubyBjbGVhciBwYXRoIGZvciBt b3JlIERvSA0KcmVzb2x2ZXJzLiAgQm9vdHN0cmFwcGluZyBhIHJlc29sdmVyIGFuZCBkaXNjb3Zl cmluZyBtb3JlIG9uIHRoZSB3YXkNCm1pZ2h0IGJlIGdvb2QuDQoNCkVyaWsgTnlncmVuOiBNYXkg YmUgYSB3YXkgdG8gYXNrIHNlcnZlcnMgdG8gY29ubmVjdCB0byBhIHNlcnZlciB0aGF0IEkNCnRy dXN0IHRvIGdldCBuYW1lcy4NCg0KUGF0cmljayBNY01hbnVzOiBJIHdhbnQgdG8gbWFrZSBzdXJl IHdlIGhhdmUgdGhlIHJpZ2h0IHN0YWtlaG9sZGVycw0KbW92aW5nIGZvcndhcmQuDQoNCk1hcmsg Tm90dGluZ2hhbTogSVNQJ3MgZG9uJ3QgY2FyZSwgYnV0IGVudGVycHJpc2UgbmV0d29ya3MsIHNj aG9vbHMsDQpob21lcywgd2FudCB0byBlbmZvcmNlIHBvbGljeSBvbiBuZXR3b3Jrcy4NCg0KTWFy ayBBbmRyZXdzOiBHZXR0aW5nIHRoZSBBQUFBIHJlY29yZHMgdG8gZ28gdGhyb3VnaCB0aGUgTkFU NjQuIEEgbG90DQpvZiBzdHVmZiBoYXBwZW5zIGxvY2FsIHRvIHRoZSBjbGllbnQgdG9kYXkuIEl0 J3MgYWxsIGdvaW5nIHRvIGVuZCB1cA0KYnJlYWtpbmcuIFdlIGZpeGVkIGEgbG90IG9mIHRoaW5n IGJyaW5naW5nIHRoZSBmaXhlcyBjbG9zZS4NCg0KQmFycnkgR3JlZW5lOiBUaGUgSVNQIGNvbnRl eHQgaXMgRXVyb3BlYW4gb3IgQW1lcmljYW4uIFdoZW4geW91DQpzdWRkZW5seSBieXBhc3MgdGhl bSBhbmQgZG8gRE5TIGRpcmVjdGx5IHlvdSB3aWxsIGdldCBjb21wbGFpbnRzLg0KVHJvdWJsZXNo b290aW5nIEROUyBwcm9ibGVtcyB3aWxsIHJlcXVpcmUgZGlmZmVyZW50IHN1cHBvcnQuDQoNClBh dWwgSG9mZm1hbjogTGV0cyBkcm9wIHRoZSBpZGVhIG9mIGdldHRpbmcgZGF0YSBmcm9tIFRMUyBh bmQganVzdCB1c2UNCkRvSC4NCg0KZGtnOiBJbiB0ZXJtcyBvZiBtb3ZpbmcgZm9yd2FyZCwgd2Ug c2hvdWxkIGRlZmluZSBpbiB0aGUgbmFycm93ZXN0DQp0ZXJtcyBwb3NzaWJsZS4gSWYgdGhhdCBt ZWFucyBpbiBvbmUgdGFiIHdlIGdvIHRvIGFuIEhUVFBTIGVuZHBvaW50DQphbmQgZ2V0IEROU1NF QyBzaWduZWQgZGF0YSAoZm9yIGV4YW1wbGUpLCBhbmQgdGhlbiB3YWxrIHRoZSBzY29wZSBvdXQN CmlmIG5lY2Vzc2FyeS4NCg0KRXJpayBOeWdyZW46IFdobyB0cnVzdHMgd2hvbT8gVGhlIG9yaWdp biBkaXNjdXNzaW9uPyBSZXN0cmljdCBpdCBzb21laG93Lg0KDQpQYXRyaWNrIE1jTWFudXM6IGV4 YW1wbGUuY29tIGNvdWxkIHB1c2ggYSByZWNvcmQgZm9yIGdtYWlsLiBJZiBpdCBpcw0Kbm90IERO U1NFQyBzaWduZWQsIHRoZW4gaXQgY291bGQgcHVibGlzaCB0aGUgSVAgYWRkcmVzcyBmb3IgaXRz ZWxmIGFzDQpnbWFpbC5jb20uDQoNCj8/PzQ6IEV2ZW4gcmVzdHJpY3RpbmcgaW4gYSB0YWIgY2Fu IGJlY29tZSBtZXNzeS4gQSB0YWIgbWF5IHVzZQ0KaW5mb3JtYXRpb24gZnJvbSBvdGhlciB0YWJz LiBNYXliZSB3ZSBoYXZlIHRvIHNheSBvbmx5IGluIHByaXZhdGUNCmJyb3dzZXIgbW9kZSwgd2l0 aCBhIHRvdGFsbHkgc2VwYXJhdGUgY29udGV4dCBhbmQgc3Ryb25nZXIgZmlyZXdhbGxzLg0KDQpC ZW4gU2Nod2FydHo6IElmIEkgb3duIGEgZG9tYWluIEkgY2FuIGNyZWF0ZSBETlNTRUMtc2lnbmVk IHJlY29yZHMgYW5kDQpzcGFtIGFuIGVudGlyZSAvNjQsIHRoZW4gYW55IHBhZ2UgdGhhdCB5b3Ug bG9hZCB3aGlsZSB0aGF0IGlzIGluIGNhY2hlDQp0aGVuIGEgdHJhY2tpbmcgcGl4ZWwgd2lsbCBh bGxvdyB0cmFja2luZy4gQ29va2llIHNjb3BlIHBhcnRpdGlvbmluZw0KbmVlZHMgdG8gYXBwbHkg dG8gSVAgYWRkcmVzc2VzLg0KDQpNYXJrIE5vdHRpbmdoYW06IFRoaXMgaXMgcG9zc2libGUuIFNl Z3JlZ2F0aW5nIHNvY2tldHMgaXMgc3RpbGwgYQ0KY29udHJvdmVyc2lhbCB0b3BpYywgYnV0IGl0 IGlzIHdvcnRoIHRhbGtpbmcgYWJvdXQuDQoNCmRrZzogQSBkaWZmZXJlbmNlIGJldHdlZW4gRE5T U0VDIHNpZ25lZCByZWNvcmRzIGZvciBhIC82NCBhbmQgdGhlDQphbHRlcm5hdGl2ZSBpcyB0aGF0 IGlmIEkgZ2V0IGEgc2lnbmVkIHJlY29yZCB0aGVuIEkgY2FuIHJlcGxheSBpdCBmb3INCmFueW9u ZSBlbHNlLiBTaWduZWQgcmVjb3JkcyBnaXZlcyB1cyB0aGUgb3Bwb3J0dW5pdHkgZm9yIHNvbWUg c29ydCBvZg0KdHJhbnNwYXJlbmN5IG1vZGVsLg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KUGF0cmljayBN Y01hbnVzOiBXZSB3aWxsIGNyZWF0ZSBhIG1haWxpbmcgbGlzdCwgdG8gd29yayB3aXRoIGRrZydz DQpzdWdnZXN0aW9uIG9mIHdvcmtpbmcgdG93YXJkcyBhIG1pbmltYWwgbW9kZWwuIElmIHdlIGNh biBkbyB0aGF0IGluDQp0aGUgbmV4dCAzIHRvIDQgbW9udGhzIHRoZW4gd2UgY2FuIGNvbnNpZGVy IHdoYXQgdG8gZG8uDQo= --000000000000b82213057211c474--