From nobody Thu Jun 1 22:51:13 2017 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD75126DFF; Thu, 1 Jun 2017 22:51:11 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: ben@nostrum.com, dispatch@ietf.org, superuser@gmail.com, dispatch-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149638267101.31749.447965524096056925.idtracker@ietfa.amsl.com> Date: Thu, 01 Jun 2017 22:51:11 -0700 Archived-At: Subject: [dispatch] dispatch - Update to a Meeting Session Request for IETF 99 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Jun 2017 05:51:11 -0000 An update to a meeting session request has just been submitted by Murray Kucherawy, a Chair of the dispatch working group. --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Murray Kucherawy Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: core clue bfcpbis avtext avtcore ecrit insipid mmusic netvc payload rmcat rtcweb sipcore stir webpush xrblock jmap uta dmarc dcrup Second Priority: tram tsvwg tsvarea opsarea lmap People who must be present: Alexey Melnikov Mary Barnes Adam Roach Ben Campbell Cullen Jennings Murray Kucherawy Resources Requested: Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs. --------------------------------------------------------- From nobody Wed Jun 7 09:13:21 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96260129477; Wed, 7 Jun 2017 09:13:20 -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 4e0ph8KCiEE1; Wed, 7 Jun 2017 09:13:18 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5679212EC57; Wed, 7 Jun 2017 09:13:18 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id u12so11454196qth.0; Wed, 07 Jun 2017 09:13:18 -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=sBoGZIEyO72lz7F9kXEZRplk9nJjV6LFFOOv3YweXLw=; b=Vq5DGe1P7UW+V6uA6jTBAVCUMvjp3MV2ByMiZiQEAYRwc7VBZx7+Tfd65Tlq5U5owz 7FUQRc494SzgBW58LE0j+ZK+j8HciCinGS6phh0hz68ZCJTrkZ7FCgXZf5pMC7Q+YSU+ wdXVr6L8ot/l/ZYMP6tBQG5xgUF1FTddjuW5T2PHu6QyzCAH4Q+PhjjGYC/3hBPwChC3 iPwTiK3B/R3q8wz+CA/t2FJmIakQzSEDi/mwguzocb/Oq2QB3rY5D8lJkZjYucl4oEcu D5FHieYeWXTl0ApdGgvl6qQ8pSZoFLpInCqpb6aVXR+fcZyZEx0Ww5tscN5qQN4OYj/D 95oA== 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=sBoGZIEyO72lz7F9kXEZRplk9nJjV6LFFOOv3YweXLw=; b=hoE3nJfSRqGrZyFVqc2o8tIrFJMq7lxxrk8LfddXvO93OmzH1I8pp/x+DIyZhjUoeA aQ9EmZuyfTmywEKQkoJVDTkAohTrF4sC6VnVb7S2l+5A5V/ODsIAXAu7FJokuofvW4sT upXh1S9aUCQqSgs5uOGi0gdk1PgfQaZydKShtlkg5nI+/eKx2NXUFwWaOHqwhDrH0i0s pQ/U4TuuT+KYgO5sgxGl+jSQJMW/mpH01vQYKyZT2aktkzmFJKT7aGq4JPQ2jh45bzlP Yqj0Nrhg8le3uAeh9HmbfuzidDESpWIdDM0rjdE9HxqvW1vvBL/u206EWqi4auOpKd+l 3MaA== X-Gm-Message-State: AKS2vOyQqePRJ/FDYQqAFfqgZP3ZPFBHyNkfdOP+F85O69jq40Fnhqgr tP1pQ8uDwbnIzHsxV3aa5mlZ+UIezw== X-Received: by 10.200.38.115 with SMTP id v48mr19195775qtv.157.1496851997107; Wed, 07 Jun 2017 09:13:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.43.37 with HTTP; Wed, 7 Jun 2017 09:13:16 -0700 (PDT) In-Reply-To: References: From: Mary Barnes Date: Wed, 7 Jun 2017 11:13:16 -0500 Message-ID: To: DISPATCH Cc: Cullen Jennings , "Murray S. Kucherawy" , ART ADs Content-Type: multipart/alternative; boundary="001a1140358091aa2c0551610322" Archived-At: Subject: Re: [dispatch] Reminder: DISPATCH WG deadlines for IETF-99 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Jun 2017 16:13:21 -0000 --001a1140358091aa2c0551610322 Content-Type: text/plain; charset="UTF-8" Just a reminder that the cutoff for notifying chairs of topics is this coming Monday, June 12. And, please follow the standard naming convention for drafts - i.e., please include -dispatch- That makes it a whole lot easier to put together an agenda. Regards, Mary. On Tue, May 30, 2017 at 2:00 PM, Mary Barnes wrote: > As a reminder, the following deadlines for the DISPATCH WG for IETF-99 are > coming up: > > - June 2, 2017: Cutoff date for BoF submissions > - June 12, 2017: Cutoff date to notify the chairs/DISPATCH WG of plans > to submit a proposal > - June 18, 2017: Cutoff for charter proposals for topics > - June 25, 2017: Announcement of topics that have been dispatched for > IETF 99 > - July 3, 2017: Draft submission deadline > > Further details: https://tools.ietf.org/wg/dispatch/trac/wiki > > As a reminder, *please* use the typical WG naming convention when > submitting documents that you'd like to discuss during the DISPATCH WG > session: > draft-yoursurnamehere-dispatch-xyz > > It's very helpful to the chairs to be able to easily see relevant > documents using the tracker. And, if the draft moves to another WG later, > our handy dandy tools have an easy way to link the documents. > Regards, > Mary on behalf of DISPATCH WG chairs and ART ADs > --001a1140358091aa2c0551610322 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just a reminder that the cutoff for notifying chairs of to= pics is this coming Monday, June 12.=C2=A0 And, please follow the standard = naming convention for drafts - i.e., please include -dispatch- =C2=A0 That = makes it a whole lot easier to put together an agenda.=C2=A0

=
Regards,
Mary.


On Tue, May 30, 2017 at 2:00 PM,= Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
As a reminder, the followi= ng deadlines for the DISPATCH WG for IETF-99 are coming up:=C2=A0
    <= li>June 2, 2017: Cutoff date for BoF submissions
  • June 12, 2017: Cut= off date to notify the chairs/DISPATCH WG of plans to submit a proposal
  • June 18, 2017: Cutoff for charter proposals for topics=C2=A0
  • J= une 25, 2017: Announcement of topics that have been dispatched for IETF 99<= /li>
  • July 3, 2017: Draft submission deadline
Further details: <= a href=3D"https://tools.ietf.org/wg/dispatch/trac/wiki" target=3D"_blank">h= ttps://tools.ietf.org/wg/dispatch/trac/wiki

As a reminder, *please* use the typical WG naming convention when su= bmitting documents that you'd like to discuss during the DISPATCH WG se= ssion: =C2=A0
=C2=A0 =C2=A0draft-yoursurnamehere-dispatch-xy= z

It's very helpful to the chairs to be able t= o easily see relevant documents using the tracker.=C2=A0 And, if the draft = moves to another WG later, our handy dandy tools have an easy way to link t= he documents. =C2=A0
Regards,
Mary on behalf of DIS= PATCH WG chairs and ART ADs

--001a1140358091aa2c0551610322-- From nobody Sun Jun 11 18:00:57 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D5F129AD4; Sun, 11 Jun 2017 18:00:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-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 Ni0cNNVEErVN; Sun, 11 Jun 2017 18:00:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E431200C1; Sun, 11 Jun 2017 18:00:51 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DII04071; Mon, 12 Jun 2017 01:00:49 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.301.0; Mon, 12 Jun 2017 02:00:48 +0100 Received: from NKGEML513-MBX.china.huawei.com ([169.254.1.160]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0235.001; Mon, 12 Jun 2017 09:00:45 +0800 From: "Huangyihong (Rachel)" To: Mary Barnes , DISPATCH CC: Cullen Jennings , ART ADs Thread-Topic: [dispatch] Reminder: DISPATCH WG deadlines for IETF-99 Thread-Index: AQHS2XdDP2ndr4LdbkyYFAja0Zb6hqIZGOUAgAKvxiA= Date: Mon, 12 Jun 2017 01:00:44 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C49400B@nkgeml513-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.134.153.152] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C49400Bnkgeml513mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.593DE7C1.0117, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.160, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: af5e8d613efd03609573941b1c6555c8 Archived-At: Subject: Re: [dispatch] Reminder: DISPATCH WG deadlines for IETF-99 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Jun 2017 01:00:55 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C49400Bnkgeml513mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWFyeSwNCg0KSSBwbGFuIHRvIHN1Ym1pdCBhIGRyYWZ0IHRvIGRpc2N1c3MgdmlkZW8gZGVs aXZlcnkgaW4gaHlicmlkIG5ldHdvcmsuIEnigJlsbCBzdWJtaXQgaXQgYmVmb3JlIHRoZSBkcmFm dCBzdWJtaXNzaW9uIGRlYWRsaW5lLCBhbmQgYWxzbyBmb2xsb3cgdGhlIG5hbWluZyBjb252ZW50 aW9uLg0KDQpCUiwNClJhY2hlbA0KDQrlj5Hku7bkuro6IGRpc3BhdGNoIFttYWlsdG86ZGlzcGF0 Y2gtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIE1hcnkgQmFybmVzDQrlj5HpgIHml7bpl7Q6IDIw MTflubQ25pyIOOaXpSAwOjEzDQrmlLbku7bkuro6IERJU1BBVENIDQrmioTpgIE6IEN1bGxlbiBK ZW5uaW5nczsgQVJUIEFEcw0K5Li76aKYOiBSZTogW2Rpc3BhdGNoXSBSZW1pbmRlcjogRElTUEFU Q0ggV0cgZGVhZGxpbmVzIGZvciBJRVRGLTk5DQoNCkp1c3QgYSByZW1pbmRlciB0aGF0IHRoZSBj dXRvZmYgZm9yIG5vdGlmeWluZyBjaGFpcnMgb2YgdG9waWNzIGlzIHRoaXMgY29taW5nIE1vbmRh eSwgSnVuZSAxMi4gIEFuZCwgcGxlYXNlIGZvbGxvdyB0aGUgc3RhbmRhcmQgbmFtaW5nIGNvbnZl bnRpb24gZm9yIGRyYWZ0cyAtIGkuZS4sIHBsZWFzZSBpbmNsdWRlIC1kaXNwYXRjaC0gICBUaGF0 IG1ha2VzIGl0IGEgd2hvbGUgbG90IGVhc2llciB0byBwdXQgdG9nZXRoZXIgYW4gYWdlbmRhLg0K DQpSZWdhcmRzLA0KTWFyeS4NCg0KDQpPbiBUdWUsIE1heSAzMCwgMjAxNyBhdCAyOjAwIFBNLCBN YXJ5IEJhcm5lcyA8bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb208bWFpbHRvOm1hcnkuaWV0Zi5i YXJuZXNAZ21haWwuY29tPj4gd3JvdGU6DQpBcyBhIHJlbWluZGVyLCB0aGUgZm9sbG93aW5nIGRl YWRsaW5lcyBmb3IgdGhlIERJU1BBVENIIFdHIGZvciBJRVRGLTk5IGFyZSBjb21pbmcgdXA6DQoN CiAgKiAgIEp1bmUgMiwgMjAxNzogQ3V0b2ZmIGRhdGUgZm9yIEJvRiBzdWJtaXNzaW9ucw0KICAq ICAgSnVuZSAxMiwgMjAxNzogQ3V0b2ZmIGRhdGUgdG8gbm90aWZ5IHRoZSBjaGFpcnMvRElTUEFU Q0ggV0cgb2YgcGxhbnMgdG8gc3VibWl0IGEgcHJvcG9zYWwNCiAgKiAgIEp1bmUgMTgsIDIwMTc6 IEN1dG9mZiBmb3IgY2hhcnRlciBwcm9wb3NhbHMgZm9yIHRvcGljcw0KICAqICAgSnVuZSAyNSwg MjAxNzogQW5ub3VuY2VtZW50IG9mIHRvcGljcyB0aGF0IGhhdmUgYmVlbiBkaXNwYXRjaGVkIGZv ciBJRVRGIDk5DQogICogICBKdWx5IDMsIDIwMTc6IERyYWZ0IHN1Ym1pc3Npb24gZGVhZGxpbmUN CkZ1cnRoZXIgZGV0YWlsczogaHR0cHM6Ly90b29scy5pZXRmLm9yZy93Zy9kaXNwYXRjaC90cmFj L3dpa2kNCg0KQXMgYSByZW1pbmRlciwgKnBsZWFzZSogdXNlIHRoZSB0eXBpY2FsIFdHIG5hbWlu ZyBjb252ZW50aW9uIHdoZW4gc3VibWl0dGluZyBkb2N1bWVudHMgdGhhdCB5b3UnZCBsaWtlIHRv IGRpc2N1c3MgZHVyaW5nIHRoZSBESVNQQVRDSCBXRyBzZXNzaW9uOg0KICAgZHJhZnQteW91cnN1 cm5hbWVoZXJlLWRpc3BhdGNoLXh5eg0KDQpJdCdzIHZlcnkgaGVscGZ1bCB0byB0aGUgY2hhaXJz IHRvIGJlIGFibGUgdG8gZWFzaWx5IHNlZSByZWxldmFudCBkb2N1bWVudHMgdXNpbmcgdGhlIHRy YWNrZXIuICBBbmQsIGlmIHRoZSBkcmFmdCBtb3ZlcyB0byBhbm90aGVyIFdHIGxhdGVyLCBvdXIg aGFuZHkgZGFuZHkgdG9vbHMgaGF2ZSBhbiBlYXN5IHdheSB0byBsaW5rIHRoZSBkb2N1bWVudHMu DQpSZWdhcmRzLA0KTWFyeSBvbiBiZWhhbGYgb2YgRElTUEFUQ0ggV0cgY2hhaXJzIGFuZCBBUlQg QURzDQoNCg== --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C49400Bnkgeml513mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTrlrovkvZM7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1 IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBh bm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IlxA5a6L5L2TIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERl ZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJ e21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk65a6L5L2TO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3Jk U2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30N Ci8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjEyMTY4MTY3 NTg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE5OTc4NDQzODQ7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBjbTt9DQp1bA0K CXttYXJnaW4tYm90dG9tOjBjbTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5IaSBNYXJ5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIHBsYW4gdG8gc3VibWl0IGEgZHJhZnQgdG8gZGlzY3VzcyB2aWRlbyBkZWxpdmVyeSBp biBoeWJyaWQgbmV0d29yay4gSeKAmWxsIHN1Ym1pdCBpdCBiZWZvcmUgdGhlIGRyYWZ0IHN1Ym1p c3Npb24gZGVhZGxpbmUsIGFuZCBhbHNvIGZvbGxvdyB0aGUNCiBuYW1pbmcgY29udmVudGlvbi48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+QlIsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SYWNoZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IGRpc3Bh dGNoIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10NCjwvc3Bhbj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Luj6KGoIDwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5NYXJ5IEJhcm5lczxicj4NCjwvc3Bhbj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+5Y+R6YCB5pe26Ze0PHNwYW4gbGFuZz0iRU4t VVMiPjo8L3NwYW4+PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQiPiAyMDE3PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij7lubQ8 c3BhbiBsYW5nPSJFTi1VUyI+Njwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+ODwvc3Bhbj7m l6U8c3BhbiBsYW5nPSJFTi1VUyI+IDA6MTM8YnI+DQo8L3NwYW4+PGI+5pS25Lu25Lq6PHNwYW4g bGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gRElTUEFUQ0g8YnI+ DQo8L3NwYW4+PGI+5oqE6YCBPHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxh bmc9IkVOLVVTIj4gQ3VsbGVuIEplbm5pbmdzOyBBUlQgQURzPGJyPg0KPC9zcGFuPjxiPuS4u+mi mDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IFJlOiBb ZGlzcGF0Y2hdIFJlbWluZGVyOiBESVNQQVRDSCBXRyBkZWFkbGluZXMgZm9yIElFVEYtOTk8bzpw PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5KdXN0IGEgcmVtaW5kZXIgdGhh dCB0aGUgY3V0b2ZmIGZvciBub3RpZnlpbmcgY2hhaXJzIG9mIHRvcGljcyBpcyB0aGlzIGNvbWlu ZyBNb25kYXksIEp1bmUgMTIuJm5ic3A7IEFuZCwgcGxlYXNlIGZvbGxvdyB0aGUgc3RhbmRhcmQg bmFtaW5nIGNvbnZlbnRpb24gZm9yIGRyYWZ0cyAtIGkuZS4sIHBsZWFzZSBpbmNsdWRlIC1kaXNw YXRjaC0gJm5ic3A7IFRoYXQgbWFrZXMgaXQgYSB3aG9sZSBsb3QNCiBlYXNpZXIgdG8gcHV0IHRv Z2V0aGVyIGFuIGFnZW5kYS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5NYXJ5LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPk9uIFR1ZSwgTWF5IDMwLCAyMDE3IGF0IDI6MDAgUE0sIE1hcnkgQmFybmVzICZsdDs8 YSBocmVmPSJtYWlsdG86bWFyeS5pZXRmLmJhcm5lc0BnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5r Ij5tYXJ5LmlldGYuYmFybmVzQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ QXMgYSByZW1pbmRlciwgdGhlIGZvbGxvd2luZyBkZWFkbGluZXMgZm9yIHRoZSBESVNQQVRDSCBX RyBmb3IgSUVURi05OSBhcmUgY29taW5nIHVwOiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0 OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFuIGxhbmc9IkVOLVVTIj5KdW5lIDIsIDIwMTc6IEN1dG9m ZiBkYXRlIGZvciBCb0Ygc3VibWlzc2lvbnM8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gbGFuZz0iRU4t VVMiPkp1bmUgMTIsIDIwMTc6IEN1dG9mZiBkYXRlIHRvIG5vdGlmeSB0aGUgY2hhaXJzL0RJU1BB VENIIFdHIG9mIHBsYW5zIHRvIHN1Ym1pdCBhIHByb3Bvc2FsPG86cD48L286cD48L3NwYW4+PC9s aT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjxzcGFu IGxhbmc9IkVOLVVTIj5KdW5lIDE4LCAyMDE3OiBDdXRvZmYgZm9yIGNoYXJ0ZXIgcHJvcG9zYWxz IGZvciB0b3BpY3MmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPHNwYW4gbGFuZz0iRU4tVVMiPkp1bmUg MjUsIDIwMTc6IEFubm91bmNlbWVudCBvZiB0b3BpY3MgdGhhdCBoYXZlIGJlZW4gZGlzcGF0Y2hl ZCBmb3IgSUVURiA5OTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+SnVseSAzLCAy MDE3OiBEcmFmdCBzdWJtaXNzaW9uIGRlYWRsaW5lPG86cD48L286cD48L3NwYW4+PC9saT48L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkZ1cnRoZXIgZGV0YWls czogPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy93Zy9kaXNwYXRjaC90cmFjL3dpa2ki IHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cvZGlzcGF0Y2gvdHJh Yy93aWtpPC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+QXMgYSByZW1pbmRlciwgKnBsZWFzZSogdXNlIHRoZSB0eXBpY2FsIFdHIG5hbWluZyBjb252 ZW50aW9uIHdoZW4gc3VibWl0dGluZyBkb2N1bWVudHMgdGhhdCB5b3UnZCBsaWtlIHRvIGRpc2N1 c3MgZHVyaW5nIHRoZSBESVNQQVRDSCBXRyBzZXNzaW9uOiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7ICZuYnNwO2RyYWZ0LXlvdXJzdXJuYW1laGVyZS1kaXNwYXRjaC14eXo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkl0J3MgdmVyeSBo ZWxwZnVsIHRvIHRoZSBjaGFpcnMgdG8gYmUgYWJsZSB0byBlYXNpbHkgc2VlIHJlbGV2YW50IGRv Y3VtZW50cyB1c2luZyB0aGUgdHJhY2tlci4mbmJzcDsgQW5kLCBpZiB0aGUgZHJhZnQgbW92ZXMg dG8gYW5vdGhlciBXRyBsYXRlciwgb3VyIGhhbmR5IGRhbmR5IHRvb2xzIGhhdmUgYW4gZWFzeSB3 YXkgdG8gbGluayB0aGUgZG9jdW1lbnRzLiAmbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+UmVn YXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TWFyeSBvbiBiZWhhbGYgb2YgRElTUEFUQ0ggV0cg Y2hhaXJzIGFuZCBBUlQgQURzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C49400Bnkgeml513mbxchi_-- From nobody Thu Jun 15 12:09:43 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285C7127866 for ; Thu, 15 Jun 2017 12:09:42 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com header.b=BuRcKFBE; dkim=pass (1024-bit key) header.d=chromium.org header.b=oOMnxCKd Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N5kTI_EPdsv8 for ; Thu, 15 Jun 2017 12:09:40 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::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 A5374127078 for ; Thu, 15 Jun 2017 12:09:39 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id d64so1873136wmf.1 for ; Thu, 15 Jun 2017 12:09:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to :content-transfer-encoding; bh=jahQD+LSz2yRrXtf7YIGgAtIj8yS005nsvKKbsoZNmk=; b=BuRcKFBEWECTRJ8oP7Qal/lEOPiyuqUrSQiFkzV5ETCfFKpBlHHdR3UVdwmJ1Dsm6B RFZ6gOcI+4pTacI22fGtK2nnrQZy1YBmqkqdaZRRQuj92zcwscjvEWc7CswrdqlYFhHI 2kJR0b45P/V3dCY2Ero1pLD9ZGs0NgvJh4yt9Ie3e/CEm8A3l6l76eIxy9U9vVE2SR8k /I6i1QXDbTcxVBRCDr/23ABwatHvtsp/MjJCw/WshCJQCGbug/lCv1RTQHVywx1n5h/q qvkbNKQppObSIBP8kIgckYP+d4x5xURt7oKUCbewiz31VO443r8PM7m7B3yhu998gT86 7Cpg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:from:date:message-id:subject:to :content-transfer-encoding; bh=jahQD+LSz2yRrXtf7YIGgAtIj8yS005nsvKKbsoZNmk=; b=oOMnxCKd2XnHSBwUU2WVSlU0PKQGhtqQrEEyjCOrze0gQJ3/+w55krMUKB41U6lHqO YFbmmPvExhhUE9CXzX7aUMkwsmdiiElj3ZD01Qke/Tlfige6vv0tIzQIhYfNGWjSYqlx z/IkzzZADF48W6r3r6OzP2NW+5L1sPByAGz5Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-transfer-encoding; bh=jahQD+LSz2yRrXtf7YIGgAtIj8yS005nsvKKbsoZNmk=; b=Z/N2PK9eKmlMmrRHe95AAQ6TrTnbrrGEnmiNb6aHiMfb549sL8EoKXp1rPpd5LAX0R Bf02W/bNQctC/AM5VAwSVN2iyPwctiJ5WI8ZXPQWgIcqmHV26YDkn7DqsLQUQCG9L+jY wuduZ6OderXZkvUZzOE1DzNPFY6KvFnuO192OpJSOV0aPj4WEogxRhC7hotDqhCtItah d0d42gbG97pUJnLxnxdauUsHQi1vtUXKmoXcxuU5CxYR3VJZSf0jTYw9hNcrnvqn+6Yz Ros+cX9PhSLBxntlsqU2/eVHvC7Irz9S/N5Z81rIKm7wv8vapUB2cwBwe/qy1dOOUMsu Skgw== X-Gm-Message-State: AKS2vOxL+Q2NQ3EySSrXdIyzeQnqyLEFGu015w4b5nrMO0vzPUOmJ/Rx FZc99yc0s4w6YzaqduKH3pGrpgyas4FY9PsevA== X-Received: by 10.28.71.147 with SMTP id m19mr4601183wmi.92.1497553777627; Thu, 15 Jun 2017 12:09:37 -0700 (PDT) MIME-Version: 1.0 Sender: jyasskin@google.com Received: by 10.28.157.197 with HTTP; Thu, 15 Jun 2017 12:09:16 -0700 (PDT) From: Jeffrey Yasskin Date: Thu, 15 Jun 2017 12:09:16 -0700 X-Google-Sender-Auth: -_necepPs9e3GG7-_ex1SUUYUdg Message-ID: To: dispatch@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [dispatch] A packaging format for the web X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jun 2017 19:09:42 -0000 Hello Dispatch, TL;DR: We're bringing the work at https://github.com/WICG/webpackage to the IETF. People would like to use content offline and in other situations where there isn=E2=80=99t a direct connection to the server where the content originates. However, it's difficult to distribute and verify the authenticity of applications and content without a connection to the network. The W3C has addressed running applications offline with Service Workers (https://www.w3.org/TR/service-workers-1/), but not the problem of distribution. * People with expensive or intermittent internet connections are used to sharing files via P2P links and shared SD cards. They should be able to install web applications they received this way. Installing a web application requires a TLS-type guarantee that it came from and can use data owned by a particular origin. * Verification of the origin of the content isn't always necessary. For example, users currently share screenshots and MHTML documents with their peers, with no guarantee that the shared content is authentic. However, these formats have low fidelity (screenshots) and/or aren't interoperable (MHTML). We'd like an interoperable format that lets both publishers and readers package such content for use in an untrusted mode. * CDNs want to re-publish other origins' content so readers can access it more quickly or more privately. Currently, to attribute that content to the original origin, they need the full ability to publish arbitrary content under that origin's name. There should be a way to let them attribute only the exact content that the original origin published. We think a packaging format can help satisfy these use cases. This format likely also has other uses, and we should try to support such use cases as long as they don't compromise the offline use cases. For example, packages may help optimize transferring online content or let third-parties assert properties of the package via cross-signatures. The Chromium project has started work on this sort of packaging format within the W3C's WICG, at https://github.com/WICG/webpackage. We have a list of use cases, some goals and explicit non-goals, and a draft for the format itself. We believe the IETF is the ideal place to standardize the format, and in parallel we'll specify within the W3C how browsers should load it. I'll be writing an initial internet-draft in the next couple weeks, in time to bring it to IETF 99. We'd appreciate being directed to the appropriate place within the IETF to do this work. Thanks, Jeffrey Yasskin P.S. I'll be on vacation from June 16-23; I'll reply intermittently during that time but mostly once I get back. From nobody Fri Jun 16 13:34:56 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ADAA131867 for ; Fri, 16 Jun 2017 13:34:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.203 X-Spam-Level: X-Spam-Status: No, score=-4.203 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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 MCw7EiWbv-3F for ; Fri, 16 Jun 2017 13:34:53 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 63525127869 for ; Fri, 16 Jun 2017 13:34:53 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 16 Jun 2017 13:34:51 -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.1178.000; Fri, 16 Jun 2017 13:34:50 -0700 From: Paul Hoffman To: "dispatch@ietf.org" Thread-Topic: New proposed work: DNS over HTTPS Thread-Index: AQHS5uAAFeia1c+5vE2BTU0fwZxcsg== Date: Fri, 16 Jun 2017 20:34:50 +0000 Message-ID: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@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: <5A91F026E3BA024E8ECF7122ACBAA3C5@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dispatch] New proposed work: DNS over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 20:34:55 -0000 Greetings. We would like to propose that the work on DNS over HTTPS that is= currently embodied in the individual draft https://tools.ietf.org/html/dr= aft-hoffman-dns-over-https-01 be dispatched at IETF 99. The work has been discussed for the last nine months on the IETF-sponsored = mailing list at https://www.ietf.org/mailman/listinfo/dnsoverhttp and was a= t the core of a bar bof in Seoul attended by around 80 people with a genera= l consensus that standardization would benefit this space. I understand the= draft should be resubmitted with the dispatch naming convention and will b= e very soon. This seems to us to be an Application protocol, but the httpbis WG generall= y does not take on how-to-use HTTP (that is, "foo over HTTP" work items), s= o dispatch's help in progressing the work would be appreciated. We emphasiz= e that we seek work consistent with the goals of this previous work (and be= lieve it to be a strong starting point), but the actual protocol specificat= ion is of course a matter of IETF consensus not pre-determined by that draf= t. As a bit of background, the Internet of course does not always provide good= end-to-end reachability for DNS transport and this is especially true when= using confidential and integrity transports for DNS. On-path network devic= es may spoof DNS responses, block DNS requests, track DNS activity, or just= redirect DNS queries to different DNS servers that give less-than-honest a= nswers. This work focuses on interacting with DNS servers, not just using encapsula= tion as a tunnel. Using secure HTTPS provides an alternative transport opti= on and also provides a mechanism for obtaining and using DNS data in web br= owsers, both natively and in security contexts governed by the Same-Origin = security policy. Another clear goal of the approach is to be a good fit for the HTTP protoco= l: good answers for caching, support for an ecosystem of different media ty= pes (such as both traditional DNS framing and more web-friendly things like= JSON), and leverage of the multiplexing and prioritization schemes modern = HTTP can provide. Use of HTTPS is very common, of course, and the ability to use an establish= ed connection to carry DNS information can provide both performance and con= fidentiality benefits over other approaches in circumstances when HTTPS is = the prominent transport available. This proposal should not be considered e= xclusive or competitive with the valuable mechcanisms of the drive WG. Paul and Patrick= From nobody Fri Jun 16 15:37:22 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01B371287A5 for ; Fri, 16 Jun 2017 15:37:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.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 3Ab58XLNGeKP for ; Fri, 16 Jun 2017 15:37:18 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 4BE09127B31 for ; Fri, 16 Jun 2017 15:37:18 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id u195so21745696wmd.1 for ; Fri, 16 Jun 2017 15:37:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Mu1aJbZuW2Ahbm1EFz09/JNeNjO8uLpdUZhqaOzwKiw=; b=I2Fm2fYk8bFRqhGWwclYvcx6uEryglQQh6Ts7AhGNUCsLsUnLERjOxNTS/TAGnef8H NTFVBgEFdwqctkpUw4kaJvoPHDFdgnrJobpNvLQ9a3rPhwEk2wcvCa0hjQVBAJlwxHzL Q8Lc6m0D12MjbHhuXnrezg5vyYTDTpS3+xiQJBDMRu8o07P2pgC7sg2twEzsdq/1hznA g9KbHYYos3UE33ut0k3JKqUSII9YE4d0T2jjH9CvBKIFJ/U31oOmK7lpx6cEWtMQKr+J 1p0rqKzSQhsKucuPJRvmCHJQpw5m32EMu6rG9lvdMj/wgPBz5fa3n5MXdZUZEoXCrMKi KQmw== 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=Mu1aJbZuW2Ahbm1EFz09/JNeNjO8uLpdUZhqaOzwKiw=; b=HfiUSCEwkkXkbstQiE6H88ItKSpAE9TzrNI9r/EL/YsJZmVa8/3WigFZwHIwPUgf6I 80HZOqFdvmSmkfk3kilvJbuR3ppeIQ2JYeFhV2v58VzAdiIWS0oKZHYXXKSf80lgnYaY BAxZ0vADtt2aOCdrf6rNLKsyg+uYXWfvudYRAC84RVoPPS9y6JVpgdHqVugXSnk8N8TO 0pR0q51YDnEJJkOWhlg7h7VmVSzHRuum5lJJ2YGHSQHcr7Cg3gxL1o1WmkMN9BDqzgL1 zV2FZTJI0uDsyGPK6NAQzKghf2OU9Si3dorQOLbSaoRIFuS/Rk4/z1FxMO4WnA5LaUZ4 p4VQ== X-Gm-Message-State: AKS2vOzZqxGf/TvPVrdjP6N0LjHhm+8OYeYGNl8MEELQPm3k1a9o/m/C HT6/VBTeTVu4+i6OWhEG/W8yVmpA1jUk X-Received: by 10.28.146.12 with SMTP id u12mr8796342wmd.15.1497652636603; Fri, 16 Jun 2017 15:37:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.16 with HTTP; Fri, 16 Jun 2017 15:37:15 -0700 (PDT) In-Reply-To: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org> References: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org> From: Richard Barnes Date: Fri, 16 Jun 2017 18:37:15 -0400 Message-ID: To: Paul Hoffman Cc: "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="001a114434a066ea0505521b6ddd" Archived-At: Subject: Re: [dispatch] New proposed work: DNS over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Jun 2017 22:37:21 -0000 --001a114434a066ea0505521b6ddd Content-Type: text/plain; charset="UTF-8" Assuming we keep this bounded to the question of how to map DNS request/response pairs to HTTP request/response pairs, with a little bit of JSON syntax to make programming nice, this seems like a nicely bounded piece of work that would be well-suited to a small working group. Looking back at that the Bar BoF, however, I would be *very* wary of scope creep, so the charter should be written very tightly and enforced by the chairs and ADs. On Fri, Jun 16, 2017 at 4:34 PM, Paul Hoffman wrote: > Greetings. We would like to propose that the work on DNS over HTTPS that > is currently embodied in the individual draft > https://tools.ietf.org/html/draft-hoffman-dns-over-https-01 be dispatched > at IETF 99. > > The work has been discussed for the last nine months on the IETF-sponsored > mailing list at https://www.ietf.org/mailman/listinfo/dnsoverhttp and was > at the core of a bar bof in Seoul attended by around 80 people with a > general consensus that standardization would benefit this space. I > understand the draft should be resubmitted with the dispatch naming > convention and will be very soon. > > This seems to us to be an Application protocol, but the httpbis WG > generally does not take on how-to-use HTTP (that is, "foo over HTTP" work > items), so dispatch's help in progressing the work would be appreciated. We > emphasize that we seek work consistent with the goals of this previous work > (and believe it to be a strong starting point), but the actual protocol > specification is of course a matter of IETF consensus not pre-determined by > that draft. > > As a bit of background, the Internet of course does not always provide > good end-to-end reachability for DNS transport and this is especially true > when using confidential and integrity transports for DNS. On-path network > devices may spoof DNS responses, block DNS requests, track DNS activity, or > just redirect DNS queries to different DNS servers that give > less-than-honest answers. > > This work focuses on interacting with DNS servers, not just using > encapsulation as a tunnel. Using secure HTTPS provides an alternative > transport option and also provides a mechanism for obtaining and using DNS > data in web browsers, both natively and in security contexts governed by > the Same-Origin security policy. > > Another clear goal of the approach is to be a good fit for the HTTP > protocol: good answers for caching, support for an ecosystem of different > media types (such as both traditional DNS framing and more web-friendly > things like JSON), and leverage of the multiplexing and prioritization > schemes modern HTTP can provide. > > Use of HTTPS is very common, of course, and the ability to use an > established connection to carry DNS information can provide both > performance and confidentiality benefits over other approaches in > circumstances when HTTPS is the prominent transport available. This > proposal should not be considered exclusive or competitive with the > valuable mechcanisms of the drive WG. > > Paul and Patrick > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a114434a066ea0505521b6ddd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Assuming we keep this bounded to the question of how = to map DNS request/response pairs to HTTP request/response pairs, with a li= ttle bit of JSON syntax to make programming nice, this seems like a nicely = bounded piece of work that would be well-suited to a small working group.

Looking back at that the Bar BoF, however, I wo= uld be *very* wary of scope creep, so the charter should be written very ti= ghtly and enforced by the chairs and ADs.


On Fri, Jun 16, 2017 at 4:34 PM= , Paul Hoffman <paul.hoffman@icann.org> wrote:
Greetings. We would like to propose that the work= on DNS over HTTPS that is=C2=A0 currently embodied in the individual draft= https://tools.ietf.org/html/draft-h= offman-dns-over-https-01 be dispatched at IETF 99.

The work has been discussed for the last nine months on the IETF-sponsored = mailing list at https://www.ietf.org/mailman/l= istinfo/dnsoverhttp and was at the core of a bar bof in Seoul attended = by around 80 people with a general consensus that standardization would ben= efit this space. I understand the draft should be resubmitted with the disp= atch naming convention and will be very soon.

This seems to us to be an Application protocol, but the httpbis WG generall= y does not take on how-to-use HTTP (that is, "foo over HTTP" work= items), so dispatch's help in progressing the work would be appreciate= d. We emphasize that we seek work consistent with the goals of this previou= s work (and believe it to be a strong starting point), but the actual proto= col specification is of course a matter of IETF consensus not pre-determine= d by that draft.

As a bit of background, the Internet of course does not always provide good= end-to-end reachability for DNS transport and this is especially true when= using confidential and integrity transports for DNS. On-path network devic= es may spoof DNS responses, block DNS requests, track DNS activity, or just= redirect DNS queries to different DNS servers that give less-than-honest a= nswers.

This work focuses on interacting with DNS servers, not just using encapsula= tion as a tunnel. Using secure HTTPS provides an alternative transport opti= on and also provides a mechanism for obtaining and using DNS data in web br= owsers, both natively and in security contexts governed by the Same-Origin = security policy.

Another clear goal of the approach is to be a good fit for the HTTP protoco= l: good answers for caching, support for an ecosystem of different media ty= pes (such as both traditional DNS framing and more web-friendly things like= JSON), and leverage of the multiplexing and prioritization schemes modern = HTTP can provide.

Use of HTTPS is very common, of course, and the ability to use an establish= ed connection to carry DNS information can provide both performance and con= fidentiality benefits over other approaches in circumstances when HTTPS is = the prominent transport available. This proposal should not be considered e= xclusive or competitive with the valuable mechcanisms of the drive WG.

Paul and Patrick
_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch

--001a114434a066ea0505521b6ddd-- From nobody Sat Jun 17 05:33:40 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CDD7129485 for ; Sat, 17 Jun 2017 05:33:38 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNuO4IrLwEH6 for ; Sat, 17 Jun 2017 05:33:35 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 497E912949A for ; Sat, 17 Jun 2017 05:33:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 76298BE3E; Sat, 17 Jun 2017 13:33:33 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8zI34-Wn2Mw; Sat, 17 Jun 2017 13:33:31 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 16F18BE39; Sat, 17 Jun 2017 13:33:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1497702811; bh=6BAXW0HEC24ck0L5as68pDqu+rX+XUERuyZP17iBEaU=; h=Subject:To:References:From:Date:In-Reply-To:From; b=viAAqt/+w7QTQp6Bz+xy7TLLTIXS02LBEkCKclMnizxF1Uco3c+xfUVs5lzqw80ts FPA703ieuTFlKwe210wZ5tasbQTDC4gPSG1/mROTvJ34C9xEmM/Ai0bZgyzC8WDWmt 3UKcyltxiI1PbUxe/fqTzhjGm5swpnPOXtKOe3os= To: Paul Hoffman , "dispatch@ietf.org" References: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Sat, 17 Jun 2017 13:33:30 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BTrd65sNVwcUIrOIeNevDdNlgkuxk4J4N" Archived-At: Subject: Re: [dispatch] New proposed work: DNS over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 12:33:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --BTrd65sNVwcUIrOIeNevDdNlgkuxk4J4N Content-Type: multipart/mixed; boundary="6DBfXvWajlwvrmU0lAXQ1klQ3DVNK8ttn"; protected-headers="v1" From: Stephen Farrell To: Paul Hoffman , "dispatch@ietf.org" Message-ID: Subject: Re: [dispatch] New proposed work: DNS over HTTPS References: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org> In-Reply-To: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org> --6DBfXvWajlwvrmU0lAXQ1klQ3DVNK8ttn Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable FWIW I generally support this work. Despite the last para of the security considerations section (which may be partly in response to some off list comments I made, and if so thanks:-), I think more effort needs to be devoted to considering attacks that might use this. For example, it may be that it'd be sensible to explore whether or not a browser using this mechanism ought limit the DNS cache resulting to the tab that is rendering content from that origin or something. And yes, current browsers may be equally vulnerable to similar attacks via WiFi APs, but there remain differences - e.g., folks probably only regularly interact with a few APs, but with many web sites and perhaps thousands of https-speaking hosts so there is the potential for this to expand the horizon a lot, despite the admonition in the referenced text. Especially when one considers the risible state of so-called "consent" on the web. So if such analysis is part of the planned work, then I'd be happy to support progressing it. If not... not. Cheers, S. On 16/06/17 21:34, Paul Hoffman wrote: > Greetings. We would like to propose that the work on DNS over HTTPS tha= t is currently embodied in the individual draft https://tools.ietf.org/h= tml/draft-hoffman-dns-over-https-01 be dispatched at IETF 99. >=20 > The work has been discussed for the last nine months on the IETF-sponso= red mailing list at https://www.ietf.org/mailman/listinfo/dnsoverhttp and= was at the core of a bar bof in Seoul attended by around 80 people with = a general consensus that standardization would benefit this space. I unde= rstand the draft should be resubmitted with the dispatch naming conventio= n and will be very soon. >=20 > This seems to us to be an Application protocol, but the httpbis WG gene= rally does not take on how-to-use HTTP (that is, "foo over HTTP" work ite= ms), so dispatch's help in progressing the work would be appreciated. We = emphasize that we seek work consistent with the goals of this previous wo= rk (and believe it to be a strong starting point), but the actual protoco= l specification is of course a matter of IETF consensus not pre-determine= d by that draft. >=20 > As a bit of background, the Internet of course does not always provide = good end-to-end reachability for DNS transport and this is especially tru= e when using confidential and integrity transports for DNS. On-path netwo= rk devices may spoof DNS responses, block DNS requests, track DNS activit= y, or just redirect DNS queries to different DNS servers that give less-t= han-honest answers. >=20 > This work focuses on interacting with DNS servers, not just using encap= sulation as a tunnel. Using secure HTTPS provides an alternative transpor= t option and also provides a mechanism for obtaining and using DNS data i= n web browsers, both natively and in security contexts governed by the Sa= me-Origin security policy. >=20 > Another clear goal of the approach is to be a good fit for the HTTP pro= tocol: good answers for caching, support for an ecosystem of different me= dia types (such as both traditional DNS framing and more web-friendly thi= ngs like JSON), and leverage of the multiplexing and prioritization schem= es modern HTTP can provide. >=20 > Use of HTTPS is very common, of course, and the ability to use an estab= lished connection to carry DNS information can provide both performance a= nd confidentiality benefits over other approaches in circumstances when H= TTPS is the prominent transport available. This proposal should not be co= nsidered exclusive or competitive with the valuable mechcanisms of the dr= ive WG. >=20 > Paul and Patrick > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 --6DBfXvWajlwvrmU0lAXQ1klQ3DVNK8ttn-- --BTrd65sNVwcUIrOIeNevDdNlgkuxk4J4N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZRSGaAAoJEC88hzaAX42iRL0IAL2Jx37sUqXCuTXNaC2Yw67W D4+SVIQl0qpzQTRY6jcwqgDWQ9XGenZHZWJa9RnrKLeh8T7M8d7Y9pqoLdKgBuyi ZB8EdxT0oa1JY9DuGdcVbo/37mmH19PDCebeK+a8BwofP7SlquIDPgctUvKMAiku isPCzvbbRIcXkwIofbyVRgI2LOAPXKX9gifUUdkMRtM700/TuOH7l4ngBj8FM+Q+ iInVmFuqM3yFJ2ajJHIMce7Lcf8cW8TZ5mwn3pK5T8zNXmpIvQJgjLjocyoZNWLU jp04Ra9Q+5QYFob6xFIiAgg2XdiRyb7VEI1x44bA/Vz8j6QkY4FXdZBOByqWnqM= =RfTV -----END PGP SIGNATURE----- --BTrd65sNVwcUIrOIeNevDdNlgkuxk4J4N-- From nobody Sat Jun 17 10:43:49 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5C47128954 for ; Sat, 17 Jun 2017 10:43:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwJ3FMEXwuqr for ; Sat, 17 Jun 2017 10:43:46 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-2.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 6D986126CBF for ; Sat, 17 Jun 2017 10:43:46 -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.1178.4; Sat, 17 Jun 2017 10:43:44 -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.1178.000; Sat, 17 Jun 2017 10:43:44 -0700 From: Paul Hoffman To: Stephen Farrell CC: "dispatch@ietf.org" Thread-Topic: [Ext] Re: [dispatch] New proposed work: DNS over HTTPS Thread-Index: AQHS5uAAWFUC6aODQkKBu5Rz9z1YmKIpc3IAgABWqIA= Date: Sat, 17 Jun 2017 17:43:43 +0000 Message-ID: <474023DC-BDEA-4F48-B23E-BA29B2B9645A@icann.org> References: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [192.0.32.234] Content-Type: multipart/signed; boundary="Apple-Mail=_E660D93E-FCE9-48DE-91D7-2D5F984AF720"; protocol="application/pgp-signature"; micalg=pgp-sha256 MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] [Ext] Re: New proposed work: DNS over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 17:43:48 -0000 --Apple-Mail=_E660D93E-FCE9-48DE-91D7-2D5F984AF720 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Jun 17, 2017, at 5:33 AM, Stephen Farrell = wrote: > So if such analysis is part of the planned work, then I'd be > happy to support progressing it. If not... not. It wasn't part of the planned work because we thought we dealt with the = issue you reported. It is now part of the planned work because it = appears we undershot. This kind of consideration should definitely be = discussed in the document. --Paul --Apple-Mail=_E660D93E-FCE9-48DE-91D7-2D5F984AF720 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZRWpPAAoJEJz/fXByZmLZjHUIALeK3q+ZS83q527njwVQOxAA 5ZPo3X0aBQk8mSeXq0ilXRPF+amS1Y3jUsAE16xMdodYPcsx1w/ftZJ1K2bnejnv IU6KnYRl1AhFdOcKMxXCcT7hw7i/rpsEv4Nf7jHJpR92QDkrcnPxfOyWub4/mRDt XRbb1r5hQfzMihdMTq6tnkJ9f7pcK7WnNyhqG2EAMCKkpDdInsmzu2KQr/HgWU7p wisnt4p/uL2OZSWA6/4A8ETRGrxkEWkPtcIthTXpdYlxqz0KvanTojc/ege+fbO3 pOAfnzULBAXFhu70gyLh7V+i7YgH4F00J4Hm0D3jNdehmG/lu41bzzXNux6q2W4= =sK12 -----END PGP SIGNATURE----- --Apple-Mail=_E660D93E-FCE9-48DE-91D7-2D5F984AF720-- From nobody Sat Jun 17 11:06:28 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 599A6129A99 for ; Sat, 17 Jun 2017 11:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ECKfRD-iJVAy for ; Sat, 17 Jun 2017 11:06:24 -0700 (PDT) Received: from out.west.pexch112.icann.org (pfe112-ca-1.pexch112.icann.org [64.78.40.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02CB412957F for ; Sat, 17 Jun 2017 11:06:24 -0700 (PDT) Received: from PMBX112-W1-CA-1.pexch112.icann.org (64.78.40.21) by PMBX112-W1-CA-2.pexch112.icann.org (64.78.40.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 17 Jun 2017 11:06:21 -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.1178.000; Sat, 17 Jun 2017 11:06:21 -0700 From: Paul Hoffman To: "dispatch@ietf.org" Thread-Topic: Initial version of draft-hoffman-dispatch-dns-over-https Thread-Index: AQHS55Rs+VkJj/e1ZkeGqaSt/fzELg== Date: Sat, 17 Jun 2017 18:06:20 +0000 Message-ID: <59522F59-E46B-4983-A130-F2B51590CF75@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: <6C43A3F374A2A94D8C91E2D6F7A9DA67@pexch112.icann.org> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: [dispatch] Initial version of draft-hoffman-dispatch-dns-over-https X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 18:06:25 -0000 Greetings. Based on the advice from the chairs, we have given a new filenam= e to our dns-over-https draft. This will hopefully get the draft picked up = in the DISPATCH WG tracker page. --Paul and Patrick A new version of I-D, draft-hoffman-dispatch-dns-over-https-00.txt has been successfully submitted by Paul Hoffman and posted to the IETF repository. Name: draft-hoffman-dispatch-dns-over-https Revision: 00 Title: DNS Queries over HTTPS Document date: 2017-06-17 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/id/draft-hoffman-dispatch-dns-over-htt= ps-00.txt=20 Status: https://datatracker.ietf.org/doc/draft-hoffman-dispatch-dns= -over-https/=20 Htmlized: https://tools.ietf.org/html/draft-hoffman-dispatch-dns-over= -https-00=20 Htmlized: https://datatracker.ietf.org/doc/html/draft-hoffman-dispatc= h-dns-over-https-00=20 Abstract: DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication. Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. This document describes how to run DNS service over HTTP using https:// URIs. From nobody Sat Jun 17 11:22:54 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EA5129B55 for ; Sat, 17 Jun 2017 11:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZZALAevh2PWy for ; Sat, 17 Jun 2017 11:22:50 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBBF7129A97 for ; Sat, 17 Jun 2017 11:22:50 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 45A23BE50; Sat, 17 Jun 2017 19:22:48 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDVyFi9ac7ao; Sat, 17 Jun 2017 19:22:47 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7D0EBBE4D; Sat, 17 Jun 2017 19:22:46 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1497723767; bh=oEi2WBYV11SAvKgxeoZ7ECxuCgXfPgxExrg//YeiU9U=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Kp99Fr+fz5Nsnlms7ygvOVO5s0kkQKMN1zSMEM6fjznIT4ZTruufuERZk/jK3oCdu clMaHvosdC7ZQLXzuz/vnnk5UmqMytC7PCMSgMTZuBlxcofYm4agHMFklYt4QXARW/ WOhp4vWtm26S6a1/geUMIoHkAhfk1XVBnEfQOKCM= To: Paul Hoffman Cc: "dispatch@ietf.org" References: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org> <474023DC-BDEA-4F48-B23E-BA29B2B9645A@icann.org> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <31f72b02-9dfb-ad0c-e40a-abf588ae9486@cs.tcd.ie> Date: Sat, 17 Jun 2017 19:22:45 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <474023DC-BDEA-4F48-B23E-BA29B2B9645A@icann.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ccsOMVviQrNOU2E5HGtbu9DLgAVeni05K" Archived-At: Subject: Re: [dispatch] [Ext] Re: New proposed work: DNS over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 18:22:53 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ccsOMVviQrNOU2E5HGtbu9DLgAVeni05K Content-Type: multipart/mixed; boundary="klm8h1viMsVd3iJ3iEMpe5iwj5T38Wc56"; protected-headers="v1" From: Stephen Farrell To: Paul Hoffman Cc: "dispatch@ietf.org" Message-ID: <31f72b02-9dfb-ad0c-e40a-abf588ae9486@cs.tcd.ie> Subject: Re: [Ext] Re: [dispatch] New proposed work: DNS over HTTPS References: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org> <474023DC-BDEA-4F48-B23E-BA29B2B9645A@icann.org> In-Reply-To: <474023DC-BDEA-4F48-B23E-BA29B2B9645A@icann.org> --klm8h1viMsVd3iJ3iEMpe5iwj5T38Wc56 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 17/06/17 18:43, Paul Hoffman wrote: > On Jun 17, 2017, at 5:33 AM, Stephen Farrell > wrote: >> So if such analysis is part of the planned work, then I'd be happy >> to support progressing it. If not... not. >=20 > It wasn't part of the planned work because we thought we dealt with > the issue you reported. It is now part of the planned work because it > appears we undershot. This kind of consideration should definitely be > discussed in the document. Ack. So long as the analysis is done and appropriately documented, then I'd be fine. I'm not sure myself how much text that'd result in for this document - I guess that'll depend on the results found. S. >=20 > --Paul >=20 --klm8h1viMsVd3iJ3iEMpe5iwj5T38Wc56-- --ccsOMVviQrNOU2E5HGtbu9DLgAVeni05K Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZRXN2AAoJEC88hzaAX42iWQoH/i4lTySF6rdbO2O6DolUujxY OY6f6W55+OmSL5eX1yixqpTqmbTyBpY8UcZnk3Xiru0+NeWNKS27aMZYSLMCUebw XtJ6kY1rpE8q88y97THOBOlxvO1gFys63c+1Sdc10hV5HZctw9E4xWXLsUKODQzW zqgua+HEBFgNsL8GsXHvrcrU/lKaGn9Ikfd6a3AOdFI+fn5sfJjUcgMByTzHNVUF Zox5yZudJNvs3lpR9yCMwUXo9fP5hQgcj6BK+OKFZlQU+SkstujAOUuRTA9v+Gvb Sukftxd5c8uQbix4wEFlNdDqnPCWhyeZPSTckCiZc+QElLv4uWXrgQEoFXJ9YfI= =ki4h -----END PGP SIGNATURE----- --ccsOMVviQrNOU2E5HGtbu9DLgAVeni05K-- From nobody Sat Jun 17 19:10:33 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD2E0124BE8 for ; Sat, 17 Jun 2017 19:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=es/2lCRY; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=B25+P9hc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OcZKjv3xZZU9 for ; Sat, 17 Jun 2017 19:10:29 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54D7A1201F2 for ; Sat, 17 Jun 2017 19:10:29 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id BC80DAF5; Sat, 17 Jun 2017 22:10:28 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sat, 17 Jun 2017 22:10:28 -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:x-sasl-enc; s=fm1; bh=c0lmjU+SRY4nn3E6iK Xoac/xU1BdZjE6uKPtPCqfZ9w=; b=es/2lCRY5k6dAc4stO1nD2T+mRLpL8AtK/ 3BbLV7mOZ2lF3BkxLerV0ql3LUq5cxxZaHJxlA8IibteO0+KBoyHUHe+UlYfREe5 FF78/s6NpYQ1YCB2oO/uZw3q2PQI7UpNF63wjHSpNwFhmRmAGD6vgqnS7E3YO7jQ 5JJDWH/JROH0Hu6AlgC0k5MRz2jd2n0g0vfH3+bXZ9hGeL9yHkI1n4uhR5HNNip5 cMfgBBVTMZeReER3RsoRgJNZp9iaG/s6mIHzgNckM40Kqq99kSksk0jPSswrUeP6 ojV2bbVIb1L6jVWyPXrBptA/OOdLMqNuNJIHIKXcoPzQEBidwaJg== 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:x-sasl-enc; s= fm1; bh=c0lmjU+SRY4nn3E6iKXoac/xU1BdZjE6uKPtPCqfZ9w=; b=B25+P9hc 6OZ0utZh781gP2HrHj15keMYyrwl/rTqmx5A+rveGDjZ6eu1L5yTHRRnWwvXNo2G mUc50TBZcQdOLTIEvKoOInbpOcsNFMlLxh9J28TA7aLdqTtYkpsfUyzmBwkxNMdw pL/+QBv8cynxAP1wDQkD9Ng28yUJFP+Px7vIUqjjVmCPhcrqumkOEnzdSUmo4fRs WKCIYxgW/xREGVos98ZstpwDQHHaWSvmS2tMhSrnAOy3R/drcm/7QYYzcOYKz/w1 JAUXeMhe1AGX5ouH8EaNCb8OkXgi/KZ87WtaElrPzucsnLGVSM9AzBpUrR62GNUP 5VQyUet/IwDzyw== X-ME-Sender: X-Sasl-enc: uEi+wD8YqeFczpeouuF3cnWxKXAQsh4pTznIsJIIIera 1497751827 Received: from [192.168.66.109] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 1A66D24998; Sat, 17 Jun 2017 22:10:26 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Sun, 18 Jun 2017 12:10:24 +1000 Cc: Paul Hoffman , "dispatch@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <415E24BA-331F-4117-A16D-488E20779493@mnot.net> References: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org> To: Richard Barnes X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dispatch] New proposed work: DNS over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jun 2017 02:10:32 -0000 +1 to everything Richard says. > On 17 Jun 2017, at 8:37 am, Richard Barnes wrote: >=20 > Assuming we keep this bounded to the question of how to map DNS = request/response pairs to HTTP request/response pairs, with a little bit = of JSON syntax to make programming nice, this seems like a nicely = bounded piece of work that would be well-suited to a small working = group. >=20 > Looking back at that the Bar BoF, however, I would be *very* wary of = scope creep, so the charter should be written very tightly and enforced = by the chairs and ADs. >=20 >=20 > On Fri, Jun 16, 2017 at 4:34 PM, Paul Hoffman = wrote: > Greetings. We would like to propose that the work on DNS over HTTPS = that is currently embodied in the individual draft = https://tools.ietf.org/html/draft-hoffman-dns-over-https-01 be = dispatched at IETF 99. >=20 > The work has been discussed for the last nine months on the = IETF-sponsored mailing list at = https://www.ietf.org/mailman/listinfo/dnsoverhttp and was at the core of = a bar bof in Seoul attended by around 80 people with a general consensus = that standardization would benefit this space. I understand the draft = should be resubmitted with the dispatch naming convention and will be = very soon. >=20 > This seems to us to be an Application protocol, but the httpbis WG = generally does not take on how-to-use HTTP (that is, "foo over HTTP" = work items), so dispatch's help in progressing the work would be = appreciated. We emphasize that we seek work consistent with the goals of = this previous work (and believe it to be a strong starting point), but = the actual protocol specification is of course a matter of IETF = consensus not pre-determined by that draft. >=20 > As a bit of background, the Internet of course does not always provide = good end-to-end reachability for DNS transport and this is especially = true when using confidential and integrity transports for DNS. On-path = network devices may spoof DNS responses, block DNS requests, track DNS = activity, or just redirect DNS queries to different DNS servers that = give less-than-honest answers. >=20 > This work focuses on interacting with DNS servers, not just using = encapsulation as a tunnel. Using secure HTTPS provides an alternative = transport option and also provides a mechanism for obtaining and using = DNS data in web browsers, both natively and in security contexts = governed by the Same-Origin security policy. >=20 > Another clear goal of the approach is to be a good fit for the HTTP = protocol: good answers for caching, support for an ecosystem of = different media types (such as both traditional DNS framing and more = web-friendly things like JSON), and leverage of the multiplexing and = prioritization schemes modern HTTP can provide. >=20 > Use of HTTPS is very common, of course, and the ability to use an = established connection to carry DNS information can provide both = performance and confidentiality benefits over other approaches in = circumstances when HTTPS is the prominent transport available. This = proposal should not be considered exclusive or competitive with the = valuable mechcanisms of the drive WG. >=20 > Paul and Patrick > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Mark Nottingham https://www.mnot.net/ From nobody Sun Jun 18 17:25:42 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F351243F6 for ; Sun, 18 Jun 2017 17:25:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 aB4by7rx7V4b for ; Sun, 18 Jun 2017 17:25:39 -0700 (PDT) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F03901200C5 for ; Sun, 18 Jun 2017 17:25:38 -0700 (PDT) Received: by mail-lf0-x22c.google.com with SMTP id v20so46885406lfa.1 for ; Sun, 18 Jun 2017 17:25:38 -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=bLVS6uHhPpAb6Yp+HERhcvDBsM9bdoG57G3o3NP6Fio=; b=tyWuomLd2JabI0Ie+2ip3rPPH8/DbyW3Mx/QNFQEIE86vFRcvU82Kum089PZ9l2U7+ kPHzwwPp9otdjSV6ZZ7L0lz61qbt9M40bCigMu8KzmGobwx0rNJjGg+4kM+D43NojB+j UwnXLs8sW98r6+ozaLPR7sT1NfKv4qgHd63SSlqMagzsSm/8o3pzxieroNekwbyYwtPA dm/3lri8wsLAveEDzQyZQTeASeP/eG6X31hJABHMcWLa+JM0BAPR+VM/R9VXfnb+9F/y /HzNE3LJJWKbQBCv6kHSM+fIm+IRDK+qBJUMkcAgjyVeUDKX1ZEXOMNCjiBfpzlN8UQL 0Hhg== 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=bLVS6uHhPpAb6Yp+HERhcvDBsM9bdoG57G3o3NP6Fio=; b=k+NeQ/iYHSIWm8zDY+Zu6Ph1R751VeBAjvPbzJtGIMoILzbVPcz2z7Jq6C6O9HqRSU E+2k3ljeauafHESdRKV7fvlUimfYiLQhwGG+/R5xnk/TCTCE9xOtKIDqEGiksIve7fU4 AHw21JFQnA33+xCwF0RB66DnUAF99hKrCvHWotvFfmDziA+232gfCA1/UKnKL6k4ZGix xYAqk7el8OuTSaGLZEon0Phk6IhmpzAla4G6b1F4+O/JLtV3CwPUwZxJxwkGwuJLxuiW PK+Hr54aC+huF68b9ioZ7a2DmFHXUJT+YWwrEvyHOApOqETRzmS3oRDIQEbscmjLJAzd SJ8Q== X-Gm-Message-State: AKS2vOx66yoMOT8+D6PDiNrfkkCPqBC1vRDQ4AV20NYURRvw2zRJ0MiW duct4Ud6wfnoQWOZpuywq6ZC70bJbs4R X-Received: by 10.25.166.15 with SMTP id p15mr5704382lfe.43.1497831937331; Sun, 18 Jun 2017 17:25:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Sun, 18 Jun 2017 17:25:36 -0700 (PDT) In-Reply-To: <474023DC-BDEA-4F48-B23E-BA29B2B9645A@icann.org> References: <52CA02A7-705D-4D5E-AC1D-FB0B02BB4305@icann.org> <474023DC-BDEA-4F48-B23E-BA29B2B9645A@icann.org> From: Martin Thomson Date: Mon, 19 Jun 2017 10:25:36 +1000 Message-ID: To: Paul Hoffman Cc: Stephen Farrell , "dispatch@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dispatch] [Ext] Re: New proposed work: DNS over HTTPS X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 00:25:41 -0000 On 18 June 2017 at 03:43, Paul Hoffman wrote: > On Jun 17, 2017, at 5:33 AM, Stephen Farrell wrote: >> So if such analysis is part of the planned work, then I'd be >> happy to support progressing it. If not... not. > > It wasn't part of the planned work because we thought we dealt with the issue you reported. It is now part of the planned work because it appears we undershot. This kind of consideration should definitely be discussed in the document. I've had a number of discussions about this recently, and I'm really glad you say this. The interaction between this work and recent extensions to HTTP change the dynamics considerably. I believe that there is an answer to be had, but navigating the competing pressures of connection coalescing, ORIGIN frames, Alt-Svc, and secondary certificates isn't something we should be too dismissive of. At best, I think that this introduces some new ways of thinking about who resolves requests that need some care. From nobody Mon Jun 19 10:43:03 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAEB7131724 for ; Mon, 19 Jun 2017 10:43:01 -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 NkFvm9OP5rlk for ; Mon, 19 Jun 2017 10:42:59 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4807131734 for ; Mon, 19 Jun 2017 10:42:48 -0700 (PDT) Received: (qmail 23164 invoked from network); 19 Jun 2017 17:42:47 -0000 Received: from unknown (64.57.183.18) by mail1.iecc.com with QMQP; 19 Jun 2017 17:42:47 -0000 Date: 19 Jun 2017 17:42:25 -0000 Message-ID: <20170619174225.10412.qmail@ary.lan> From: "John Levine" To: dispatch@ietf.org Organization: X-Headerized: yes Mime-Version: 1.0 Content-type: text/plain; charset=utf-8 Content-transfer-encoding: 8bit Archived-At: Subject: [dispatch] FYI draft-levine-mailbomb-header-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 17:43:02 -0000 This draft came out of a discussion last week at M3AAWG. The issue is that bad guys (or more likely bad bots) fill out web forms and include fake mail addresses, the forms provoke confirmation mail which then mailbombs the address(es). This draft adds a new header to indicate that a message is in response to a form submission: Form-Sub: v=1; ip4=198.51.x.x The IP address is that of the web client, which may be partly redacted with "x" for privacy reasons. If a recipient mail system sees too many of them, it may block the system that's sending them. The draft also asks for an enhanced status code which means we rejected this message because it's part of a flood with Form-Sub headers. When we had the discussion there were people from at least two large consumer mail systems and a dozen hosters and (sending) mail service providers in the room, so it is likely this will be implemented enough to see if it's useful. At this point the main point of writing the draft was to have a reference so I could ask IANA to register the header and status code. If it does turn out to be useful I'll come back and ask for it to be dispatched into a standards track document. R's, John From nobody Mon Jun 19 15:02:43 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CE7129503 for ; Mon, 19 Jun 2017 15:02:42 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVSic5T8_i7A for ; Mon, 19 Jun 2017 15:02:39 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65E321294F5 for ; Mon, 19 Jun 2017 15:02:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 0FDE7BE53; Mon, 19 Jun 2017 23:02:37 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXjWX8BXjW1D; Mon, 19 Jun 2017 23:02:32 +0100 (IST) Received: from [10.244.2.100] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 94BEDBE50; Mon, 19 Jun 2017 23:02:31 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1497909752; bh=fr7SvksU6aPE5Oj/zUNfmFpg3ta65UftcKd4szvC0KE=; h=Subject:To:References:From:Date:In-Reply-To:From; b=l8CJUQ/SdOPBUg6hp5ML8/eVqhi4S2l4Nd1LEoakEQK9K4ldVQD7/wxIWCn5twqIm smbB9YOAvh46NIScS/Q/1CWCyKWtHvfgSG0kHoj2bKowPUup2tiHl7SsIZrxl8PMGz tlBY41UY3LtgTiruYB6tUEMtlwDL7hz2sbESP8Fo= To: John Levine , dispatch@ietf.org References: <20170619174225.10412.qmail@ary.lan> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Mon, 19 Jun 2017 23:02:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170619174225.10412.qmail@ary.lan> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="kSvJw0nXBBhc4EqQr3xxK8NRXimRmdeqR" Archived-At: Subject: Re: [dispatch] FYI draft-levine-mailbomb-header-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 22:02:42 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --kSvJw0nXBBhc4EqQr3xxK8NRXimRmdeqR Content-Type: multipart/mixed; boundary="xgCDE5xqc4MMo9CTgBTLdalemUi4DthsS"; protected-headers="v1" From: Stephen Farrell To: John Levine , dispatch@ietf.org Message-ID: Subject: Re: [dispatch] FYI draft-levine-mailbomb-header-00 References: <20170619174225.10412.qmail@ary.lan> In-Reply-To: <20170619174225.10412.qmail@ary.lan> --xgCDE5xqc4MMo9CTgBTLdalemUi4DthsS Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable On 19/06/17 18:42, John Levine wrote: > This draft came out of a discussion last week at M3AAWG. The issue is > that bad guys (or more likely bad bots) fill out web forms and include > fake mail addresses, the forms provoke confirmation mail which then > mailbombs the address(es). >=20 > This draft adds a new header to indicate that a message is in response > to a form submission: >=20 > Form-Sub: v=3D1; ip4=3D198.51.x.x Why not some hashed form of the address? I'd assume a bad bot will generate a load of subscribes per IP address, so a (maybe keyed) has of the full address might be better than the /16 or whatever. And if you only had hashes then it's harder to accidentally be privacy invasive. S. >=20 > The IP address is that of the web client, which may be partly redacted > with "x" for privacy reasons. If a recipient mail system sees too > many of them, it may block the system that's sending them. The draft > also asks for an enhanced status code which means we rejected this > message because it's part of a flood with Form-Sub headers. >=20 > When we had the discussion there were people from at least two large > consumer mail systems and a dozen hosters and (sending) mail service > providers in the room, so it is likely this will be implemented > enough to see if it's useful. >=20 > At this point the main point of writing the draft was to have a > reference so I could ask IANA to register the header and status code. > If it does turn out to be useful I'll come back and ask for it to be > dispatched into a standards track document. >=20 > R's, > John >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch >=20 --xgCDE5xqc4MMo9CTgBTLdalemUi4DthsS-- --kSvJw0nXBBhc4EqQr3xxK8NRXimRmdeqR Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZSEn0AAoJEC88hzaAX42i3FkH/RLF1VIsDX6bTGwT7LhiKReG Pro88mapl4dudcoKdw1bRWRJQ2klAilPDYFzMwsfZhmO1NOnzT3PhAzdAms9wUvc gZXpD3YmHzsWlN9w2meXbt77Nxo+JX/TFmPebuUz+ljh3SVw7mPMsQE3eI591t1n 2PK4kh0PuFU97/PUeCUHd+Db+eEMeE94iN1eQpB3GOmR9tCD77bWWqQ6XRbSLEFf Ej6A/sotQnC8ZbW9n/jm7zfmSb5w3nAWeLvj9WrM9Nei9vt9dqquDkXF33n/iKxM 1a87hArnLuJeW2BxInd73ahuqyxb5Tz+h1WYlHUjbWkgjxePHRL/xtjD+jcjNxI= =13VY -----END PGP SIGNATURE----- --kSvJw0nXBBhc4EqQr3xxK8NRXimRmdeqR-- From nobody Mon Jun 19 15:12:22 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0F581315DC for ; Mon, 19 Jun 2017 15:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.79 X-Spam-Level: X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=UuqjwU67; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=rEjxen20 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFuNR7bX5-_M for ; Mon, 19 Jun 2017 15:12:18 -0700 (PDT) Received: from miucha.iecc.com (w6.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D785129329 for ; Mon, 19 Jun 2017 15:12:04 -0700 (PDT) Received: (qmail 65967 invoked from network); 19 Jun 2017 22:12:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=101ad.59484c32.k1705; bh=0YGoz5dwvL0cJA1K90ehAW9WsCKGSMOD4QS+BctgZJ4=; b=UuqjwU67OOjvz4v4mJddOwYbR/d+DSXHPTpSfRtcOS1f4Te3JEXiwMeHeb5DZfT+VkvCnHWLYFbKJyuaZplSsGnkORiYyKogezmjpq1UoAQfZXnGcc6WmjWyJ+EJVvyW4JdqqCx6JI8B5rRlItYqLI1IcO4LRSNsA1qqq8Ivzc+qEdnHE9B6xoAdbSh4UWEAEy+c3tiUlf8zEeuzockixWGmbeYdK8caIT5xCUNMXhb2uv8vMbC6eyVsItpyHjVO DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=101ad.59484c32.k1705; bh=0YGoz5dwvL0cJA1K90ehAW9WsCKGSMOD4QS+BctgZJ4=; b=rEjxen20FVqFl0852KQGAvGOQQXJ9l5YEUJxu2oZ3ireZAFzsLhLXqo3S+GDUN52BvOW3niapV5tjHbiyct6SfWxYXiez0mYbhsvXPSW7C+dtMlk2y6jNrZtabnKt1qxTno4B0r2vhu7YQDx9dXH9Xz60IX5SMl/cU+cAlhviLC68Ukhla0uMrW9A7YV+nc4kUJFUUavOjqutqFAVSYUOCP4UUL3xngIJ/XQM3kl2j0ieE4EWjHnM/CDD7/101ff Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 19 Jun 2017 22:12:02 -0000 Date: 19 Jun 2017 18:12:02 -0400 Message-ID: From: "John R Levine" To: "Stephen Farrell" Cc: "Dispatch WG" In-Reply-To: References: <20170619174225.10412.qmail@ary.lan> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dispatch] FYI draft-levine-mailbomb-header-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 22:12:20 -0000 On Mon, 19 Jun 2017, Stephen Farrell wrote: >> to a form submission: >> >> Form-Sub: v=1; ip4=198.51.x.x > > Why not some hashed form of the address? As Richard Clayton pointed out, it is trivial to reverse unsalted IPv4 hashes with rainbow tables (and not all that hard to do salted hashes), and you can't use hashes with different salts to see if it's the same guilty party. I added a sentence about that to -01. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly From nobody Tue Jun 20 00:00:34 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CEA5128D69 for ; Tue, 20 Jun 2017 00:00:33 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yh67LZuPblZZ for ; Tue, 20 Jun 2017 00:00:30 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 565A9127419 for ; Tue, 20 Jun 2017 00:00:07 -0700 (PDT) Received: by mail-oi0-x236.google.com with SMTP id c189so44092009oia.2 for ; Tue, 20 Jun 2017 00:00:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EDuPJ3AbtjSZkI/poBRx38Htdu/69fD5nTVqFwUhDeA=; b=dyYYrNbW2A7Sp5KjXD5gUkgHnjz2Ef4vjhgtdXeCOmXtfuio38/onegpR9xO+3uHns jvH0xe4S71aA+2F7dH3pyheQgfugTf1ymxjl9NiEdD2vgxxAdz/Zx6fwyr1ZWskaXZ1/ mn20Q4RHmXOjO0SxrY5nQgI08C3+fWlfc+9VSKLfLjCu3TFffrZ9QcPXW59ZDpZlwCQz Xj8JbCP0YecDVHPotwHQiIHS5fCKiCc928EGaGeSJSzQOJRH7ayLYMXyKN27JMcDkiab Fw8i0N5lnBIRnBZcIhX3zhxVIr8u57v7+Ii7JzqmrLCC6yoXF7eEbA2B94p3oKrG9tl0 umwQ== 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=EDuPJ3AbtjSZkI/poBRx38Htdu/69fD5nTVqFwUhDeA=; b=UlCpGrvL+CmISNaJ6lUgO0NVGmE0ejfo/6C1VQCjJRyS0abvr7Jth8HKH+kiGObSUF I2Zq3Injhqvue1LL41abXIpO3l+vugZ5/FZX6gNTmMwvWZ1w12ovOTUPee2kLoRTqvr5 iSIrVORPU4Q9QF6uOHtQXImhI1ulLhnLlW2LT9hNva6ptJr4380O/bZVJPpt+DN33duh nIpPUUZiuvmH3HN+5p3YkBqgONhzsQrAMb6tY8qv/hHSBI80BGRUTvUFisPHBU3wxDBO gG3CxiBEYxMCRDpj/KqTSVE9ieol2ry4lWab0eqwIqwjb6db8SVPKmTCfRakkZqb6fZA cCrg== X-Gm-Message-State: AKS2vOxo2L+08P+xX5zYIuCBkwsxTaeEjlhwCT51fE99NkRdFkvo6zg/ 0ktdYKKWx++yuQ7bGnLvkWrBapgKWwZ9roE= X-Received: by 10.202.72.20 with SMTP id v20mr15215260oia.44.1497942006250; Tue, 20 Jun 2017 00:00:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.68.42 with HTTP; Tue, 20 Jun 2017 00:00:05 -0700 (PDT) Received: by 10.182.68.42 with HTTP; Tue, 20 Jun 2017 00:00:05 -0700 (PDT) In-Reply-To: References: <20170619174225.10412.qmail@ary.lan> From: Brandon Long Date: Tue, 20 Jun 2017 00:00:05 -0700 Message-ID: To: John Levine Cc: Dispatch WG , Stephen Farrell Content-Type: multipart/alternative; boundary="001a11c17cda2dad7705525ecd29" Archived-At: Subject: Re: [dispatch] FYI draft-levine-mailbomb-header-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 07:00:33 -0000 --001a11c17cda2dad7705525ecd29 Content-Type: text/plain; charset="UTF-8" So, we think these form providers are more likely to do this than actually protect their forms from abuse by bots? This seems like putting the onus on receivers to work around the junk they're putting out. I'd be tempted to put on a BOFH hat and use a couple mailbombs to create a blacklist and never accept mail from them again. Hmm, maybe I could pay one of these mailbomb services to mailbomb a couple honeypots. Though, if they include this header, it's also easy to drop them all, I guess. Perhaps a bit hyperbolic, ok. Brandon On Jun 19, 2017 3:12 PM, "John R Levine" wrote: On Mon, 19 Jun 2017, Stephen Farrell wrote: > to a form submission: >> >> Form-Sub: v=1; ip4=198.51.x.x >> > > Why not some hashed form of the address? > As Richard Clayton pointed out, it is trivial to reverse unsalted IPv4 hashes with rainbow tables (and not all that hard to do salted hashes), and you can't use hashes with different salts to see if it's the same guilty party. I added a sentence about that to -01. Regards, John Levine, johnl@taugh.com, Taughannock Networks, Trumansburg NY Please consider the environment before reading this e-mail. https://jl.ly _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --001a11c17cda2dad7705525ecd29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
So, we think these form providers are more likely to= do this than actually protect their forms from abuse by bots?

This seems like putting the onus on receiv= ers to work around the junk they're putting out.

I'd be tempted to put on a BOFH hat and us= e a couple mailbombs to create a blacklist and never accept mail from them = again.=C2=A0 Hmm, maybe I could pay one of these mailbomb services to mailb= omb a couple honeypots.

= Though, if they include this header, it's also easy to drop them all, I= guess.

Perhaps a bit hy= perbolic, ok.

Brandon

On Jun 19,= 2017 3:12 PM, "John R Levine" <johnl@taugh.com> wrote:
On Mon, 19 Jun 2017, Stephen Farrell w= rote:
to a form submission:

=C2=A0Form-Sub: v=3D1; ip4=3D198.51.x.x

Why not some hashed form of the address?

As Richard Clayton pointed out, it is trivial to reverse unsalted IPv4 hash= es with rainbow tables (and not all that hard to do salted hashes), and you= can't use hashes with different salts to see if it's the same guil= ty party.=C2=A0 I added a sentence about that to -01.

Regards,
John Levine, johnl@tau= gh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly


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

--001a11c17cda2dad7705525ecd29-- From nobody Tue Jun 20 11:22:06 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38CB51315CE for ; Tue, 20 Jun 2017 11:22:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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 8wpcGrMy04oI for ; Tue, 20 Jun 2017 11:22:00 -0700 (PDT) Received: from smtp80.iad3a.emailsrvr.com (smtp80.iad3a.emailsrvr.com [173.203.187.80]) (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 0B4591315C6 for ; Tue, 20 Jun 2017 11:22:00 -0700 (PDT) Received: from smtp19.relay.iad3a.emailsrvr.com (localhost [127.0.0.1]) by smtp19.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 3C6CF515F; Tue, 20 Jun 2017 14:21:59 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp19.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id D665550B9; Tue, 20 Jun 2017 14:21:58 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [10.1.3.55] (d172-219-247-164.abhsia.telus.net [172.219.247.164]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:587 (trex/5.7.12); Tue, 20 Jun 2017 14:21:59 -0400 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Cullen Jennings In-Reply-To: <20170619174225.10412.qmail@ary.lan> Date: Tue, 20 Jun 2017 12:21:57 -0600 Cc: dispatch@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <33E62B35-8048-4EBA-A5D8-409564D5B667@iii.ca> References: <20170619174225.10412.qmail@ary.lan> To: John Levine X-Mailer: Apple Mail (2.3259) Archived-At: Subject: Re: [dispatch] FYI draft-levine-mailbomb-header-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 18:22:03 -0000 For v6, how much would typically be redacted ? > On Jun 19, 2017, at 11:42 AM, John Levine wrote: > > This draft came out of a discussion last week at M3AAWG. The issue is > that bad guys (or more likely bad bots) fill out web forms and include > fake mail addresses, the forms provoke confirmation mail which then > mailbombs the address(es). > > This draft adds a new header to indicate that a message is in response > to a form submission: > > Form-Sub: v=1; ip4=198.51.x.x > > The IP address is that of the web client, which may be partly redacted > with "x" for privacy reasons. If a recipient mail system sees too > many of them, it may block the system that's sending them. The draft > also asks for an enhanced status code which means we rejected this > message because it's part of a flood with Form-Sub headers. > > When we had the discussion there were people from at least two large > consumer mail systems and a dozen hosters and (sending) mail service > providers in the room, so it is likely this will be implemented > enough to see if it's useful. > > At this point the main point of writing the draft was to have a > reference so I could ask IANA to register the header and status code. > If it does turn out to be useful I'll come back and ask for it to be > dispatched into a standards track document. > > R's, > John > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Jun 20 11:27:09 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EEB71315D8 for ; Tue, 20 Jun 2017 11:27:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=iecc.com header.b=bNCAZsYi; dkim=neutral reason="invalid (public key: not available)" header.d=taugh.com header.b=aUIYVdb1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWpAn-SLEH4n for ; Tue, 20 Jun 2017 11:27:05 -0700 (PDT) Received: from miucha.iecc.com (www.iecc.com [IPv6:2001:470:1f07:1126::4945:4343]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F15C13154A for ; Tue, 20 Jun 2017 11:27:03 -0700 (PDT) Received: (qmail 41530 invoked from network); 20 Jun 2017 18:27:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=iecc.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a238.594968f6.k1705; bh=/YGTvRu1lg7fwbx04Q+ZTCwdoiSxygnsO0RkYvkXDi8=; b=bNCAZsYi4Aq43Kg1L1SIKMCkv+m704R1/sx2uZEPPjS6Q9ZzWvoi/99dxESM1Tln5uk0Kf3z4rU96N4Vy5mBp8XtZo6eoA89a5We4FE55KYMwO0ExDq9ZPzVYvaAsA1YaHAIEIhICsQWoSLvA9lzjL6hKKuV+dlxGUexaPlxUIL1uP6B4eG3iMOu5LpG+P3tfXFfAtFsndxZaR5wzP/RmbZP3uwtnUBpqx0RUqQ14gSSitpqhpAaGAxXxEmQoZA2 DKIM-Signature: v=1; a=rsa-sha256; c=simple; d=taugh.com; h=date:message-id:from:to:cc:subject:in-reply-to:references:mime-version:content-type:user-agent; s=a238.594968f6.k1705; bh=/YGTvRu1lg7fwbx04Q+ZTCwdoiSxygnsO0RkYvkXDi8=; b=aUIYVdb1SkZPExq6e/E2AK1hx/Ni5rR3M5J2MKJjAUG24ToAgHv23GEdQtC5o+hoglgRO7+IYrCcPxqlkeoLU5cbqNYvw5PoIk5kiymfT9LLZ868PCLeNEcU6QBLhjRUELEzEt7XcSttDrIoxovJvc79Ve9cccIG7hjn77AgxjPfAmAoll9vkpzorYNrPmsRp0FeyqmIUq+YKZP4Lu/BcXPwDBWc7rz3NVimRvV8hGHRX8EsPwd3v6hFWCx3IL9B Received: from localhost ([IPv6:2001:470:1f07:1126::78:696d:6170]) by imap.iecc.com ([IPv6:2001:470:1f07:1126::78:696d:6170]) with ESMTPS (TLS1.2/X.509/AEAD) via TCP6; 20 Jun 2017 18:27:01 -0000 Date: 20 Jun 2017 14:27:01 -0400 Message-ID: From: "John R Levine" To: "Cullen Jennings" Cc: "Dispatch WG" In-Reply-To: <33E62B35-8048-4EBA-A5D8-409564D5B667@iii.ca> References: <20170619174225.10412.qmail@ary.lan> <33E62B35-8048-4EBA-A5D8-409564D5B667@iii.ca> User-Agent: Alpine 2.21 (OSX 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [dispatch] FYI draft-levine-mailbomb-header-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jun 2017 18:27:07 -0000 > For v6, how much would typically be redacted ? I get the impression it'd usually either be the high half or the low half. We worked this out with some German ISPs who had strong opinions about what they would be allowed to include. Keep in mind that the alternative to a redacted IP is not a full IP, it's no IP at all. R's, John >> On Jun 19, 2017, at 11:42 AM, John Levine wrote: >> >> This draft came out of a discussion last week at M3AAWG. The issue is >> that bad guys (or more likely bad bots) fill out web forms and include >> fake mail addresses, the forms provoke confirmation mail which then >> mailbombs the address(es). >> >> This draft adds a new header to indicate that a message is in response >> to a form submission: >> >> Form-Sub: v=1; ip4=198.51.x.x >> >> The IP address is that of the web client, which may be partly redacted >> with "x" for privacy reasons. If a recipient mail system sees too >> many of them, it may block the system that's sending them. The draft >> also asks for an enhanced status code which means we rejected this >> message because it's part of a flood with Form-Sub headers. >> >> When we had the discussion there were people from at least two large >> consumer mail systems and a dozen hosters and (sending) mail service >> providers in the room, so it is likely this will be implemented >> enough to see if it's useful. >> >> At this point the main point of writing the draft was to have a >> reference so I could ask IANA to register the header and status code. >> If it does turn out to be useful I'll come back and ask for it to be >> dispatched into a standards track document. From nobody Wed Jun 21 08:50:25 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7F512EB72; Wed, 21 Jun 2017 08:49:58 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 n8o5ij8YUQhH; Wed, 21 Jun 2017 08:49:57 -0700 (PDT) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 04A4912EB71; Wed, 21 Jun 2017 08:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1498060121; d=isode.com; s=june2016; i=@isode.com; bh=EQRj0u9RvCLnA3702jqWQWFCWk5HNTx2YMVwA6PWyNw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=f9rI+UFg8rZhQyA5VEmmh/G49ngA0P14sKQHJOaZuD6sZH1tfgCJE12CJKkgAltmE+nmdM s2IZ5yD3R5gUixL/6qJgGjRgZgOAFYryKqcqwl0qfz1bmcD6BItXkNT8Khdg+wncNt0qjb jbzRlqNZ8flFVtUWlKyBBisaqvP7qw0=; Received: from [192.168.0.3] (cpc121086-nmal24-2-0-cust54.19-2.cable.virginm.net [77.97.145.55]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 21 Jun 2017 16:48:41 +0100 From: Alexey Melnikov To: dispatch@ietf.org, "hybi@ietf.org" Message-ID: <594A9557.9080707@isode.com> Date: Wed, 21 Jun 2017 16:48:39 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Jun 2017 15:49:59 -0000 Hi, RFC 5785 defined a path prefix, "/.well-known/", that can be used by well-known URIs, specifically for the "http" and "https" URI schemes. Other URI schemes like "coap" also opted-in into using .well-known. RFC 6455 defined WebSocket protocol and "ws"/"wss" URI schemes. It hasn't however opted-in into using the .well-known registry defined by RFC 5785. draft-bormann-hybi-ws-wk-00 is fixing this deficiency. I am going to start IETF LC on this document. Please send your comments to ietf@ietf.org mailing list or reply to this email. Thank you, Alexey From nobody Thu Jun 22 09:29:22 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33B46129AEA; Thu, 22 Jun 2017 09:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=annevk.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lb09w-o9k-ED; Thu, 22 Jun 2017 09:29:10 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F761129AE7; Thu, 22 Jun 2017 09:29:09 -0700 (PDT) Received: from homiemail-a14.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTP id 6B42339207F; Thu, 22 Jun 2017 09:29:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=annevk.nl; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc: content-type; s=annevk.nl; bh=METoWYvKO85ms7Deb3JFmGd8WDs=; b=Q0 ykebSE9QyJpC9HKGrVMF1GCs9d2HmJGzwDmFvLFeW7OMcVn47UtCpa1YMu8X7acz sTphgKeFmksL/9yrTQA3Q80qIdsWi073nKz2XnvOwXRdJkExSeubsXce1C7/v/Qc D9uOLBcnzGPS8d4xev31sMByEglQxYJaFjI5jXkbE= Received: from mail-yb0-f174.google.com (mail-yb0-f174.google.com [209.85.213.174]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: annevk@annevk.nl) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTPSA id 4AE02392075; Thu, 22 Jun 2017 09:29:09 -0700 (PDT) Received: by mail-yb0-f174.google.com with SMTP id f192so6257467yba.2; Thu, 22 Jun 2017 09:29:09 -0700 (PDT) X-Gm-Message-State: AKS2vOyUgY4howhlj5mOgfOXZZhyZQAlbYTrU1ZRn2DSLXDFaTaemcxc ORZr/okEupr3KghSQnYQbCX2N5ywDg== X-Received: by 10.37.175.17 with SMTP id a17mr2493729ybh.9.1498148948568; Thu, 22 Jun 2017 09:29:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.216.81 with HTTP; Thu, 22 Jun 2017 09:29:08 -0700 (PDT) In-Reply-To: <594A9557.9080707@isode.com> References: <594A9557.9080707@isode.com> From: Anne van Kesteren Date: Thu, 22 Jun 2017 18:29:08 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Alexey Melnikov Cc: dispatch@ietf.org, "hybi@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dispatch] [hybi] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 16:29:15 -0000 On Wed, Jun 21, 2017 at 5:48 PM, Alexey Melnikov wrote: > RFC 5785 defined a path prefix, "/.well-known/", that can be used by > well-known URIs, specifically for the "http" and "https" URI schemes. > Other URI schemes like "coap" also opted-in into using .well-known. > > RFC 6455 defined WebSocket protocol and "ws"/"wss" URI schemes. It > hasn't however opted-in into using the .well-known registry defined by > RFC 5785. draft-bormann-hybi-ws-wk-00 is fixing this deficiency. In practice (and in the specification that supersedes parts of the RFC) the scheme in use is already http/https: https://fetch.spec.whatwg.org/#websocket-protocol -- https://annevankesteren.nl/ From nobody Thu Jun 22 09:33:56 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDE8112945A; Thu, 22 Jun 2017 09:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=messagingengine.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 wWcLM1wCN8vm; Thu, 22 Jun 2017 09:33:49 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A39D1270A3; Thu, 22 Jun 2017 09:33:49 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A6DF620B78; Thu, 22 Jun 2017 12:33:48 -0400 (EDT) Received: from web5 ([10.202.2.215]) by compute3.internal (MEProxy); Thu, 22 Jun 2017 12:33:48 -0400 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=fm1; bh=BNtUoP xhhffV+JCfTiT0T0jj9UpbRHFijM8CF6jPyVs=; b=m8GCcwkis5y3kmjjjrGHfa RCLqJfU0iXKQcDybQ8IoWgPu9dBE5t6dfi7gyyO7DnjGQndnWradI9k4oTMup/8s P7sF5Wo/1o5hBPEoOIyxd/lg6FuPW9/fvI7Ea+u0xrowO+kRKGDm5wKZkyp0Q8wE PU4LUNDhES0xuNo991Ej01uL6xHsOUF4oFsCRGDtVeEd7ISuSBsE+5RLTBHdBgCo E8gd/f7STr6JUMRCRu4HeoptbCb5gCM1Tayd8z767zJyZVuyTeKLMfY6IqF0lo+j 7QCVG7SiZk7CZshTgHAv2V2Fv4CRqpsakXHIzk3/G0C9FK7Kjx0jjKosbjIwopCA == X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id 87F2A9E23D; Thu, 22 Jun 2017 12:33:48 -0400 (EDT) Message-Id: <1498149228.3653703.1018087584.5D4E9087@webmail.messagingengine.com> From: Alexey Melnikov To: Anne van Kesteren Cc: hybi@ietf.org, dispatch@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-72841c42 In-Reply-To: References: <594A9557.9080707@isode.com> Date: Thu, 22 Jun 2017 17:33:48 +0100 Archived-At: Subject: Re: [dispatch] [hybi] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 16:33:51 -0000 On Thu, Jun 22, 2017, at 05:29 PM, Anne van Kesteren wrote: > On Wed, Jun 21, 2017 at 5:48 PM, Alexey Melnikov > wrote: > > RFC 5785 defined a path prefix, "/.well-known/", that can be used by > > well-known URIs, specifically for the "http" and "https" URI schemes. > > Other URI schemes like "coap" also opted-in into using .well-known. > > > > RFC 6455 defined WebSocket protocol and "ws"/"wss" URI schemes. It > > hasn't however opted-in into using the .well-known registry defined by > > RFC 5785. draft-bormann-hybi-ws-wk-00 is fixing this deficiency. > > In practice (and in the specification that supersedes parts of the > RFC) the scheme in use is already http/https: > > https://fetch.spec.whatwg.org/#websocket-protocol I think this is an orthogonal thing, as ws/wss URI schemes are also used in not HTTP contexts. So basically draft-bormann-hybi-ws-wk-00 doesn't affect Fetch. From nobody Thu Jun 22 11:13:15 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B164C129418; Thu, 22 Jun 2017 11:13:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.52 X-Spam-Level: X-Spam-Status: No, score=-1.52 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=annevk.nl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcOGONNeRNqH; Thu, 22 Jun 2017 11:13:12 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (homie.mail.dreamhost.com [208.97.132.208]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CF9C1201FA; Thu, 22 Jun 2017 11:13:12 -0700 (PDT) Received: from homiemail-a38.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTP id 1243A10AFBD; Thu, 22 Jun 2017 11:13:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=annevk.nl; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc: content-type; s=annevk.nl; bh=LISz2mtFY1hVfCrb4VfWZgsFbKQ=; b=Ie kg7sFEBdr2i7hnLK1GRQnFT6mcoJko/NesZSq00M6LEAxcqGZv8CWk0FY4TWAGE1 Iz+yZp5waEWyDfTL12RL3b6oXpsxsyzCE6YLwCbXSEYGA6RmroPmRBRtXQwh/IS5 r+7QyDVG7EHJ0+s0NauWs8PabAUwEIkR4ozxGqFmA= Received: from mail-yw0-f176.google.com (mail-yw0-f176.google.com [209.85.161.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: annevk@annevk.nl) by homiemail-a38.g.dreamhost.com (Postfix) with ESMTPSA id D9D8510AFB8; Thu, 22 Jun 2017 11:13:11 -0700 (PDT) Received: by mail-yw0-f176.google.com with SMTP id l75so9020857ywc.3; Thu, 22 Jun 2017 11:13:11 -0700 (PDT) X-Gm-Message-State: AKS2vOzMvteCx+8qDyUBx/40yEpNueFlwY5NBxto2RDvJRH5Cwwlzt69 jHm1tHfJX9CRMmhh0j/B6uXO2eMczA== X-Received: by 10.129.128.132 with SMTP id q126mr2834236ywf.259.1498155190704; Thu, 22 Jun 2017 11:13:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.216.81 with HTTP; Thu, 22 Jun 2017 11:13:10 -0700 (PDT) In-Reply-To: <1498149228.3653703.1018087584.5D4E9087@webmail.messagingengine.com> References: <594A9557.9080707@isode.com> <1498149228.3653703.1018087584.5D4E9087@webmail.messagingengine.com> From: Anne van Kesteren Date: Thu, 22 Jun 2017 20:13:10 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Alexey Melnikov Cc: "hybi@ietf.org" , dispatch@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dispatch] [hybi] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jun 2017 18:13:14 -0000 On Thu, Jun 22, 2017 at 6:33 PM, Alexey Melnikov wrote: > On Thu, Jun 22, 2017, at 05:29 PM, Anne van Kesteren wrote: >> On Wed, Jun 21, 2017 at 5:48 PM, Alexey Melnikov >> wrote: >> > RFC 5785 defined a path prefix, "/.well-known/", that can be used by >> > well-known URIs, specifically for the "http" and "https" URI schemes. >> > Other URI schemes like "coap" also opted-in into using .well-known. >> > >> > RFC 6455 defined WebSocket protocol and "ws"/"wss" URI schemes. It >> > hasn't however opted-in into using the .well-known registry defined by >> > RFC 5785. draft-bormann-hybi-ws-wk-00 is fixing this deficiency. >> >> In practice (and in the specification that supersedes parts of the >> RFC) the scheme in use is already http/https: >> >> https://fetch.spec.whatwg.org/#websocket-protocol > > I think this is an orthogonal thing, as ws/wss URI schemes are also used > in not HTTP contexts. So basically draft-bormann-hybi-ws-wk-00 doesn't > affect Fetch. The /.well-known/ thing only makes sense with respect to the WebSocket handshake, no? And that's already defined to be an HTTP request. So I'm not sure why any /.well-known/ things with regard to HTTP would not already apply. (One of the reasons Fetch made this change/clarification is to make sure HSTS, CSP, etc. would all apply to WebSocket as well.) -- https://annevankesteren.nl/ From nobody Fri Jun 23 03:35:19 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122E2128D40 for ; Fri, 23 Jun 2017 03:35:18 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mlq974hYQ_wO for ; Fri, 23 Jun 2017 03:35:16 -0700 (PDT) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 838781274D0 for ; Fri, 23 Jun 2017 03:35:15 -0700 (PDT) Received: by mail-wr0-x232.google.com with SMTP id 77so59778100wrb.1 for ; Fri, 23 Jun 2017 03:35:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eANuT5PwY6b1sXp9p1mqXRdIDkgWa91Q6z53UN3EK1Q=; b=VyG7EBCNdLi7HFAHa9p2N9t14g8opLAeJ2lmWkfMTHCpM3gS4m8UzktBmc9Dy6aRV8 gXMc0dneduLXYmVOBboGkFW0Ph7ZM/du9PlbcFrDz5FTY0ArzQT3avIB32eBruxmQM9K aQOfqn2JrKTiNzCav7NwwhurSZNiz2FgeFsFD0AsAJEFQVW0yCrjAnbMq2hLzb4aLuDe 0c4Ds7AH3hLN93vyRI5uXtcuucoL9h90q9vuwCNGPTaYTr+hZbZdmfw+k9AT73TjuIgq 6ue/+J9RMW37igQ4eRKFAMCUx3isCBYX8Y61BELmthi/nQ44o2Uag8IjkRluOSHscs36 nGlQ== 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=eANuT5PwY6b1sXp9p1mqXRdIDkgWa91Q6z53UN3EK1Q=; b=S62OAXUBGRAZoghtJEwcz+3ToVRlV46wxywxhu/jBgDH3Gjbtgf8y7Ya+fbS/+Bnon nArQS5DlrifkiZaqhhr7iI5KgSmx0i/DmbhEN/aXfCiqAmvVb1FLZ/PrIiFCwqvnliem UinsTZVZS1zbVRktLS9UQsD7lc74yxTR41MoXgdQp6foZs1e/rjyqYt5lLScMkA2BiRw JsCyKRKHTHbtqdl3hnnECKJTTlfkVZLiLyJ3l/PFMXKsXu4u3JspulmcvoA5D9SkWX1o boaJvPZuN/PW4qTHQTOQJMRkjluLKSnt2ogtx1iXvYvW3ND5qxk7xsUydb4c+6SdBClN EfPw== X-Gm-Message-State: AKS2vOxbxUebyksU0qmk1Ch1IWTUfrlydEY7C9Tkb/P/ZcXPjFTt2T5x jbjGCTnZrxJ+a4+y7LyRykXKUSiMPK8HPZE= X-Received: by 10.28.229.6 with SMTP id c6mr4939229wmh.49.1498214113734; Fri, 23 Jun 2017 03:35:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.218.3 with HTTP; Fri, 23 Jun 2017 03:35:12 -0700 (PDT) In-Reply-To: References: <594A9557.9080707@isode.com> <1498149228.3653703.1018087584.5D4E9087@webmail.messagingengine.com> From: Adam Rice Date: Fri, 23 Jun 2017 19:35:12 +0900 Message-ID: To: Anne van Kesteren Cc: Alexey Melnikov , dispatch@ietf.org, "hybi@ietf.org" Content-Type: multipart/alternative; boundary="001a1145b51a0c758205529e281b" Archived-At: Subject: Re: [dispatch] [hybi] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 10:35:18 -0000 --001a1145b51a0c758205529e281b Content-Type: text/plain; charset="UTF-8" On 23 June 2017 at 03:13, Anne van Kesteren wrote: > The /.well-known/ thing only makes sense with respect to the WebSocket > handshake, no? And that's already defined to be an HTTP request. So > I'm not sure why any /.well-known/ things with regard to HTTP would > not already apply. (One of the reasons Fetch made this > change/clarification is to make sure HSTS, CSP, etc. would all apply > to WebSocket as well.) > If understand correctly, this permits a well-known WebSocket endpoint to be registered under /.well-known/, so it's not just about HTTP-compatibility. I don't see any problems with the proposal, as long as it's actually going to be used. Is there a list of expected use-cases somewhere? --001a1145b51a0c758205529e281b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable --001a1145b51a0c758205529e281b-- From nobody Fri Jun 23 03:42:17 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBAD129C07; Fri, 23 Jun 2017 03:42:09 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.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 Npjac0IP0LFK; Fri, 23 Jun 2017 03:42:07 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7BD127180; Fri, 23 Jun 2017 03:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1498214526; d=isode.com; s=june2016; i=@isode.com; bh=vqXr8AEY2IPYaxf0W8a70LQF0htxKbkBr0mg3n6Ksek=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=xNhyUPuptu5SVQqmR9YsTBD0ppRCQtsfrp9ClfIA8c2aHvS2AobDx2h0phSHt9kIxOqoPj GiNRSJQl3qTEn6BM+NpW09vwe0oQzIe8E4yeaLqMfLYFiO4YIrOf/b3jK7bU6EoZRa3MUQ xyJtKPDNHR08dnAcNIMD9SEpqMuG3qE=; Received: from [172.20.1.215] (dhcp-215.isode.net [172.20.1.215]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 23 Jun 2017 11:42:06 +0100 To: Adam Rice , Anne van Kesteren Cc: dispatch@ietf.org, "hybi@ietf.org" References: <594A9557.9080707@isode.com> <1498149228.3653703.1018087584.5D4E9087@webmail.messagingengine.com> From: Alexey Melnikov Message-ID: <6eb360bd-0d5c-4559-85c9-99716cf846ba@isode.com> Date: Fri, 23 Jun 2017 11:41:36 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------35A2D17180D210AF4059E5D9" Content-Language: en-US Archived-At: Subject: Re: [dispatch] [hybi] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 10:42:09 -0000 --------------35A2D17180D210AF4059E5D9 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 23/06/2017 11:35, Adam Rice wrote: > On 23 June 2017 at 03:13, Anne van Kesteren > wrote: > > The /.well-known/ thing only makes sense with respect to the WebSocket > handshake, no? And that's already defined to be an HTTP request. So > I'm not sure why any /.well-known/ things with regard to HTTP would > not already apply. (One of the reasons Fetch made this > change/clarification is to make sure HSTS, CSP, etc. would all apply > to WebSocket as well.) > > > If understand correctly, this permits a well-known WebSocket endpoint > to be registered under /.well-known/, so it's not just about > HTTP-compatibility. Right. > > I don't see any problems with the proposal, as long as it's actually > going to be used. Is there a list of expected use-cases somewhere? Sections 7.3 and 7.4 of . --------------35A2D17180D210AF4059E5D9 Content-Type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On 23/06/2017 11:35, Adam Rice wrote:


Right.

I don't see any problems with the proposal, as long as it's actually going to be used. Is there a list of expected use-cases somewhere?
=C2=A0
Sections 7.3 and 7.4 of <https://datatracker.ietf= .org/doc/draft-ietf-core-coap-tcp-tls/?include_text=3D1>.


--------------35A2D17180D210AF4059E5D9-- From nobody Fri Jun 23 04:18:57 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23419129353 for ; Fri, 23 Jun 2017 04:18:50 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGTc4M9dGg25 for ; Fri, 23 Jun 2017 04:18:47 -0700 (PDT) Received: from mail-wr0-x22d.google.com (mail-wr0-x22d.google.com [IPv6:2a00:1450:400c:c0c::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 B08FA127601 for ; Fri, 23 Jun 2017 04:18:46 -0700 (PDT) Received: by mail-wr0-x22d.google.com with SMTP id 77so61310287wrb.1 for ; Fri, 23 Jun 2017 04:18:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9eXKMLaHtify5+wwQiTH/IevKkwsa3yIGSJ0XqDM1CE=; b=J3jD0dNEOHM9YZZRloLhQle/HbOqHYkodXn7wMo9Tspy+sEDb97irFp/OB4PAOE90N woGxnho7yvUKLFPGHX7+OCRH3GcS/o2ipBvazOZmdkOp62hdmvU1KZHQ1hH490v33WbN d94Gs9jkpd7wmpCIdp4863/ioyVoZ2taDgBoDa6zNLIQtDOXCBwlD0sjyZTzkXVXhpAe 9R3jLxufjNSyr/vGP9rhsAPzuSqugTNEbJkHC+pE3f3CEzGCfAIFjY0R9ShgAuUNDmu5 6/FQoFd08nz9q4c5S5eJzqV5HV4pwhrX69s2P0ZxftMncaEDg4nxx83NJvIFagy/pT3N jKdw== 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=9eXKMLaHtify5+wwQiTH/IevKkwsa3yIGSJ0XqDM1CE=; b=bFzppn2xBvMJ7PF4D4uBoilEb2ywainjOHd0Hc1MNUN4HHNsMQXTaasMpBydtHz/ep p7+3IizoUr84Gmk8TnLH58QS5kLLjNkiS7btonbCHedzDANFD5BRWZ22aH3Sdz/101LX oqGk5tjeQvebwoZRTzyjhM8X8plc/Qjrb8dph4h6KBpT/JTOMIy6CY9Rc6AM+LNMmBvp L3WMeMMwX5utfEZ8fY+AsJskhsp9aqPwqU5gU97qAN/bgmCzEBCCQPgk+PoqHFaLXGPi wY3DcV1qS5f5iBPgnRTTsSpzvehCpRrQ+0+GoGbdZp0NAbPLef8Pcxql3eOfE7ojW5/L htlA== X-Gm-Message-State: AKS2vOxnZjDM6PCWfSXVXH1tir/ZSTdesauqcZ8vemeRP5CsAokjwEtV mZutdR1QBiSzD6LjqTKwwHs88UBM/53bp8I= X-Received: by 10.223.135.105 with SMTP id 38mr5097065wrz.23.1498216724846; Fri, 23 Jun 2017 04:18:44 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.218.3 with HTTP; Fri, 23 Jun 2017 04:18:44 -0700 (PDT) In-Reply-To: <6eb360bd-0d5c-4559-85c9-99716cf846ba@isode.com> References: <594A9557.9080707@isode.com> <1498149228.3653703.1018087584.5D4E9087@webmail.messagingengine.com> <6eb360bd-0d5c-4559-85c9-99716cf846ba@isode.com> From: Adam Rice Date: Fri, 23 Jun 2017 20:18:44 +0900 Message-ID: To: Alexey Melnikov Cc: Anne van Kesteren , dispatch@ietf.org, "hybi@ietf.org" Content-Type: multipart/alternative; boundary="001a1147fd6eaea7dd05529ec315" Archived-At: Subject: Re: [dispatch] [hybi] Publication request for draft-bormann-hybi-ws-wk-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jun 2017 11:18:50 -0000 --001a1147fd6eaea7dd05529ec315 Content-Type: text/plain; charset="UTF-8" Ah, I see, it's already planned to be used for coap-over-WebSocket. Sounds good to me. On 23 June 2017 at 19:41, Alexey Melnikov wrote: > On 23/06/2017 11:35, Adam Rice wrote: > > On 23 June 2017 at 03:13, Anne van Kesteren wrote: > >> The /.well-known/ thing only makes sense with respect to the WebSocket >> handshake, no? And that's already defined to be an HTTP request. So >> I'm not sure why any /.well-known/ things with regard to HTTP would >> not already apply. (One of the reasons Fetch made this >> change/clarification is to make sure HSTS, CSP, etc. would all apply >> to WebSocket as well.) >> > > If understand correctly, this permits a well-known WebSocket endpoint to > be registered under /.well-known/, so it's not just about > HTTP-compatibility. > > > Right. > > > I don't see any problems with the proposal, as long as it's actually going > to be used. Is there a list of expected use-cases somewhere? > > > Sections 7.3 and 7.4 of doc/draft-ietf-core-coap-tcp-tls/?include_text=1> > > . > > > --001a1147fd6eaea7dd05529ec315 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah, I see, it's already planned to be used for coap-ov= er-WebSocket. Sounds good to me.

On 23 June 2017 at 19:41, Alexey Melnikov <al= exey.melnikov@isode.com> wrote:
=20 =20 =20

On 23/06/2017 11:35, Adam Rice wrote:

On 23 June 2017 at 03:13, Anne van Kesteren <annevk@annevk.= nl> wrote:
The /.well-known/ thing only makes sense with respect to the WebSocket
handshake, no? And that's already defined to be an HTTP request. So
I'm not sure why any /.well-known/ things with regard to HTTP would
not already apply. (One of the reasons Fetch made this
change/clarification is to make sure HSTS, CSP, etc. would all apply
to WebSocket as well.)

If understand correctly, this permits a well-known WebSocket endpoint to be registered under /.well-known/, so it's not just about HTTP-compatibility.

 Right.

I don't see any problems with the proposal, as long as it's actually going to be used. Is there a list of expected use-cases somewhere?
=C2=A0
 Sections 7.3 and 7.4 of <https://datatracker.ietf.org/doc/draft-ietf-core-coa= p-tcp-tls/?include_text=3D1>.



--001a1147fd6eaea7dd05529ec315-- From nobody Fri Jun 23 17:12:48 2017 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id BE7C8129B5E; Fri, 23 Jun 2017 17:07:07 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: ben@nostrum.com, dispatch@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826282777.7840.14633203276856915898.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:07 -0700 Archived-At: Subject: [dispatch] dispatch - Requested session has been scheduled for IETF 99 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:10 -0000 Dear Alexey Melnikov, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dispatch Session 1 (1:30:00) Monday, Morning Session I 0930-1200 Room Name: Congress Hall III size: 250 --------------------------------------------- Special Note: 09:30-11:30 Request Information: --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Alexey Melnikov Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: dmarc uta jmap xrblock webpush stir sipcore rtcweb rmcat payload netvc mmusic insipid ecrit avtcore avtext bfcpbis clue core dcrup Second Priority: tram tsvwg tsvarea opsarea lmap People who must be present: Alexey Melnikov Mary Barnes Adam Roach Ben Campbell Cullen Jennings Murray Kucherawy Resources Requested: Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs. --------------------------------------------------------- From nobody Mon Jun 26 19:38:27 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BAD8127A91 for ; Mon, 26 Jun 2017 19:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6_BpIQ6HkMZj for ; Mon, 26 Jun 2017 19:38:24 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA86F1286D6 for ; Mon, 26 Jun 2017 19:38:23 -0700 (PDT) Received: from [169.254.238.53] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v5R2bgww017897 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Mon, 26 Jun 2017 19:37:43 -0700 (MST) (envelope-from paul.hoffman@icann.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.238.53] From: "Paul Hoffman" To: "dispatch@ietf.org" Date: Mon, 26 Jun 2017 19:38:21 -0700 Message-ID: <88C327F9-3124-40CE-B1CB-4A8F8870746D@icann.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: [dispatch] Initial version of draft-hoffman-dispatch-dns-over-https X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 02:38:25 -0000 [[ Any comments on the -00 that we should incorporate into a -01 before the cutoff in a week? ]] Greetings. Based on the advice from the chairs, we have given a new filename to our dns-over-https draft. This will hopefully get the draft picked up in the DISPATCH WG tracker page. --Paul and Patrick A new version of I-D, draft-hoffman-dispatch-dns-over-https-00.txt has been successfully submitted by Paul Hoffman and posted to the IETF repository. Name: draft-hoffman-dispatch-dns-over-https Revision: 00 Title: DNS Queries over HTTPS Document date: 2017-06-17 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/id/draft-hoffman-dispatch-dns-over-https-00.txt Status: https://datatracker.ietf.org/doc/draft-hoffman-dispatch-dns-over-https/ Htmlized: https://tools.ietf.org/html/draft-hoffman-dispatch-dns-over-https-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-hoffman-dispatch-dns-over-https-00 Abstract: DNS queries sometimes experience problems with end to end connectivity at times and places where HTTPS flows freely. HTTPS provides the most practical mechanism for reliable end to end communication. Its use of TLS provides integrity and confidentiality guarantees and its use of HTTP allows it to interoperate with proxies, firewalls, and authentication systems where required for transit. This document describes how to run DNS service over HTTP using https:// URIs. From nobody Mon Jun 26 21:17:40 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7233128B8E for ; Mon, 26 Jun 2017 21:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mnot.net header.b=Jd0U+ngR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Wmomg1Re Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eiRj-_GCuLYT for ; Mon, 26 Jun 2017 21:17:35 -0700 (PDT) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B7B6128B88 for ; Mon, 26 Jun 2017 21:17:35 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DA93320DAD; Tue, 27 Jun 2017 00:17:34 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 27 Jun 2017 00:17:34 -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:x-sasl-enc; s=fm1; bh=YMjFQEVH0IcJwAYW4a 4PP18SY6IPgCZ8eh0O1wY6AS8=; b=Jd0U+ngRrPVgUumhpxtCeD5BC3ZuNUhW9X wFOVFRrvWDanAbSgc/d/x+bcwleeSe2Bo9I9lJHl9wlmxH51G2MrsJvcnJ+byq+I ZHIYkOkA3hN5PaqgQA/WXDmg61jw9yEGm1XOEMdhMViOnlT9M14Jq77Sya+TWV9P /0ezmmIsW2rKrNiDzLdYuzYErvlLOkkALib1lOrlIR1vV/JGCnhmngg83xL19Fqf Mvr3xy9Y1BUGaRWaaACzkN2q0ju8esEAl1UqR3D9SdKXIMwrCBQZc9Wa7t/GANwl Vdz2PU5zSpUCwgosMXgALw/VtU6RJB0HzKV5xCBuIhCwvhPABjFQ== 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:x-sasl-enc; s= fm1; bh=YMjFQEVH0IcJwAYW4a4PP18SY6IPgCZ8eh0O1wY6AS8=; b=Wmomg1Re ypyAm+DRJQLRQy8nPGRTipbJd8NhxhhrN5agtxk3KRbjDRpWcXWWUle3pe7kmDE1 ZwF3Rc3gSn4gfC4UiIG9FxXPHqEO5JvlE3ugnNSe+pEAhPjAQ/P2afV8yeBRPGAA OI0zqODMmQlVl6LHYR4vVzJNcAoEFOxo99CdPqJu0Pj/KUojl3Lrr7TikwQ2tYGk pyARUtLwksSqEtcyyaVYWY0DI0SidV4WZq7w0KQEkZ9j6itkxl24H0UZaLgvy4Hh A5LxSFyXxOsaRDZr9DLiRibkjTyUsXpZaSI/doROmKvmY6p7SFfQXkCIQFjc9jna OyjbeK07iBnlBg== X-ME-Sender: X-Sasl-enc: aUEaVUa0AyzF7s6kllJzZ49z0qJJnF0tXAVBcUgY65Dq 1498537054 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id A3C76240F6; Tue, 27 Jun 2017 00:17:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: <88C327F9-3124-40CE-B1CB-4A8F8870746D@icann.org> Date: Tue, 27 Jun 2017 14:17:30 +1000 Cc: "dispatch@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <4CC73563-67A5-4683-851C-9E2A4B8F8032@mnot.net> References: <88C327F9-3124-40CE-B1CB-4A8F8870746D@icann.org> To: Paul Hoffman , Patrick McManus X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dispatch] Initial version of draft-hoffman-dispatch-dns-over-https X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 04:17:38 -0000 Hi Paul, Thanks for the heads-up. """ A DNS API Client encodes the DNS query into the HTTP request using either the HTTP GET or POST methods. When using the POST method, the DNS query is included as the message body of the HTTP request and the Content-Type request header indicates the media type of the message. POST-ed requests are smaller than their GET equivalents. """ I think it's a mistake to bifurcate the request style so fundamentally; = it's HTTP tunnelling at its worst.=20 The GET-style request in your example (which I think is pretty = representative) uses 44 octets to encode the body; the POST = serialisation is 33 octets. However, with HPACK's huffman encoding = (remember, you're requiring HTTP/2), that goes down to 34 bytes. Are we really that sensitive to on-the-wire size? To me, the cache = efficiency gains as well as simplicity more than make up for a 3% = difference. The statement that "POST-ed requests are smaller" isn't = going to be true, in pathological cases. """ The media type is "application/dns-udpwireformat" """ That's needlessly long; suggest "application/dns-uwf". There's a laundry list of questions about what HTTP functionality the = client needs to support. I'm hoping a draft will emerge shortly that = will help with this. Why shouldn't DNS API servers be able to generate ETags based upon their = internal state, to reduce outbound bandwidth? Cheers, > On 27 Jun 2017, at 12:38 pm, Paul Hoffman = wrote: >=20 > [[ Any comments on the -00 that we should incorporate into a -01 = before the cutoff in a week? ]] >=20 > Greetings. Based on the advice from the chairs, we have given a new = filename to our dns-over-https draft. This will hopefully get the draft = picked up in the DISPATCH WG tracker page. >=20 > --Paul and Patrick >=20 >=20 > A new version of I-D, draft-hoffman-dispatch-dns-over-https-00.txt > has been successfully submitted by Paul Hoffman and posted to the > IETF repository. >=20 > Name: draft-hoffman-dispatch-dns-over-https > Revision: 00 > Title: DNS Queries over HTTPS > Document date: 2017-06-17 > Group: Individual Submission > Pages: 12 > URL: = https://www.ietf.org/id/draft-hoffman-dispatch-dns-over-https-00.txt > Status: = https://datatracker.ietf.org/doc/draft-hoffman-dispatch-dns-over-https/ > Htmlized: = https://tools.ietf.org/html/draft-hoffman-dispatch-dns-over-https-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-hoffman-dispatch-dns-over-http= s-00 >=20 >=20 > Abstract: > DNS queries sometimes experience problems with end to end > connectivity at times and places where HTTPS flows freely. >=20 > HTTPS provides the most practical mechanism for reliable end to end > communication. Its use of TLS provides integrity and confidentiality > guarantees and its use of HTTP allows it to interoperate with > proxies, firewalls, and authentication systems where required for > transit. >=20 > This document describes how to run DNS service over HTTP using > https:// URIs. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jun 27 07:49:32 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82312129B59 for ; Tue, 27 Jun 2017 07:49:31 -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 hIEePRjXeLAf for ; Tue, 27 Jun 2017 07:49:30 -0700 (PDT) Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9672129B51 for ; Tue, 27 Jun 2017 07:49:29 -0700 (PDT) Received: from [169.254.168.162] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v5REmM4l051141 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 27 Jun 2017 07:48:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [169.254.168.162] From: "Paul Hoffman" To: "Mark Nottingham" Cc: "Paul Hoffman" , "Patrick McManus" , "dispatch@ietf.org" Date: Tue, 27 Jun 2017 07:49:02 -0700 Message-ID: <3302E029-063B-4CDF-9861-DEB6CFA09B0C@vpnc.org> In-Reply-To: <4CC73563-67A5-4683-851C-9E2A4B8F8032@mnot.net> References: <88C327F9-3124-40CE-B1CB-4A8F8870746D@icann.org> <4CC73563-67A5-4683-851C-9E2A4B8F8032@mnot.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.6r5347) Archived-At: Subject: Re: [dispatch] Initial version of draft-hoffman-dispatch-dns-over-https X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 14:49:31 -0000 On 26 Jun 2017, at 21:17, Mark Nottingham wrote: Issues will be opened for all of these. > """ > A DNS API Client encodes the DNS query into the HTTP request using > either the HTTP GET or POST methods. > > When using the POST method, the DNS query is included as the > message > body of the HTTP request and the Content-Type request header > indicates the media type of the message. POST-ed requests are > smaller than their GET equivalents. > """ > > I think it's a mistake to bifurcate the request style so > fundamentally; it's HTTP tunnelling at its worst. > > The GET-style request in your example (which I think is pretty > representative) uses 44 octets to encode the body; the POST > serialisation is 33 octets. However, with HPACK's huffman encoding > (remember, you're requiring HTTP/2), that goes down to 34 bytes. > > Are we really that sensitive to on-the-wire size? To me, the cache > efficiency gains as well as simplicity more than make up for a 3% > difference. The statement that "POST-ed requests are smaller" isn't > going to be true, in pathological cases. The bifurcation was not at all due to size, but instead the likelihood of HTTP caching. As the draft says in the paragraph after the quoted ones: "Using the GET method is friendlier to many HTTP cache implementations." We recognized that POST-ed requests can be cached, they rarely are. Also, not needing to encode the GET means that a client that doesn't already have a base64url encoder doesn't need to add one. I'm kinda speaking for my co-author there; I'm fine with having just one type and dealing with the trade-offs. We're open to what the WG might want. > > """ > The media type is "application/dns-udpwireformat" > """ > > That's needlessly long; suggest "application/dns-uwf". Is there a length-equivalent of bike-shed colors? :-) > There's a laundry list of questions about what HTTP functionality the > client needs to support. I'm hoping a draft will emerge shortly that > will help with this. Great. > Why shouldn't DNS API servers be able to generate ETags based upon > their internal state, to reduce outbound bandwidth? Can you say more? The current text is: """ In the HTTP responses, the HTTP cache headers SHOULD be set to expire at the same time as the shortest DNS TTL in the response. Because DNS provides only caching but not revalidation semantics, DNS over HTTP responses should not carry revalidation response headers (such as Last-Modified: or Etag:) or return 304 responses. """ --Paul Hoffman From nobody Tue Jun 27 08:50:33 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE836129A9F for ; Tue, 27 Jun 2017 08:50:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-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 irTd9PTC_nPQ for ; Tue, 27 Jun 2017 08:50:29 -0700 (PDT) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id E7C38129ADF for ; Tue, 27 Jun 2017 08:50:28 -0700 (PDT) Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com [209.85.216.177]) by linode64.ducksong.com (Postfix) with ESMTPSA id 1FFF63A019 for ; Tue, 27 Jun 2017 11:50:28 -0400 (EDT) Received: by mail-qt0-f177.google.com with SMTP id f92so27853529qtb.2 for ; Tue, 27 Jun 2017 08:50:28 -0700 (PDT) X-Gm-Message-State: AKS2vOz9eXWDfuzyYEaUQMGProhEWZw0mSCKJ4DzPM1cK9wQ7scY3r5n jxIcE+keAHyibhh5QHl8tOD3ziC0dQ== X-Received: by 10.237.50.132 with SMTP id z4mr7787856qtd.31.1498578627857; Tue, 27 Jun 2017 08:50:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.12.183.85 with HTTP; Tue, 27 Jun 2017 08:50:27 -0700 (PDT) In-Reply-To: <4CC73563-67A5-4683-851C-9E2A4B8F8032@mnot.net> References: <88C327F9-3124-40CE-B1CB-4A8F8870746D@icann.org> <4CC73563-67A5-4683-851C-9E2A4B8F8032@mnot.net> From: Patrick McManus Date: Tue, 27 Jun 2017 08:50:27 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Mark Nottingham Cc: Paul Hoffman , Patrick McManus , "dispatch@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c124602c815740552f306bc" Archived-At: Subject: Re: [dispatch] Initial version of draft-hoffman-dispatch-dns-over-https X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 15:50:32 -0000 --94eb2c124602c815740552f306bc Content-Type: text/plain; charset="UTF-8" On Mon, Jun 26, 2017 at 9:17 PM, Mark Nottingham wrote: > > > I think it's a mistake to bifurcate the request style so fundamentally; > it's HTTP tunnelling at its worst. > I'm going to push back on the tunnel terminology at least a little bit (while acknowledging one of the use cases has lots of properties of tunnels) the DoH approach tries to emphasize flexible typing and caching in order to leverage the HTTP ecosystem. The typing is particularly useful, I think. Refining that is certainly a goal of any future iterations of the draft. > The GET-style request in your example (which I think is pretty > representative) uses 44 octets to encode the body; the POST serialisation > is 33 octets. However, with HPACK's huffman encoding (remember, you're > requiring HTTP/2), that goes down to 34 bytes. > > Are we really that sensitive to on-the-wire size? To me, the cache > efficiency gains as well as simplicity more than make up for a 3% > difference. The statement that "POST-ed requests are smaller" isn't going > to be true, in pathological cases. > > So size is one concern that motivates the POST definition but there are others that should probably be articulated. Most significantly request header mechanisms that apply to the request message body don't apply well to GET other than the content-type encoded into the GET URI (which is a rather unfortunate wart without adding more such warts on). From a size perspective obviously compression might be a win for POST but not for GET but I'm also trying to be a pragmatist when thinking about whether 415 applies naturally to the GET mode. If we were to have only one, and that is a reasonable thing to at least discuss about a standard (the current situation is definitely a tradeoff, though one I support), I'd actually be inclined to go POST only to more naturally delineate the messages in each direction. That of course leads to the cache discussion - and we know as spec-heads that there's nothing wrong with caching POST in this model - but we also know that it won't happen. Thus this flavor of pragmatism while acknowledging there are 30 other flavors available on the menu. > Why shouldn't DNS API servers be able to generate ETags based upon their > internal state, to reduce outbound bandwidth? > > we should give it a full airing wherever this gets dispatched to, but 2 thoughts: 1 - iirc this boils down to an interaction between the DNS TTL embedded in the response and the 304.. you really do conceptually need a new DNS entry, but if its byte-for-byte the same I agree the server could 304 that with appropriate cache controls. we should figure out the right language to thread that needle. 2 - these responses are good candidates for immutable --94eb2c124602c815740552f306bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 26, 2017 at 9:17 PM, Mark Nottingham <= mnot@mnot.net> wrote:


I think it's a mistake to bifurcate the request style so fundamentally;= it's HTTP tunnelling at its worst.

I'm going to push back on the tunnel terminology at least a little bit= (while acknowledging one of the use cases has lots of properties of tunnel= s) the DoH approach tries to emphasize flexible typing and caching in order= to leverage the HTTP ecosystem. The typing is particularly useful, I think= . Refining that is certainly a goal of any future iterations of the draft.<= /div>


The GET-style request in your example (which I think is pretty representati= ve) uses 44 octets to encode the body; the POST serialisation is 33 octets.= However, with HPACK's huffman encoding (remember, you're requiring= HTTP/2), that goes down to 34 bytes.

Are we really that sensitive to on-the-wire size? To me, the cache efficien= cy gains as well as simplicity more than make up for a 3% difference. The s= tatement that "POST-ed requests are smaller" isn't going to b= e true, in pathological cases.


So size is one concern that motivates = the POST definition but there are others that should probably be articulate= d. Most significantly request header mechanisms that apply to the request m= essage body don't apply well to GET other than the content-type encoded= into the GET URI (which is a rather unfortunate wart without adding more s= uch warts on). From a size perspective obviously compression might be a win= for POST but not for GET but I'm also trying to be a pragmatist when t= hinking about whether 415 applies naturally to the GET mode.

=
If we were to have only one, and that is a reasonable thing to a= t least discuss about a standard (the current situation is definitely a tra= deoff, though one I support), I'd actually be inclined to go POST only = to more naturally delineate the messages in each direction. That of course = leads to the cache discussion - and we know as spec-heads that there's = nothing wrong with caching POST in this model - but we also know that it wo= n't happen. Thus this flavor of=C2=A0 pragmatism while acknowledging th= ere are 30 other flavors available on the menu.
=C2=A0
Why shouldn't DNS API servers be able to generate ETags based upon thei= r internal state, to reduce outbound bandwidth?


we should give it a full airing wherev= er this gets dispatched to, but 2 thoughts:
1 - iirc this boils d= own to an interaction between the DNS TTL embedded in the response and the = 304.. you really do conceptually need a new DNS entry, but if its byte-for-= byte the same I agree the server could 304 that with appropriate cache cont= rols. we should figure out the right language to thread that needle.

2 - these responses are good candidates for immutabl= e
=C2=A0
--94eb2c124602c815740552f306bc-- From nobody Tue Jun 27 12:39:15 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F283312EB16 for ; Tue, 27 Jun 2017 12:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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=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 vLkBv4zwUS_A for ; Tue, 27 Jun 2017 12:39:11 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 1813612EB13 for ; Tue, 27 Jun 2017 12:39:11 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b207so23135044lfg.2 for ; Tue, 27 Jun 2017 12:39:11 -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=ZWhMoMvoafStcmuN6LHxkflir3ExD8tkTpV7vJClWNA=; b=l07pZyCaNVd7H7rHYMN7i18t+lxE0pprCm2eFxMTC/+B4RI5mK0k9ZA2cX9twHgR3w wpEuBfhW4FRJimLBnYlQKXamz6/eK+fcOCG7b+aqjbRL4n69Fy00n6V+zL9qLfd2W14u 0Gr1U9pMbN6iFN7kkfqqIrMvwpJrBAHxjCaDWvp8ZJbyTXUbpTkdO7mINW5tXf1fYmXk DchZBYbs2ds3xzpvAQKFisk8nY5N8f3Hr5hRDqC/l2ZUjlaSBFFmNx7cBcsWwlnXouYh v5qSimPGdCms5honLCsy/N24X7aeOwiQHSjGUkbw50yY8l/j1NycgXwMP/8g6gp+pDgr jGDQ== 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=ZWhMoMvoafStcmuN6LHxkflir3ExD8tkTpV7vJClWNA=; b=GQtaH5zKj0n3j6VTAj1QvAeyTHAV+W/LMFZ9L4UoNUvzDijErTNt8wPYv1Kh2zsDMt 31d6h1SKHVfSJ3n2I875UmhHyYn1umcKQFL7aVFnX3YWXhrFQfpomJ5+8g9mkz2I5aXC 19JZsfw8T+916TlRbVsc+zi/cJpcvkuECTWeNCOgcMGiUKCFoR/vH1FNJYogerpz95Q/ Mrkitr3jsf1w1ngwbq/P88xqSS9QBP2qxsptcauTv0MxVZKxyfZUKB6Yl4n7ArmHmA1w x0dIrx7wuKkNgUdU+BIRIJ2vnifQtHC6C1pCleySEtv+OrPrXgV7JCkcJ1kzZ2pZVhJm dtjQ== X-Gm-Message-State: AKS2vOw30X5IEcEof9iqMAlKLJIYyZ4xjeDeXhCJHAXf0aRRKp5R3m5o OkgA2J9rmajehZ2F4aEcmLgSNWbRWw== X-Received: by 10.46.77.70 with SMTP id a67mr2175393ljb.103.1498592349099; Tue, 27 Jun 2017 12:39:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Tue, 27 Jun 2017 12:39:08 -0700 (PDT) In-Reply-To: <3302E029-063B-4CDF-9861-DEB6CFA09B0C@vpnc.org> References: <88C327F9-3124-40CE-B1CB-4A8F8870746D@icann.org> <4CC73563-67A5-4683-851C-9E2A4B8F8032@mnot.net> <3302E029-063B-4CDF-9861-DEB6CFA09B0C@vpnc.org> From: Martin Thomson Date: Tue, 27 Jun 2017 12:39:08 -0700 Message-ID: To: Paul Hoffman Cc: Mark Nottingham , Patrick McManus , Paul Hoffman , "dispatch@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [dispatch] Initial version of draft-hoffman-dispatch-dns-over-https X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 19:39:13 -0000 On 27 June 2017 at 07:49, Paul Hoffman wrote: >> >> The media type is "application/dns-udpwireformat" >> """ >> >> That's needlessly long; suggest "application/dns-uwf". > > > Is there a length-equivalent of bike-shed colors? :-) See also RFC 7541, which makes this specific sort of micro-optimization less necessary. From nobody Tue Jun 27 15:02:09 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A33F912EB4A for ; Tue, 27 Jun 2017 15:02:05 -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=ZLTLECSw; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=o8iHZgex Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpiJlsNVJ-fZ for ; Tue, 27 Jun 2017 15:02:02 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03F7C126BF7 for ; Tue, 27 Jun 2017 15:02:02 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 7277A2281C; Tue, 27 Jun 2017 18:02:00 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 27 Jun 2017 18:02:00 -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:x-sasl-enc; s=fm1; bh=MVpuTH5v/0Fp2ckSp4 B+FnrMGxG3E9CXKS3DtCZfvcA=; b=ZLTLECSwPawbywdBvLm622OFp6wCNEzVyN EyrizHzyABc8rg0kZqT9AXr8IjZr2T5g/vGr7dWvlm+Phl1Y3Toj7b5juKy0PR3L +SB9580+qlBmSTBJonUf4JclWZO3hrP8eKwdC/iiCsern036fnflRgwi1hp/1PY9 sJx+IJBexQ9cK7XStuMmYDqtSrzdbiGMbgK9pH/Fl1rcyvOsqZwtjFPZ9eBaXJa5 bD0TWnCSjiyXkoQFVdplIU/k9P7TKfaKnEzhbboTVc0MrE5nzX9xjboQ3QCqvI4b oS42lG/Hbu8GG/MhMDy6bA8J8H2ugvEqUaZst87Ri3FDuxGG6f+Q== 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:x-sasl-enc; s= fm1; bh=MVpuTH5v/0Fp2ckSp4B+FnrMGxG3E9CXKS3DtCZfvcA=; b=o8iHZgex p2ySIQh86zhWt4h6EYv3+drUcNZ+4dk6jNtoeRD0te9fSYZPAp9ksXHtwSSgoox2 Z1t3Q+VDCN+ksxqSxv5S4jiZNjov7yND8M5WaWNZfxutJMjygl4y164+kKsqOYcg wxD/eFF6TiaaQmWSy3MXkb4I50PO2allq9Wk8L5Wff6EP8TkVnBMsjUjxL0Yd4Hf Ov+1791odpGBf3QD7S6e0ItaXgYIoMpQRg96qUe+J8tQ4QDzOhnH8NgSxePdhITh Ai1xuPMg9F8c+IDsQ3b8q9dB207J1/EiDN+pSHwsADDA+TjYFHo5AvNXbgqIyvmI XH0EJPsmhudyyg== X-ME-Sender: X-Sasl-enc: 71/aIWdoHs63V8wHm8NedBB3DwKLKPGpBINzpa11PB+E 1498600919 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id AB9AD2458E; Tue, 27 Jun 2017 18:01:58 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Wed, 28 Jun 2017 08:01:54 +1000 Cc: Paul Hoffman , Patrick McManus , Paul Hoffman , "dispatch@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <88C327F9-3124-40CE-B1CB-4A8F8870746D@icann.org> <4CC73563-67A5-4683-851C-9E2A4B8F8032@mnot.net> <3302E029-063B-4CDF-9861-DEB6CFA09B0C@vpnc.org> To: Martin Thomson X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dispatch] Initial version of draft-hoffman-dispatch-dns-over-https X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Jun 2017 22:02:06 -0000 On 28 Jun 2017, at 5:39 am, Martin Thomson = wrote: >=20 > On 27 June 2017 at 07:49, Paul Hoffman wrote: >>>=20 >>> The media type is "application/dns-udpwireformat" >>> """ >>>=20 >>> That's needlessly long; suggest "application/dns-uwf". >>=20 >>=20 >> Is there a length-equivalent of bike-shed colors? :-) >=20 > See also RFC 7541, which makes this specific sort of > micro-optimization less necessary. They're putting it in the URL, which changes between almost all requests = on a connection. -- Mark Nottingham https://www.mnot.net/ From nobody Tue Jun 27 18:05:59 2017 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE40129B22 for ; Tue, 27 Jun 2017 18:05:57 -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=JzpelF71; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nQZpKmR9 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TbC7iwIuiCU for ; Tue, 27 Jun 2017 18:05:54 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8561F129B42 for ; Tue, 27 Jun 2017 18:05:54 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id A3BB320975; Tue, 27 Jun 2017 21:05:50 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Tue, 27 Jun 2017 21:05:50 -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:x-sasl-enc; s=fm1; bh=3I+1FgPMJ2o0urWbXx A1HQT7ZSOfJr5ttyq+4qZnk2k=; b=JzpelF71PZ0TwKRWBWNs2465YFCt5SIr16 KAFZY1AyNBDNWiyALYK7qoT7/3YlgY8KYO97mimrdxKPcusKdpy7XZasLzA39J+C +uuQzfvFL/mUc/+vnSiOUTymD0hrfM5LcNQZDOvNR1OzaKn23DgI0EdutwPudiZv dNn+LQjvRLH99stTpRrbHdicrRL11SqttlSwsf9Wwo71WhQprg1ChmY31xGVzYCP VRBqwi4gJVH95pu8O3JHXn7RnwE4t2P5JHENZqbNi2BXfs27xzyKJiniYgBfvZap LyjEZW56CYgxF2ZCI7WrJGxhq2xjBJ+mH42vvO+4SSJYxcvVXgtA== 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:x-sasl-enc; s= fm1; bh=3I+1FgPMJ2o0urWbXxA1HQT7ZSOfJr5ttyq+4qZnk2k=; b=nQZpKmR9 MQwIbI2FrHBh5ZSRDXVpdDDzgL4zTsZ2basXtTDxn35OGlkEcVAsyR7Z8h2UlEti 7ibyUbyaq0H7FJ1vz6Uyfl6YSSQlpghm0JOxlLqSJo/c97f7taaak8x2IwD9dCcw 4/HVHtClImqSc5Hw1whBonZ5RXw9bsttUSf9ixp0hrIH9MpXMBeiGiLvN+Lks1Xy 5YOM4aWYcpVGRiJLPB7XKNU6VuN3q3+mXnHcTX2GkwySnFt/3t5VsWAujWww9Ubz whYrfmRacH52++3GQYjv+t/+RtBHohF+ulnZE7TZZX78+3OSMmfAiGj+SngKM9gw xN5PnlPdKIG3vw== X-ME-Sender: X-Sasl-enc: sa+3s6nCmQVej64scrcq+Bp1jEmTnzjgCNEWsO9HnYRM 1498611950 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 199747E794; Tue, 27 Jun 2017 21:05:48 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Wed, 28 Jun 2017 11:05:45 +1000 Cc: Paul Hoffman , Patrick McManus , "dispatch@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <089A78D5-F98A-4D89-A94A-3F94C1BE87EC@mnot.net> References: <88C327F9-3124-40CE-B1CB-4A8F8870746D@icann.org> <4CC73563-67A5-4683-851C-9E2A4B8F8032@mnot.net> To: Patrick McManus X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [dispatch] Initial version of draft-hoffman-dispatch-dns-over-https X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 01:05:57 -0000 > On 28 Jun 2017, at 1:50 am, Patrick McManus = wrote: >> The GET-style request in your example (which I think is pretty = representative) uses 44 octets to encode the body; the POST = serialisation is 33 octets. However, with HPACK's huffman encoding = (remember, you're requiring HTTP/2), that goes down to 34 bytes. >>=20 >> Are we really that sensitive to on-the-wire size? To me, the cache = efficiency gains as well as simplicity more than make up for a 3% = difference. The statement that "POST-ed requests are smaller" isn't = going to be true, in pathological cases. >=20 > So size is one concern that motivates the POST definition but there = are others that should probably be articulated. Most significantly = request header mechanisms that apply to the request message body don't = apply well to GET other than the content-type encoded into the GET URI = (which is a rather unfortunate wart without adding more such warts on). = =46rom a size perspective obviously compression might be a win for POST = but not for GET but I'm also trying to be a pragmatist when thinking = about whether 415 applies naturally to the GET mode. >=20 > If we were to have only one, and that is a reasonable thing to at = least discuss about a standard (the current situation is definitely a = tradeoff, though one I support), I'd actually be inclined to go POST = only to more naturally delineate the messages in each direction. That of = course leads to the cache discussion - and we know as spec-heads that = there's nothing wrong with caching POST in this model - but we also know = that it won't happen. Thus this flavor of pragmatism while = acknowledging there are 30 other flavors available on the menu. If it's just Content-Type, I think putting it in the URL is fine, and = would prefer a GET-only solution. If it's going to be more complex than that, I'd recommend that the = well-known resource actually be a "directory" / "map" / "home page" = document that explains how to interact with the DNS API server, rather = than baking everything into the URI. It'll give you far more flexibility = for future changes, and AIUI in the use cases for this, it's not onerous = to do a single up-front discovery RT. BTW - If I were to nit-pick here, I'd say that you don't need a = well-known URI for this; there's no reason that a DNS API server = couldn't be configured with a full URI, instead of a hostname / port = pair.=20 >> Why shouldn't DNS API servers be able to generate ETags based upon = their internal state, to reduce outbound bandwidth? >=20 > we should give it a full airing wherever this gets dispatched to, but = 2 thoughts: > 1 - iirc this boils down to an interaction between the DNS TTL = embedded in the response and the 304.. you really do conceptually need a = new DNS entry, but if its byte-for-byte the same I agree the server = could 304 that with appropriate cache controls. we should figure out the = right language to thread that needle. >=20 > 2 - these responses are good candidates for immutable Fair enough. Just didn't want to discount validation out of the gate. -- Mark Nottingham https://www.mnot.net/