From nobody Thu Jun 2 13:47:00 2016 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4533F12D7F9; Thu, 2 Jun 2016 13:46:58 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160602204658.8781.44260.idtracker@ietfa.amsl.com> Date: Thu, 02 Jun 2016 13:46:58 -0700 Archived-At: Cc: dnssd@ietf.org, dnssd-chairs@ietf.org, rdroms.ietf@gmail.com, terry.manderson@icann.org Subject: [dnssd] dnssd - New Meeting Session Request for IETF 96 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 20:46:58 -0000 A new meeting session request has just been submitted by Ralph Droms, a Chair of the dnssd working group. --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: Ralph Droms Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: 6man dnsop homenet dprive dbound dhc 6lo iccrg icnrg Second Priority: roll core t2trg irtfopen dane 6tisch Special Requests: --------------------------------------------------------- From nobody Thu Jun 9 19:12:50 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DF6128874 for ; Thu, 9 Jun 2016 19:12:48 -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 AXOidpoma_NY for ; Thu, 9 Jun 2016 19:12:47 -0700 (PDT) Received: from mx2.yitter.info (mx2.yitter.info [50.116.54.116]) by ietfa.amsl.com (Postfix) with ESMTP id B2DA712D5BF for ; Thu, 9 Jun 2016 19:12:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mx2.yitter.info (Postfix) with ESMTP id 6D861109EC for ; Fri, 10 Jun 2016 02:12:47 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at crankycanuck.ca Received: from mx2.yitter.info ([127.0.0.1]) by localhost (mx2.yitter.info [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTjyb7vjI-tU for ; Fri, 10 Jun 2016 02:12:46 +0000 (UTC) Received: from mx2.yitter.info (c-73-142-157-135.hsd1.nh.comcast.net [73.142.157.135]) by mx2.yitter.info (Postfix) with ESMTPSA id C8F7E105A5 for ; Fri, 10 Jun 2016 02:12:46 +0000 (UTC) Date: Thu, 9 Jun 2016 22:12:45 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20160610021245.GK620@mx2.yitter.info> References: <1C777AF5-0406-44A2-B2BC-30673E8B5ADB@ecs.soton.ac.uk> <20160403010246.GR30146@mx2.yitter.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20160403010246.GR30146@mx2.yitter.info> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-mdns-dns-interop-02 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 02:12:49 -0000 Hi, I'm likely to have some time in airports soon, so I want to know what to do here. In particular: On Sat, Apr 02, 2016 at 09:02:46PM -0400, Andrew Sullivan wrote: > Hmm. I suppose the point is made clearer if the draft says something > like, "If you are sure that nothing will go past some context -- where > that context is either the LAN, or the site-network however defined -- > then local conventions prevail. Otherwise, parts of the domain names > to be queried … &c." Is that clearer? Is this change ok? > Stuart has asserted strogly -- and I confess I have some sympathy for > his claim -- that all the use cases involve pick-lists. If that's > true, then the "first way" is never going to happen, and the "second > way" is the only real option. And you're right that neither is > actually consistent with 6055. I still don't know what to do here. Suggestions? Just call out that there's an explicit inconsistency with 6055? > > seems architecturally bad. So I think the confusing is perhaps around the term > > “DNS-SD implementations” which could use some elaboration, or at least rewording for consistency > > with RFC 6055. > > I wish I knew what the WG wanted here. I'm way more than amenable to text. I need text to address this, or I'll leave it alone. A -- Andrew Sullivan ajs@anvilwalrusden.com From nobody Fri Jun 10 13:02:58 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4664912D786 for ; Fri, 10 Jun 2016 13:02:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GWrdZd4_zUd7 for ; Fri, 10 Jun 2016 13:02:53 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-eopbgr680109.outbound.protection.outlook.com [40.107.68.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0D6412D8D9 for ; Fri, 10 Jun 2016 13:02:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=cQhY3kfHVzhL/7sY68t0Y7mrdPukZxy+FktQsd4Z2bc=; b=hxN++H+OtMKCNnpsBPHwz95w8ks2+vHjvPw3EvlhtDjsmhbaXXcJIqk5VLo93RptCImLe0wBLESgDzUXL76xiZm97b7ApAldJ7sgkNqZQ3yhcKAUWZNhKKvM5ZmLcF14pVP33rW6/VeVOozCY5+XaSTP3Hepw5xL7uktu8GOYW8= Received: from DM2PR0301MB0655.namprd03.prod.outlook.com (10.160.96.17) by DM2PR0301MB0653.namprd03.prod.outlook.com (10.160.96.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.517.8; Fri, 10 Jun 2016 20:02:50 +0000 Received: from DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) by DM2PR0301MB0655.namprd03.prod.outlook.com ([10.160.96.17]) with mapi id 15.01.0517.005; Fri, 10 Jun 2016 20:02:50 +0000 From: Christian Huitema To: "dnssd@ietf.org" Thread-Topic: New Version Notification for draft-huitema-dnssd-privacy-01.txt Thread-Index: AQHRw08sS63YDnKYNkGGJbIxhclod5/jHQ2Q Date: Fri, 10 Jun 2016 20:02:50 +0000 Message-ID: References: <20160610193457.18214.76825.idtracker@ietfa.amsl.com> In-Reply-To: <20160610193457.18214.76825.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=huitema@microsoft.com; x-originating-ip: [2001:4898:80e8:e::59a] x-ms-office365-filtering-correlation-id: 39baf13f-2752-460b-be67-08d3916a334e x-microsoft-exchange-diagnostics: 1; DM2PR0301MB0653; 6:jhOQL25jfuEOlo9wX+BOZdAuqQmTi6b8i6hW/jVEk/ti9kFAhgW1zu8ZyOG400m/q77xM9Qew3Uu+8XOzGFMcV6u+56Fa2MEYg8+pcnaMnxWAVoLc2wv/898Jm+Ed+L/l2X/7tTJoId1rZbIQ/qPmDf5rYzaxlFLPRYlygzOb3eYy1MN1zXpZUDPLxE6Mk/eVxa1HD2m6cj84uWlQ11KBUxCIXdYmeFfBfaUqvfEu7GRATKbTcxBcxIgOfZ1IfSgqB0v2iQmXlcAxti4hS9vwidCli9Sb64hVNgRNOQCjXjeQj6gUdXHfOD1YWcBoj74D2rgkUgW1paw9e+sJzK83g==; 5:ycqb9JY7Lf8DXLLHg0gstDFIMURRI3M+YxPLoAAVe1zt2Zw+5o/KfSbOibYN8ZdRck05fJmv4npSaFaCfs+zeE7Df+XM3UxwKL/+epk2xq7JkOwqd5V/IjdxbbbXQbDlxJBQ3Da1As7giDFfMMSTXw==; 24:6WmHCtMobrFeA9zGwsDAZz1motQ6sIh0j+K1gJkD+zJaq+j9+FAZBjoMs33lc1yxGIlA/IAnU7VZYKtOIuFDp3g+KWYq6sGFFZVxV4BKPRM=; 7:KwVhkzuAM87Po/FKInEENZmbttL65H4Ld79kdh2FatupYUIGJd9OFy0cvSHRGrHFiUz1as59zXZvCnT/UEDp7/nL1wlz1D5FQB10iqPYDLzEO1OXUoqHlfmGMKQPd+Hyh2q83yaxtGauIPLcX9T2Cs/eMxuxqK5+gb3sc5/RTeoHESSnOv+vtD+JZzK5d5wpaVovoAx86JXpc9+YM54wk3VRzEp69N/bp2P/uVL5hWJnbkPC5xoYI1+cGKtsrlJN x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0301MB0653; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038); SRVR:DM2PR0301MB0653; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0301MB0653; x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(13464003)(189002)(377454003)(199003)(377424004)(5640700001)(5008740100001)(2501003)(68736007)(2906002)(76576001)(15650500001)(8676002)(81166006)(1730700003)(97736004)(81156014)(2351001)(2900100001)(2950100001)(33656002)(105586002)(15975445007)(19580405001)(77096005)(19580395003)(106116001)(230783001)(586003)(110136002)(92566002)(8936002)(9686002)(6116002)(102836003)(3660700001)(4326007)(3280700002)(76176999)(86612001)(8990500004)(10090500001)(189998001)(106356001)(50986999)(5003600100002)(122556002)(11100500001)(10400500002)(10290500002)(5005710100001)(5004730100002)(54356999)(5002640100001)(99286002)(74316001)(86362001)(101416001)(87936001)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0653; H:DM2PR0301MB0655.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; CAT:NONE; LANG:en; CAT:NONE; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jun 2016 20:02:50.1190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0301MB0653 Archived-At: Cc: Daniel Kaiser Subject: [dnssd] FW: New Version Notification for draft-huitema-dnssd-privacy-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 20:02:56 -0000 SGVyZSBpcyBhIG5ldyB2ZXJzaW9uIG9mIHRoZSAiRE5TLVNEIFByaXZhY3kiIGRyYWZ0LiBJIGNv LWF1dGhvcmVkIGl0IHdpdGggRGFuaWVsIEthaXNlci4gRGFuaWVsIGlzIGNvbXBsZXRpbmcgaGlz IFBoRCBhdCB0aGUgVW5pdmVyc2l0eSBvZiBLb25zdGFueiwgaW4gR2VybWFueSwgc3R1ZHlpbmcg aXNzdWVzIHJlbGF0ZWQgdG8gcHJpdmFjeSBhbmQgZGlzY292ZXJ5LiBUaGlzIG5ldyBkcmFmdCBp cyBpbiBteSBvcGluaW9uIG11Y2ggaW1wcm92ZWQgZnJvbSB0aGUgdmVyc2lvbiAwMCB0aGF0IEkg cHJlc2VudGVkIGluIEJ1ZW5vcyBBaXJlcy4gWW91IGNhbiByZWFkIHRoZSBhYnN0cmFjdCBiZWxv dyBmb3IgdGhlIGJyb2FkIGxpbmVzIG9mIHRoZSBwcm9wb3NlZCBzb2x1dGlvbi4gT3IsIGJldHRl ciB5ZXQsIHJlYWQgdGhlIGRyYWZ0IGFuZCBjb21tZW50IQ0KDQotLSBDaHJpc3RpYW4gSHVpdGVt YQ0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVybmV0LWRyYWZ0 c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpTZW50OiBGcmlk YXksIEp1bmUgMTAsIDIwMTYgMTI6MzUgUE0NClRvOiBDaHJpc3RpYW4gSHVpdGVtYSA8aHVpdGVt YUBtaWNyb3NvZnQuY29tPjsgRGFuaWVsIEthaXNlciA8ZGFuaWVsLmthaXNlckB1bmkta29uc3Rh bnouZGU+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWh1aXRl bWEtZG5zc2QtcHJpdmFjeS0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQt aHVpdGVtYS1kbnNzZC1wcml2YWN5LTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1p dHRlZCBieSBDaHJpc3RpYW4gSHVpdGVtYSBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRv cnkuDQoNCk5hbWU6CQlkcmFmdC1odWl0ZW1hLWRuc3NkLXByaXZhY3kNClJldmlzaW9uOgkwMQ0K VGl0bGU6CQlQcml2YWN5IEV4dGVuc2lvbnMgZm9yIEROUy1TRA0KRG9jdW1lbnQgZGF0ZToJMjAx Ni0wNi0xMA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOgkJMjYNClVSTDog ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaHVp dGVtYS1kbnNzZC1wcml2YWN5LTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWh1aXRlbWEtZG5zc2QtcHJpdmFjeS8NCkh0bWxpemVk OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVpdGVtYS1kbnNzZC1w cml2YWN5LTAxDQpEaWZmOiAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmZjZGlmZj91 cmwyPWRyYWZ0LWh1aXRlbWEtZG5zc2QtcHJpdmFjeS0wMQ0KDQpBYnN0cmFjdDoNCiAgIEROUy1T RCBhbGxvd3MgZGlzY292ZXJ5IG9mIHNlcnZpY2VzIHB1Ymxpc2hlZCBpbiBETlMgb3IgTUROUy4g IFRoZQ0KICAgcHVibGljYXRpb24gbm9ybWFsbHkgZGlzY2xvc2VzIGluZm9ybWF0aW9uIGFib3V0 IHRoZSBkZXZpY2UNCiAgIHB1Ymxpc2hpbmcgdGhlIHNlcnZpY2VzLiAgVGhlcmUgYXJlIHVzZSBj YXNlcyB3aGVyZSBkZXZpY2VzIHdhbnQgdG8NCiAgIGNvbW11bmljYXRlIHdpdGhvdXQgZGlzY2xv c2luZyB0aGVpciBpZGVudGl0eSwgZm9yIGV4YW1wbGUgdHdvIG1vYmlsZQ0KICAgZGV2aWNlcyB2 aXNpdGluZyB0aGUgc2FtZSBob3RzcG90Lg0KDQogICBXZSBwcm9wb3NlIHRvIHNvbHZlIHRoaXMg cHJvYmxlbSBieSBhIHR3by1zdGFnZSBhcHByb2FjaC4gIEluIHRoZQ0KICAgZmlyc3Qgc3RhZ2Us IGhvc3RzIGRpc2NvdmVyIFByaXZhdGUgRGlzY292ZXJ5IFNlcnZpY2UgSW5zdGFuY2VzIHZpYQ0K ICAgRE5TLVNEIHVzaW5nIHNwZWNpYWwgZm9ybWF0cyB0byBwcm90ZWN0IHRoZWlyIHByaXZhY3ku ICBUaGVzZSBzZXJ2aWNlDQogICBpbnN0YW5jZXMgY29ycmVzcG9uZCB0byBQcml2YXRlIERpc2Nv dmVyeSBTZXJ2ZXJzIHJ1bm5pbmcgb24gcGVlcnMuDQogICBJbiB0aGUgc2Vjb25kIHN0YWdlLCBo b3N0cyBkaXJlY3RseSBxdWVyeSB0aGVzZSBQcml2YXRlIERpc2NvdmVyeQ0KICAgU2VydmVycyB2 aWEgRE5TLVNEIG92ZXIgVExTLiAgQSBwYWlyd2lzZSBzaGFyZWQgc2VjcmV0IG5lY2Vzc2FyeSB0 bw0KICAgZXN0YWJsaXNoIHRoZXNlIGNvbm5lY3Rpb25zIGlzIG9ubHkga25vd24gdG8gaG9zdHMg YXV0aG9yaXplZCBieSBhDQogICBwYWlyaW5nIHN5c3RlbS4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0K From nobody Wed Jun 22 02:15:48 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 034BD12B060 for ; Wed, 22 Jun 2016 02:15:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Grybn9LQdh8a for ; Wed, 22 Jun 2016 02:15:43 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E393812D09A for ; Wed, 22 Jun 2016 02:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=FdwyxykggofwE4KoACsxZDb9AwXfMMeepDmLV0fEn4w=; b=G2Hh4mbjgXqte/2Pwp5cJwfXQnFQYhthdfya6BRoGiUcSpq/NHoDX7mG80e06ZDrpq1faJyZcPHfyheGpSS5EgbCMWLFV0yBhP1yeLLmFDFwEybHUeyYLO4ARIV3K2R8pML6ZfRTdcg5RjdP0XOvtrLCVQcXeRhqZbAkzU5VML8= Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0082.outbound.protection.outlook.com [213.199.154.82]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-65-MMVQ6pF5O8eO4tyxj9APGQ-1; Wed, 22 Jun 2016 10:15:36 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (TLS) id 15.1.506.9; Wed, 22 Jun 2016 09:15:34 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0501.018; Wed, 22 Jun 2016 09:15:35 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: [dnssd] New Version Notification for draft-huitema-dnssd-privacy-01.txt Thread-Index: AQHRzGaiywt75okvWEatT++QHcTo/A== Date: Wed, 22 Jun 2016 09:15:34 +0000 Message-ID: <2499AEF6-5773-4E3C-AF81-C4CF2280B154@jisc.ac.uk> References: <20160610193457.18214.76825.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: 3d9e1bb7-4952-46ce-cd63-08d39a7dc4a3 x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 5:lFX+HXGtWdyXT+2mxmkLb9uKhBI/9i9IDiXw3OnJAOvSIxHRKvTj8MTJvEm4Tx2bNz72rQcv0kBp7yta9XoOSM5E/k0C6VWjBtvlNjHQClW59UVGjDhmuYVDrqAuNmf+4fiePuPIFs6xCDpAw3A4Lg==; 24:VTR0k0eAenZvkxXbJURyOVDnJn3FZ8yR06EPzEVArqbl3r9emuw4t2p+ZDeLoJsKzC9YpGI0PjSotuIS0LqGcBtKvZWOYHwdn1tS7a/0HJI=; 7:6orLbeodrtpNVFNq0s4MhcW4K6W9gGxmbA3Ds1gOwCXNx58wfCZAPpb+ISMJj5JjM5eqnIpQhNRfvZRBu7bP5PGsrnSOKSUVyV/h6xgvKb4Reb3m3j1GjpZEJ3kjN7ts2TWNAglr92WxPxBJxlFD/6WeKa92/qMlLX7zlRYrWi+DqSzxWIF3wE/2pwLrHQ7F; 20:Oe0jGVBRWBkKI01eJ+A4YwVR2WJhsv4VAVy/wakgGCY5hONSv6/HTou5TsIgE8jeVy5GLPVAs+W7sZLGVQwzdBr0mwRH6fspfqM6A+Q1G1VCJ2ezeGUsj7I2NDOVjugmnduiNUtWtYrA276xHRGXB5NDj1cgGAZAMbPSMxgyC7w= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(24454002)(377424004)(66654002)(189002)(199003)(13464003)(377454003)(15650500001)(105586002)(50986999)(10400500002)(8666005)(19580395003)(5002640100001)(106116001)(19580405001)(122556002)(74482002)(4326007)(101416001)(7846002)(2950100001)(81156014)(81166006)(1730700003)(77096005)(2900100001)(106356001)(8936002)(87936001)(76176999)(2351001)(15975445007)(110136002)(82746002)(6116002)(3846002)(3280700002)(2906002)(57306001)(86362001)(50226002)(33656002)(230783001)(66066001)(2501003)(5640700001)(189998001)(92566002)(68736007)(97736004)(586003)(83716003)(102836003)(7736002)(3660700001)(36756003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jun 2016 09:15:34.8780 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 X-MC-Unique: MMVQ6pF5O8eO4tyxj9APGQ-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Daniel Kaiser , Christian Huitema Subject: Re: [dnssd] New Version Notification for draft-huitema-dnssd-privacy-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 09:15:47 -0000 Hi, Ralph and I would like to encourage some review of this updated document, p= articularly as it is now stepping into a proposed solution space. =20 Privacy aspects are very important in all our work, and it would be great t= o have feedback on the updated draft in advance of the meeting in Berlin. Many thanks, Tim=20 > On 10 Jun 2016, at 21:02, Christian Huitema wrote= : >=20 > Here is a new version of the "DNS-SD Privacy" draft. I co-authored it wit= h Daniel Kaiser. Daniel is completing his PhD at the University of Konstanz= , in Germany, studying issues related to privacy and discovery. This new dr= aft is in my opinion much improved from the version 00 that I presented in = Buenos Aires. You can read the abstract below for the broad lines of the pr= oposed solution. Or, better yet, read the draft and comment! >=20 > -- Christian Huitema >=20 >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Friday, June 10, 2016 12:35 PM > To: Christian Huitema ; Daniel Kaiser > Subject: New Version Notification for draft-huitema-dnssd-privacy-01.txt >=20 >=20 > A new version of I-D, draft-huitema-dnssd-privacy-01.txt > has been successfully submitted by Christian Huitema and posted to the IE= TF repository. >=20 > Name:=09=09draft-huitema-dnssd-privacy > Revision:=0901 > Title:=09=09Privacy Extensions for DNS-SD > Document date:=092016-06-10 > Group:=09=09Individual Submission > Pages:=09=0926 > URL: https://www.ietf.org/internet-drafts/draft-huitema-dnssd-= privacy-01.txt > Status: https://datatracker.ietf.org/doc/draft-huitema-dnssd-priv= acy/ > Htmlized: https://tools.ietf.org/html/draft-huitema-dnssd-privacy-0= 1 > Diff: https://www.ietf.org/rfcdiff?url2=3Ddraft-huitema-dnssd-p= rivacy-01 >=20 > Abstract: > DNS-SD allows discovery of services published in DNS or MDNS. The > publication normally discloses information about the device > publishing the services. There are use cases where devices want to > communicate without disclosing their identity, for example two mobile > devices visiting the same hotspot. >=20 > We propose to solve this problem by a two-stage approach. In the > first stage, hosts discover Private Discovery Service Instances via > DNS-SD using special formats to protect their privacy. These service > instances correspond to Private Discovery Servers running on peers. > In the second stage, hosts directly query these Private Discovery > Servers via DNS-SD over TLS. A pairwise shared secret necessary to > establish these connections is only known to hosts authorized by a > pairing system. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd >=20 From nobody Wed Jun 22 15:11:25 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D11D712DCE7 for ; Wed, 22 Jun 2016 15:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id upOMtEoaS5aQ for ; Wed, 22 Jun 2016 15:11:21 -0700 (PDT) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CF0112DCE6 for ; Wed, 22 Jun 2016 15:11:21 -0700 (PDT) Received: from [10.9.9.212] (helo=mailfront12.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1bFqMg-0001uT-Lu; Thu, 23 Jun 2016 00:11:18 +0200 Received: from c-24-5-43-153.hsd1.ca.comcast.net ([24.5.43.153] helo=[192.168.29.128]) by mailfront12.runbox.com with esmtpsa (uid:871115 ) (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1bFqMS-00086x-Ro; Thu, 23 Jun 2016 00:11:05 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alf Watt In-Reply-To: Date: Wed, 22 Jun 2016 15:11:01 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <814527C7-4C4B-436F-A68E-4FDB8687FC15@istumbler.net> References: <20160610193457.18214.76825.idtracker@ietfa.amsl.com> To: "dnssd@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Daniel Kaiser , Christian Huitema Subject: Re: [dnssd] New Version Notification for draft-huitema-dnssd-privacy-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2016 22:11:24 -0000 I think the threat analysis and enumeration of privacy implication is = very well done and very helpful. The suggested mechanism for private service advertising is well thought = out and an interesting method, but it=E2=80=99s worth mentioning two = important points: - =E2=80=9CPairing=E2=80=9D (S 4.1) does solve an important security = problem but I don=E2=80=99t think that the scope of pairing is a good = fit with service discovery: which is typically between members of a = group (i.e. family, workplace or school, etc) which can be larger than = two people. - An older, wiser, IETF member once pointed out to me that RFCs are not = the best place to do protocol design: they are a good way to codify = existing protocols so that vendors can develop interoperable = implementations. In order to get these protocols implemented in real = devices we need to outline the use cases and requirements for private = service discovery so that vendors can consider if they want to implement = them. I=E2=80=99m interested in writing up those requirements, but = unfortunately I=E2=80=99m only available volunteer hours for this work = at the moment so it could take a while before I can get to it. Best, Alf > On Jun 10, 2016, at 1:02 PM, Christian Huitema = wrote: >=20 > Here is a new version of the "DNS-SD Privacy" draft. I co-authored it = with Daniel Kaiser. Daniel is completing his PhD at the University of = Konstanz, in Germany, studying issues related to privacy and discovery. = This new draft is in my opinion much improved from the version 00 that I = presented in Buenos Aires. You can read the abstract below for the broad = lines of the proposed solution. Or, better yet, read the draft and = comment! >=20 > -- Christian Huitema >=20 >=20 >=20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 > Sent: Friday, June 10, 2016 12:35 PM > To: Christian Huitema ; Daniel Kaiser = > Subject: New Version Notification for = draft-huitema-dnssd-privacy-01.txt >=20 >=20 > A new version of I-D, draft-huitema-dnssd-privacy-01.txt > has been successfully submitted by Christian Huitema and posted to the = IETF repository. >=20 > Name: draft-huitema-dnssd-privacy > Revision: 01 > Title: Privacy Extensions for DNS-SD > Document date: 2016-06-10 > Group: Individual Submission > Pages: 26 > URL: = https://www.ietf.org/internet-drafts/draft-huitema-dnssd-privacy-01.txt > Status: = https://datatracker.ietf.org/doc/draft-huitema-dnssd-privacy/ > Htmlized: = https://tools.ietf.org/html/draft-huitema-dnssd-privacy-01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-huitema-dnssd-privacy-01 >=20 > Abstract: > DNS-SD allows discovery of services published in DNS or MDNS. The > publication normally discloses information about the device > publishing the services. There are use cases where devices want to > communicate without disclosing their identity, for example two = mobile > devices visiting the same hotspot. >=20 > We propose to solve this problem by a two-stage approach. In the > first stage, hosts discover Private Discovery Service Instances via > DNS-SD using special formats to protect their privacy. These = service > instances correspond to Private Discovery Servers running on peers. > In the second stage, hosts directly query these Private Discovery > Servers via DNS-SD over TLS. A pairwise shared secret necessary to > establish these connections is only known to hosts authorized by a > pairing system. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. >=20 > The IETF Secretariat >=20 > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd >=20 From nobody Thu Jun 23 11:52:00 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C2BB12D668 for ; Thu, 23 Jun 2016 11:51:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 NZa6vaivNxtv for ; Thu, 23 Jun 2016 11:51:58 -0700 (PDT) Received: from xsmtp03.mail2web.com (xsmtp03.mail2web.com [168.144.250.223]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F27F812D63E for ; Thu, 23 Jun 2016 11:51:57 -0700 (PDT) Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bG9jH-0004ax-N0 for dnssd@ietf.org; Thu, 23 Jun 2016 14:51:56 -0400 Received: (qmail 27231 invoked from network); 23 Jun 2016 18:51:54 -0000 Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.160.201]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Jun 2016 18:51:54 -0000 From: "Christian Huitema" To: "'S Moonesamy'" , "'Tim Chown'" References: <6.2.5.6.2.20160623020221.0b6b9df0@resistor.net> In-Reply-To: <6.2.5.6.2.20160623020221.0b6b9df0@resistor.net> Date: Thu, 23 Jun 2016 11:51:52 -0700 Message-ID: <001501d1cd80$4f885de0$ee9919a0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQF4CwMzLPfj2ndSRfVTW988tEw+yAFsu5GZAWyjbx6glB1+MA== Content-Language: en-us Archived-At: Cc: dnssd@ietf.org, 'Ralph Droms' Subject: Re: [dnssd] [ietf-privacy] Fwd: draft-huitema-dnssd-privacy-01.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jun 2016 18:51:59 -0000 (Moving this conversation to DNS-SD mailing list) On Thursday, June 23, 2016 2:53 AM, S Moonesamy wrote: > > Hi Tim, > At 05:18 22-06-2016, Tim Chown wrote: > >We're encouraging discussion of privacy considerations in the WG. As a > >result, we now have a draft (see below), including an initial proposal > >for a solution, for which we'd welcome wider review. The draft also > >addresses mDNS/DNS-SD privacy within single subnet scenarios. > > One of the privacy issue identified in the draft (Section 2.4) is device > fingerprinting. In Section 3.1, it is proposed to solve the privacy issues > described in Section 2.1 by obfuscating instance names. If I had to pick one > privacy threat for that I would choose "correlation". Obfuscating service names > would not address that. Section 3 describes an initial design that was then abandoned. I guess that in the next revision we could just remove that section entirely. On the other hand, the proposal was indeed to use different obfuscated names at different locations. > If I understood the draft correctly, the solution "to prevent tracking over time > and location, different string values would be used at different locations, or at > different times". QR-codes are used to generate a shared secret and establish > trust between two or more "friends". The private discovery service relies on pre-existing pairings. The pairing solutions are only drafted in very vague terms in the draft. I really wonder whether we should go define a complete pairing protocol. Is that in-charter for DNS-SD? What about competing with existing solutions over Bluetooth, Wi-Fi, and certainly many more? -- Christian Huitema From nobody Thu Jun 23 17:23:14 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D76412D5CC for ; Thu, 23 Jun 2016 17:23:13 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i3nDxznDILP3 for ; Thu, 23 Jun 2016 17:23:11 -0700 (PDT) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C526012B042 for ; Thu, 23 Jun 2016 17:23:10 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id p10so128016384qke.3 for ; Thu, 23 Jun 2016 17:23:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=nr3F034GZFW4PhxGZzeJ8EzU6KPM+zZ7PHV9fVmii8E=; b=IWveOJ2pbBYfrieitf7Sg0qFagJ714fZRVx/EsZ2ehiD7PaXioTHR5CHUj05KGY+J2 CABCgoB7BLdGVOER/0/lVyU9wFGoGWR9oweu7l+vM4/FMQoAPp0EfuW5aQk8oqy7Hi2o xLKf3fDBXu17/eZ1T/qNh6bOkzf+j/C3DUJbDMcstGunQ4uMeclUXwq7AggDSrMZlLqQ P/snDcevoLq8lDLrO+xPO81YuSiFZ/mtgJTuIhTHAOScEMYlBqw8JnKDjLvNQvO17zP2 HDTbL+exCB3pLCLocjLneGO9kRZLtuUYJRusBV7QhSLRMvkGU4da054OqwHS/Ih8BCLz Vdfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=nr3F034GZFW4PhxGZzeJ8EzU6KPM+zZ7PHV9fVmii8E=; b=lUNXN2aKPIwGtc2jgOaoK455dmcGu94SofEporfnQAVa0VjuBxXtuI3AF5mO4acfOp Z8mr0InCcgDqixdQ4QhDjkW5Ri6BqelUWnaHE5U8Chtd4jdTfOi7s0H90TxmpjRylzZI 4LoVo6iB7LduQvUO78wJ4okQ2I7CvmJYniGeef73uMV1RI7gCf1Dkz3u5VQvVxdEdDu1 OireRXEsBqWQrAwtIGwxvtLw/s2v6rSRHR8QPJ+74Djes4bNx3H/6PA8X8BsGcROCOoM zHiOOzHnwmnsvZdoDzUsEUOPpu2P2Z+L5i50Py1Rg/oS25Msd0eqwvt+b+6lRWaeto2u kKYg== X-Gm-Message-State: ALyK8tJTChc6jONsCnmGDGeEqQCv0oDoZssgBJWJE0gTY/9LZta2iS1YMJ/A1REuNty8PpdjtDFbbt7K8YxF+g== X-Received: by 10.55.118.196 with SMTP id r187mr1478188qkc.32.1466727789984; Thu, 23 Jun 2016 17:23:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Thu, 23 Jun 2016 17:23:09 -0700 (PDT) From: Martin Thomson Date: Fri, 24 Jun 2016 10:23:09 +1000 Message-ID: To: Christian Huitema , dnssd@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dnssd] dnssd privacy draft X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 00:23:13 -0000 Interesting work. I think that a lot of this comes down to the design of the pairing protocol. The requirement to use base64 isn't going to work very well with DNS. Or do you expect this to work anyway? I guess that it could if you use the URL and filename safe variant without padding, but I wouldn't have been that bold. Using base32 reduces the number of pairings you can advertise at once to 5; which isn't great, but I guess that you can use the mitigation you already have. But it begs the question: does this really need to be in the name? Did you consider retrieving the proofs using TXT records that are provisioned against the nonce? Do you need to include the time in the nonce? We decided against leaking clock information in TLS 1.3 for a range of reasons, primarily privacy. I believe that lots of entropy would be OK. It's not like we need to be very careful with space, and 96 bits seems like plenty. Also, you don't have to base64 the psk_identity, it's just octets, which allows you to reclaim some of that space. Did you consider using SNI to carry the name? Or did you plan to forbid SNI? You probably don't need to correlate the DNSSD parts with the TLS parts for passive observers. Regarding this: "Implementers MAY eventually replace SHA256 with a stronger algorithm", I think that you need a better replacement plan. Maybe you can use an attribute in the TXT record that identifies the hash. Or you could identify the scheme in the psk_identity itself. Or you could prefix names with a protocol version identifier. You could even use a different service type name if it came to that. From nobody Fri Jun 24 09:06:16 2016 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C89F712DCF7; Fri, 24 Jun 2016 09:00:54 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160054.10933.22999.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:54 -0700 Archived-At: Cc: dnssd@ietf.org, terry.manderson@icann.org Subject: [dnssd] dnssd - Requested session has been scheduled for IETF 96 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:56 -0000 Dear Ralph Droms, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnssd Session 1 (1:30:00) Wednesday, Afternoon Session I 1400-1530 Room Name: Charlottenburg II/III size: 175 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: Ralph Droms Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: 6man dnsop homenet dprive dbound dhc 6lo iccrg icnrg Second Priority: roll core t2trg irtfopen dane 6tisch Special Requests: --------------------------------------------------------- From nobody Fri Jun 24 12:26:43 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3B2412D5BE for ; Fri, 24 Jun 2016 12:26:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 SQY56kHq1x6w for ; Fri, 24 Jun 2016 12:26:40 -0700 (PDT) Received: from xsmtp12.mail2web.com (xsmtp12.mail2web.com [168.144.250.177]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E313612B05F for ; Fri, 24 Jun 2016 12:26:39 -0700 (PDT) Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bGWkQ-0007P0-21 for dnssd@ietf.org; Fri, 24 Jun 2016 15:26:38 -0400 Received: (qmail 5848 invoked from network); 24 Jun 2016 19:26:37 -0000 Received: from unknown (HELO huitema2) (Authenticated-user:_huitema@huitema.net@[131.107.160.201]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Jun 2016 19:26:37 -0000 From: "Christian Huitema" To: "'Martin Thomson'" , "'Christian Huitema'" , References: In-Reply-To: Date: Fri, 24 Jun 2016 12:26:34 -0700 Message-ID: <04a901d1ce4e$52e056e0$f8a104a0$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIN3TkVMGpjbbwR26PjQrGFtNYdfJ+Aysqg Content-Language: en-us Archived-At: Subject: Re: [dnssd] dnssd privacy draft X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 19:26:42 -0000 On Thursday, June 23, 2016 5:23 PM, Martin Thomson wrote: > > Interesting work. Thanks. > I think that a lot of this comes down to the design of the pairing protocol. Yes. The point is, do we have the appetite to design a pairing protocol in this group? If we do, my preference would be to describe this pairing protocol in a separate draft. > The requirement to use base64 isn't going to work very well with DNS. > Or do you expect this to work anyway? I guess that it could if you use the URL > and filename safe variant without padding, but I wouldn't have been that bold. It is already a requirement for DNS SD. There is a long discussion of that in RFC 6763: The portion of the Service Instance Name is a user- friendly name consisting of arbitrary Net-Unicode text [RFC5198]. It MUST NOT contain ASCII control characters (byte values 0x00-0x1F and 0x7F) [RFC20] but otherwise is allowed to contain any characters, without restriction, including spaces, uppercase, lowercase, punctuation -- including dots -- accented characters, non-Roman text, and anything else that may be represented using Net-Unicode. For discussion of why the name should be a user-visible, user- friendly name rather than an invisible machine-generated opaque identifier, see Appendix C, "What You See Is What You Get". Base64 guarantees that we will not be using control characters. I actually checked whether we could get something more compact using a wider range of Unicode character, but those require more bits on the wire and end up not very efficient. > Using base32 reduces the number of pairings you can advertise at once to 5; > which isn't great, but I guess that you can use the mitigation you already have. > But it begs the question: does this really need to be in the name? Did you > consider retrieving the proofs using TXT records that are provisioned against > the nonce? Yes, that's a possibility. But the instance name is obtained directly from the PTR record. Putting the information in the TXT record implies a longer query process: first get the PTR records, then retrieve the TXT record for each name in the PTR record. > Do you need to include the time in the nonce? We decided against leaking > clock information in TLS 1.3 for a range of reasons, primarily privacy. I believe > that lots of entropy would be OK. It's not like we need to be very careful with > space, and 96 bits seems like plenty. Are you saying that specifically for the PSK identity encoding? The use of time stamp there provides some level of protection against replay attacks, described in section 6.5. Otherwise, servers will have to rely on extended memory of previously used PSK identifiers. > Also, you don't have to base64 the psk_identity, it's just octets, which allows > you to reclaim some of that space. Well, section 5.1. of RFC4279 says: "The PSK identity MUST be first converted to a character string, and then encoded to octets using UTF-8 [UTF8]." And I see the character string requirement enforced in some of the TLS API. So base64 is just a way of being cautious. > Did you consider using SNI to carry the name? Or did you plan to forbid SNI? > You probably don't need to correlate the DNSSD parts with the TLS parts for > passive observers. Good point. We should probably specify some fixed SNI value, so the SNI does not leak server identity. > Regarding this: "Implementers MAY eventually replace SHA256 with a stronger > algorithm", I think that you need a better replacement plan. > Maybe you can use an attribute in the TXT record that identifies the hash. Or > you could identify the scheme in the psk_identity itself. > Or you could prefix names with a protocol version identifier. You could even > use a different service type name if it came to that. Yes, we need to think about versioning. The simplest solution is probably to encode a version number in the service type used by DNS SD. But better suggestions are welcome. -- Christian Huitema From nobody Sun Jun 26 17:32:32 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 254C212D1AE for ; Sun, 26 Jun 2016 17:32:30 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sR8NM-qgUUMa for ; Sun, 26 Jun 2016 17:32:28 -0700 (PDT) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::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 70DEC12D1A5 for ; Sun, 26 Jun 2016 17:32:28 -0700 (PDT) Received: by mail-qt0-x22a.google.com with SMTP id w59so15615224qtd.3 for ; Sun, 26 Jun 2016 17:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NjywjnYwN6DwHWm/VVu4WVbbAyenRSzi+hpdcaRyI0M=; b=FCpzHJbjrWHuLQTZkSJF6r14YCeBmlhbcBNZxw9Y0pLhxLN4e7CSXBqvIpSZMlm+AW 6D5CfDtWwobxYkcbStNfRj9/pAY54bTk7xTkLZhqhbNKp4GTBhdNzAv7Edy6X3BikK2I txmSPz0rSzb6Zqy4a0hNF14q8BMuc5+CS/j3RtbW2gxEkcNxuLYoxCAojXUamxp5eul6 leFKD5LAGoGrOWvPgLwV7ERTCnKoxoNqntaCX7dXTGuFjmy8og+4Ntak31V8dsLeK1z8 cM6zoRCdgsWvG2+J7Ij0z81qL6U1RQMxabU0Wn7vsUmuQKf/5AtK5GoWaUyrRNNb+JHm LdcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NjywjnYwN6DwHWm/VVu4WVbbAyenRSzi+hpdcaRyI0M=; b=KyO+Zdem1m98bZq+uZqKnvmEZs+8eJswo/BuOQrUvFYIQwGdKlFqoqvrBdgrus+cMx t+s7vktfKq58FlNQTivgjkuZCc9RBuLe4SJEqxMJXqItTNM7FX4QJUR9BSfzlcz12SGA hbLqTbN8KGkrJaAyQrW4d5kmm9xdFFzFRK6kxXNd4xVi4ERw8SSXH0lIAntN8aqOWt73 4rjWYu+12e61pL99tbMDYpwR2XuUbHQ1lJewLm4/XrgT0LXTFfN3W4MVc0vBuAMprul0 EiTO+2mPZsCrmrfJH1SUuR08wN5T262QwFEUJ7dUMz4ucW8PZXM/tzH0ofMgypGmC2m8 ediA== X-Gm-Message-State: ALyK8tKpmdIyhwGBGmBMb8zASiioPV//nRXIB6TbVKYpOKsW8PMjw6Yk5dZFOmmKjSrhSi9iKQTMF+qS4+a2Dg== X-Received: by 10.200.42.161 with SMTP id b30mr19761819qta.94.1466987547445; Sun, 26 Jun 2016 17:32:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Sun, 26 Jun 2016 17:32:26 -0700 (PDT) In-Reply-To: <04a901d1ce4e$52e056e0$f8a104a0$@huitema.net> References: <04a901d1ce4e$52e056e0$f8a104a0$@huitema.net> From: Martin Thomson Date: Mon, 27 Jun 2016 10:32:26 +1000 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christian Huitema , dnssd@ietf.org Subject: Re: [dnssd] dnssd privacy draft X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 00:32:30 -0000 On 25 June 2016 at 05:26, Christian Huitema wrote: > Yes. The point is, do we have the appetite to design a pairing protocol in > this group? If we do, my preference would be to describe this pairing > protocol in a separate draft. Sounds like hard work :) Might be worth doing though. >> The requirement to use base64 isn't going to work very well with DNS. >> Or do you expect this to work anyway? I guess that it could if you use > the URL >> and filename safe variant without padding, but I wouldn't have been that > bold. > > It is already a requirement for DNS SD. OK, my fault for assuming that PTR meant that there was a domain name in the response. >> space, and 96 bits seems like plenty. > > Are you saying that specifically for the PSK identity encoding? The use of > time stamp there provides some level of protection against replay attacks, > described in section 6.5. Otherwise, servers will have to rely on extended > memory of previously used PSK identifiers. What sort of replay are you concerned about? An attacker can replay the ClientHello, and maybe the 0-RTT data that is included, but that's all. The simplest mitigation for that is to not permit 0-RTT; well, on the first attempt anyway. At that point, there is fresh entropy from the server every time. (I assume here that you aren't looking to aggressively shave every last RTT from the protocol; you just added a bunch with the indirection step.) (That point on resumption makes me think: you might want to add a fixed octet at the start of psk_identity so that a server can distinguish between nonces and its own resumption psk_identity values. It could distinguish based on length, I suppose, but that is a little inconvenient.) >> Also, you don't have to base64 the psk_identity, it's just octets, which > allows >> you to reclaim some of that space. > > Well, section 5.1. of RFC4279 says: "The PSK identity MUST be first > converted to a character string, and then encoded to octets using UTF-8 > [UTF8]." And I see the character string requirement enforced in some of the > TLS API. So base64 is just a way of being cautious. Damn you 4279 for adding useless constraints! TLS 1.3 says nothing of the sort about the field. Nonetheless, I understand the caution now. From nobody Sun Jun 26 21:18:25 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2766612D536 for ; Sun, 26 Jun 2016 21:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cm4pdydqi3Oo for ; Sun, 26 Jun 2016 21:18:18 -0700 (PDT) Received: from aibo.runbox.com (aibo.runbox.com [91.220.196.211]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2E212D0BF for ; Sun, 26 Jun 2016 21:18:17 -0700 (PDT) Received: from [10.9.9.210] (helo=mailfront10.runbox.com) by bars.runbox.com with esmtp (Exim 4.71) (envelope-from ) id 1bHNzt-0006MK-Mj; Mon, 27 Jun 2016 06:18:09 +0200 Received: from c-24-5-43-153.hsd1.ca.comcast.net ([24.5.43.153] helo=[192.168.29.198]) by mailfront10.runbox.com with esmtpsa (uid:871115 ) (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) id 1bHNzl-0001GK-J4; Mon, 27 Jun 2016 06:18:01 +0200 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alf Watt In-Reply-To: Date: Sun, 26 Jun 2016 21:17:58 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <1674621C-3632-4F32-8552-8625D0BCE1DE@istumbler.net> References: <04a901d1ce4e$52e056e0$f8a104a0$@huitema.net> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Christian Huitema , dnssd@ietf.org, Christian Huitema Subject: Re: [dnssd] dnssd privacy draft X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 04:18:25 -0000 Opportunistic Encryption using the Internet Key Exchange (IKE) might be = suitable for the purposes proposed here. https://tools.ietf.org/html/rfc4322 Best, Alf > On Jun 26, 2016, at 5:32 PM, Martin Thomson = wrote: >=20 > On 25 June 2016 at 05:26, Christian Huitema = wrote: >> Yes. The point is, do we have the appetite to design a pairing = protocol in >> this group? If we do, my preference would be to describe this pairing >> protocol in a separate draft. >=20 > Sounds like hard work :) Might be worth doing though. From nobody Sun Jun 26 21:24:48 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABE8E12B010 for ; Sun, 26 Jun 2016 21:24:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 JhfbGUeyi1pC for ; Sun, 26 Jun 2016 21:24:45 -0700 (PDT) Received: from xsmtp02.mail2web.com (xsmtp02.mail2web.com [168.144.250.215]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BF84128B44 for ; Sun, 26 Jun 2016 21:24:45 -0700 (PDT) Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1bHO6C-0004ap-3m for dnssd@ietf.org; Mon, 27 Jun 2016 00:24:44 -0400 Received: (qmail 31375 invoked from network); 27 Jun 2016 04:24:39 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[24.16.156.113]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Jun 2016 04:24:39 -0000 From: "Christian Huitema" To: "'Martin Thomson'" References: <04a901d1ce4e$52e056e0$f8a104a0$@huitema.net> In-Reply-To: Date: Sun, 26 Jun 2016 21:24:31 -0700 Message-ID: <04c601d1d02b$cdd78600$69869200$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQIN3TkVMGpjbbwR26PjQrGFtNYdfAHJSn4EAhMQ1/ifZbg3EA== Content-Language: en-us Archived-At: Cc: 'Christian Huitema' , dnssd@ietf.org Subject: Re: [dnssd] dnssd privacy draft X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 04:24:46 -0000 On Sunday, June 26, 2016 5:32 PM, Martin Thomson wrote: > On 25 June 2016 at 05:26, Christian Huitema wrote: >> Are you saying that specifically for the PSK identity encoding? The use of >> time stamp there provides some level of protection against replay attacks, >> described in section 6.5. Otherwise, servers will have to rely on extended >> memory of previously used PSK identifiers. > > What sort of replay are you concerned about? An attacker can replay > the ClientHello, and maybe the 0-RTT data that is included, but that's > all. The simplest mitigation for that is to not permit 0-RTT; well, > on the first attempt anyway. At that point, there is fresh entropy > from the server every time. I am concerned with the privacy issue. Suppose I contact a server and send a Client-Hello with a PSK Identity. If the identity is valid, the servers replies with Server-Hello. If the identity is incorrect, server will reject the connection, maybe sending an Alert. Suppose now that the Client hello is a Replay from some exchange I monitored previously. If I see a Server Hello coming back, I know this is the same server that I observed before. Hence, linkability. -- Christian Huitema From nobody Sun Jun 26 21:59:02 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF217128E18 for ; Sun, 26 Jun 2016 21:59:00 -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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQ9zI8ysfpEB for ; Sun, 26 Jun 2016 21:58:59 -0700 (PDT) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d: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 6A214127078 for ; Sun, 26 Jun 2016 21:58:59 -0700 (PDT) Received: by mail-qk0-x234.google.com with SMTP id p10so195510244qke.3 for ; Sun, 26 Jun 2016 21:58:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PMj3Y7d3CHIiUNErKDddsFLDAJ+Xcokl/EAr2XMtdFw=; b=ANJiwZ2V8oM8hIO3FHM0W2OPSNFfnqrjWC1akuw8r8UbeVIBSQjw4/40pOyz8mS/tS Wo5Q0O7qc9sf6JX3Lv1ur2fu9+VHSen6K3t3LCq35r27DCaLouN24vj7QwPJ9TszJpJb a6r3fNB90HbJ5v65Tb5y5jlXjcbfywL3fO+f1/y+6thWT6mjJ8DFAKp6EKG5pWfGm6AS H/q+yUCYn7IR9rN2QKV6F1s1sMZtKeno+XSe257HwGLzq6KqWti6NLtBiL5vFBoahHh+ AcVjbwd6qgtaohFbs6UY/+5HkoADc1vCYsa7q1Dv28pvO/OcG/OCh1H9CDf/N6s1GxMZ huEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PMj3Y7d3CHIiUNErKDddsFLDAJ+Xcokl/EAr2XMtdFw=; b=az6jgB3EpzS5WlpeEmznTdNf1TPTwrOfAMO0dvGat9SUGEM5okrgcekSb2Fl00FhHy +8VHDufXa4iolO7U9ubd82NKW6x34ecfpNkRm4vaYfgMYgMUJRUi/Nr/8Qbj9flab2p9 sa3jybF7JvC43n4gFtrLJoEADmyqJ7bLcbCBSDJD3E6xspcmAWytQTxW/e7KZyTEpl2a WwtgTse4Oa6i9XCp2UejSHY0J9G7fR5jkFEDLqvmRqU6g5kcH1vdG0TtBABsWrZEfH3J u2o/8d16WiNcwEnIOaKK3ZyM2+rhASMkA7F0w6t/LTOW+wJurMl3Avrn4Lo1MiqPIXC1 WX5w== X-Gm-Message-State: ALyK8tIVeczCEt0w8s86ZU5UhrfxcVVnMvZqgUtbPbaQjBx9yW6Mxn+fC0aGK/baaMTy2OEpk1eRHhRZcp8lmQ== X-Received: by 10.55.18.194 with SMTP id 63mr19924733qks.199.1467003538591; Sun, 26 Jun 2016 21:58:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.22.38 with HTTP; Sun, 26 Jun 2016 21:58:58 -0700 (PDT) In-Reply-To: <04c601d1d02b$cdd78600$69869200$@huitema.net> References: <04a901d1ce4e$52e056e0$f8a104a0$@huitema.net> <04c601d1d02b$cdd78600$69869200$@huitema.net> From: Martin Thomson Date: Mon, 27 Jun 2016 14:58:58 +1000 Message-ID: To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Christian Huitema , dnssd@ietf.org Subject: Re: [dnssd] dnssd privacy draft X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 04:59:01 -0000 On 27 June 2016 at 14:24, Christian Huitema wrote: > I am concerned with the privacy issue. Suppose I contact a server and send a > Client-Hello with a PSK Identity. If the identity is valid, the servers > replies with Server-Hello. If the identity is incorrect, server will reject > the connection, maybe sending an Alert. Suppose now that the Client hello is > a Replay from some exchange I monitored previously. If I see a Server Hello > coming back, I know this is the same server that I observed before. Hence, > linkability. I see. You could include some material from the instance name in the calculation of the MAC that you are using for psk_identity. Then if the server moves, it's name will change, as will what it considers to be a valid handshake. From nobody Mon Jun 27 08:17:58 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00B5212D5C3 for ; Mon, 27 Jun 2016 08:17:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.11 X-Spam-Level: X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2e9Omxi-RU4t for ; Mon, 27 Jun 2016 08:17:48 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F8512D645 for ; Mon, 27 Jun 2016 08:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KUW4XNP3cYCsFqzGsyiRxUZzn/4r7mepNi8Sw8qRoMU=; b=gtP/f0a3LteH4onVaoNyLr+I8FFwNINzhgYLKUfZyuPdRXvS3F+DcGRR8SS/8wA6wQz3X/mZ/usLn1TKeugzAldHV9MYIz0Ohsi+8GooICLARa4Q5y4s15EQucFdsNzT2n8UvdWU42EjhYGa/af3E8Qqd6VJQnb/F6tAV1pfvQc= Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0082.outbound.protection.outlook.com [213.199.154.82]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-61-wICfgosYMaaG7RIKmKIaUw-1; Mon, 27 Jun 2016 16:11:05 +0100 Received: from DBXPR07MB462.eurprd07.prod.outlook.com (10.141.231.140) by DBXPR07MB462.eurprd07.prod.outlook.com (10.141.231.140) with Microsoft SMTP Server (TLS) id 15.1.517.8; Mon, 27 Jun 2016 15:11:05 +0000 Received: from DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) by DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) with mapi id 15.01.0517.016; Mon, 27 Jun 2016 15:11:05 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: dnssd WG status / tasks with IETF96 looming Thread-Index: AQHR0IYf3UOlfwAVC0ec3hKHjwwrOw== Date: Mon, 27 Jun 2016 15:11:04 +0000 Message-ID: <2F6594AC-5839-4C7F-86F5-4DF59FB005BC@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: 1673f091-7dcb-48f0-646e-08d39e9d4261 x-microsoft-exchange-diagnostics: 1; DBXPR07MB462; 20:mKPEo8AxbKoT2DeiAfj6zHmorOUuw49Hmgw7Z8kxqNDM2DQMjmgBNHeQQETcRen9TpOjeCpH3bd+mzd/rHnGaEXwSUk9NSR7sbQIQD3/Wnd8Tr6tR6XT6fnn5uesaC3OzlfMhv7mHabQoeI4VVXWmc0djNG/DA+L9m0+YLRlp4E= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB462; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:DBXPR07MB462; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB462; x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(189002)(57704003)(10400500002)(33656002)(16236675004)(50986999)(36756003)(8936002)(19580395003)(5640700001)(77096005)(83716003)(92566002)(50226002)(7906003)(7846002)(2501003)(15975445007)(7736002)(68736007)(66066001)(82746002)(57306001)(5002640100001)(106356001)(106116001)(229853001)(2351001)(2906002)(11100500001)(86362001)(3660700001)(105586002)(6116002)(3846002)(450100001)(102836003)(101416001)(97736004)(74482002)(189998001)(2900100001)(586003)(110136002)(107886002)(3280700002)(8676002)(19617315012)(122556002)(81166006)(87936001)(1730700003)(81156014)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB462; H:DBXPR07MB462.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; CAT:NONE; LANG:en; CAT:NONE; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2016 15:11:04.7432 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB462 X-MC-Unique: wICfgosYMaaG7RIKmKIaUw-1 Content-Type: multipart/alternative; boundary="_000_2F6594AC58394C7F86F54DF59FB005BCjiscacuk_" Archived-At: Subject: [dnssd] dnssd WG status / tasks with IETF96 looming X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 15:17:56 -0000 --_000_2F6594AC58394C7F86F54DF59FB005BCjiscacuk_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SGksDQoNClJhbHBoIGFuZCBJIGhhZCBhIGNoYXQgYXQgdGhlIGVuZCBvZiBsYXN0IHdlZWsgdG8g cmV2aWV3IHdoZXJlIHdlIGFyZSBvbiBkbnNzZCBXRyBpdGVtcy4gV2Ugd2lsbCBiZSBudWRnaW5n IHBlb3BsZSBvZmZsaW5lIGFjY29yZGluZ2x5Lg0KDQpUaGUgZm9ybWFsIGxpc3Qgb2YgZHJhZnRz IGNhbiBiZSBmb3VuZCBhdCBodHRwczovL3Rvb2xzLmlldGYub3JnL3dnL2Ruc3NkLy4NCg0KMSkg SHlicmlkIHByb3h5IGRyYWZ0DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1kbnNzZC1oeWJyaWQtMDMNClVwZGF0ZXMgd2VyZSBhZ3JlZWQgYXQgSUVURjk1OyBTdHVhcnQg dG8gYXBwbHksIGNoZWNrIFdHIGlzIGhhcHB5IGFsbCBjb21tZW50cyByZXNvbHZlZCwgdGhlbiBw dXNoIHRvIElFU0cNCg0KMikgTGFiZWwgaW50cm8gZHJhZnQNCmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWRuc3NkLW1kbnMtZG5zLWludGVyb3AtMDINCkRhdmUgVGhhbGVy IHRvIHRhbGsgdG8gQW5kcmV3IFN1bGxpdmFuIGFib3V0IGVkaXRvcmlhbCAobm9uIHNlbWFudGlj KSB1cGRhdGVzLCB0aGVuIHB1c2ggdG8gSUVTRy4NCg0KU28gd2UgZXhwZWN0IHRob3NlIHR3byBk cmFmdHMgdG8gYWR2YW5jZSB0byB0aGUgSUVTRyBiZWZvcmUvZHVyaW5nIElFVEY5Ni4NCg0KMykg RE5TIHB1c2ggZHJhZnQNClRvIGJlIHNwbGl0IGludG8gdHdvIHBhcnRzDQphKSBzZXNzaW9uIHNp Z25hbGxpbmcgZHJhZnQNCiAgICBSYXkgQmVsbGlzLCBTYXJhIERpY2tpbnNvbiwgQWxsaXNvbiBN YW5raW4gaGF2ZSBiZWVuIHdvcmtpbmcgd2l0aCBTdHVhcnQgYW5kIFRvbSAtIGRyYWZ0IGV4cGVj dGVkIGJ5IElFVEY5NiBjdXRvZmYsIHRvIGJlIHN1Ym1pdHRlZCB0byBkbnNvcCBXRw0KYikgRE5T IFB1c2gtc3BlY2lmaWMgcGFydA0KICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLWRuc3NkLXB1c2gtMDcNCiAgICBVcGRhdGUgdG8gY29tZSwgcmVtb3ZpbmcgdGhlIHNl c3Npb24gc2lnbmFsbGluZyBwYXJ0LCBiZWZvcmUgSUVURjk2Lg0KDQo0KSBtRE5TL0ROUy1TRCBw cml2YWN5IGRyYWZ0DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVpdGVtYS1k bnNzZC1wcml2YWN5LTAxDQpEcmFmdCBoYXMgYmVlbiB1cGRhdGVkIHdpdGggbmV3IGF1dGhvciBz aW5jZSBJRVRGOTUsIHN0ZXBwaW5nIGludG8gc29sdXRpb24gc3BhY2UuIFNsb3QgYWxyZWFkeSBh Z3JlZWQgZm9yIElFVEY5NiwgYW5kIGxpc3QgZGlzY3Vzc2lvbiBoYXBwZW5pbmcNCg0KVGhlcmUg YXJlIGFsc28gdHdvIG5ldyBkcmFmdHMgdGhhdCB3ZSBob3BlIHdl4oCZbGwgaGF2ZSBhdCBsZWFz dCBhIC0wMCBzdHJhd21hbiBmb3IgaW4gYWR2YW5jZSBvZiBCZXJsaW46DQoNCjUpIEEgbmV3IEkt RCBvbiByZWNvbW1lbmRhdGlvbnMgZm9yIHVzaW5nIHRoZSBoeWJyaWQgcHJveHksIGVzcGVjaWFs bHkgaW4gYSBjYW1wdXMtdHlwZSBlbnZpcm9ubWVudC4gV2hhdCBhcmUgdGhlIHByYWN0aWNhbCBk ZXBsb3ltZW50IGNvbnNpZGVyYXRpb25zPw0KICAgQXV0aG9ycyBhcmUgd2VsY29tZSENCg0KNikg QSBuZXcgSS1EIG9uIEROUyBVcGRhdGUgYW5kIG1kbnMvaHlicmlkIHByb3h5IGNvZXhpc3RlbmNl DQogICBUZWQgTGVtb24gdm9sdW50ZWVyZWQgdG8gZG8gYSAtMDAgaW4gQnVlbm9zIEFpcmVzOyBp dCB3b3VsZCBiZSB1c2VmdWwgdG8gaGF2ZSBzb21lIHRleHQgYmVmb3JlIElFVEY5Ng0KDQpUaGVy ZSBhcmUgc29tZSBvdGhlciBvcGVuIHF1ZXN0aW9ucyB0aGF0IHdlIG1heSB3aXNoIHRvIGRpc2N1 c3MgaW4gQmVybGluLCBidXQgdGhlIGFib3ZlIHRvcGljcyBhcmUgdGhlIHByaW9yaXR5Lg0KVGhv c2UgcXVlc3Rpb25zIGluY2x1ZGU6DQotIERvZXMgZHJhZnQtaWV0Zi1ob21lbmV0LWh5YnJpZC1w cm94eS16ZXJvY29uZi0wMiBuZWVkIHVwZGF0aW5nIGluIGxpZ2h0IG9mIHRoZSBwdWJsaWNhdGlv biBvZiBSRkMgNzc4OD8NCi0gRG8gd2UgaGF2ZSBvcGVuIHNvdXJjZSBoeWJyaWQgcHJveHkgaW1w bGVtZW50YXRpb25zIHRoYXQgY291bGQgYmUgdGVzdGVkIGJ5IHVuaXZlcnNpdHkgY2FtcHVzIG5l dHdvcmsgb3BlcmF0b3JzPw0KLSBXaGF0IHVzZXIgaW50ZXJmYWNlIGNvbnNpZGVyYXRpb25zIGV4 aXN0Pw0KLSBEbyB3ZSBuZWVkIHRvIHJldmlzaXQgZHJhZnQtYWdnYXJ3YWwtZG5zc2Qtb3B0aW1p emUtcXVlcnktMDA/DQotIEhvdyBkbyB3ZSB0YWtlIHRoZSB0aHJlYXRzIGRyYWZ0IGZvcndhcmQ/ IChkcmFmdC1vdGlzLWRuc3NkLXNjYWxhYmxlLWRucy1zZC10aHJlYXRzLTAzKQ0KLSBBbnl0aGlu ZyBlbHNlIHdlIG1pc3NlZD8NCg0KQ29tbWVudHMgd2VsY29tZSENCg0KVGltIGFuZCBSYWxwaA0K DQoNCg0K --_000_2F6594AC58394C7F86F54DF59FB005BCjiscacuk_ Content-Type: text/html; charset=UTF-8 Content-ID: <7397E0C3F02B21408F7F42F842AE02B6@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KSGksDQo8ZGl2IGNsYXNzPSIiPjxi ciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5SYWxwaCBhbmQgSSBoYWQgYSBjaGF0 IGF0IHRoZSBlbmQgb2YgbGFzdCB3ZWVrIHRvIHJldmlldyB3aGVyZSB3ZSBhcmUgb24gZG5zc2Qg V0cgaXRlbXMuIFdlIHdpbGwgYmUgbnVkZ2luZyBwZW9wbGUgb2ZmbGluZSBhY2NvcmRpbmdseS48 L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIi PlRoZSBmb3JtYWwgbGlzdCBvZiBkcmFmdHMgY2FuIGJlIGZvdW5kIGF0Jm5ic3A7PGEgaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy93Zy9kbnNzZC8iIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvd2cvZG5zc2QvPC9hPi48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjEpIEh5YnJpZCBwcm94eSBkcmFmdDwvZGl2Pg0KPGRp diBjbGFzcz0iIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0 Zi1kbnNzZC1oeWJyaWQtMDMiIGNsYXNzPSIiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1pZXRmLWRuc3NkLWh5YnJpZC0wMzwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VXBkYXRl cyB3ZXJlIGFncmVlZCBhdCBJRVRGOTU7IFN0dWFydCB0byBhcHBseSwgY2hlY2sgV0cgaXMgaGFw cHkgYWxsIGNvbW1lbnRzIHJlc29sdmVkLCB0aGVuIHB1c2ggdG8gSUVTRzwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+MikgTGFiZWwgaW50 cm8gZHJhZnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWlldGYtZG5zc2QtbWRucy1kbnMtaW50ZXJvcC0wMiIgY2xhc3M9IiI+ aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG5zc2QtbWRucy1kbnMtaW50 ZXJvcC0wMjwvYT48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+RGF2ZSBUaGFsZXIgdG8gdGFsayB0byBB bmRyZXcgU3VsbGl2YW4gYWJvdXQgZWRpdG9yaWFsIChub24gc2VtYW50aWMpIHVwZGF0ZXMsIHRo ZW4gcHVzaCB0byBJRVNHLjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp dj4NCjxkaXYgY2xhc3M9IiI+U28gd2UgZXhwZWN0IHRob3NlIHR3byBkcmFmdHMgdG8gYWR2YW5j ZSB0byB0aGUgSUVTRyBiZWZvcmUvZHVyaW5nIElFVEY5Ni48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+ PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjMpIEROUyBwdXNoIGRyYWZ0PC9k aXY+DQo8ZGl2IGNsYXNzPSIiPlRvIGJlIHNwbGl0IGludG8gdHdvIHBhcnRzPC9kaXY+DQo8ZGl2 IGNsYXNzPSIiPmEpIHNlc3Npb24gc2lnbmFsbGluZyBkcmFmdDwvZGl2Pg0KPGRpdiBjbGFzcz0i Ij4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMHB4OyBsaW5lLWhlaWdodDogbm9ybWFsOyIgY2xhc3M9 IiI+PHNwYW4gc3R5bGU9ImZvbnQta2VybmluZzogbm9uZSIgY2xhc3M9IiI+Jm5ic3A7ICZuYnNw OyBSYXkgQmVsbGlzLCBTYXJhIERpY2tpbnNvbiwgQWxsaXNvbiBNYW5raW4gaGF2ZSBiZWVuIHdv cmtpbmcgd2l0aCBTdHVhcnQgYW5kIFRvbSAtIGRyYWZ0IGV4cGVjdGVkIGJ5IElFVEY5NiBjdXRv ZmYsIHRvIGJlIHN1Ym1pdHRlZCB0byBkbnNvcCBXRzwvc3Bhbj48L2Rpdj4NCjwvZGl2Pg0KPGRp diBzdHlsZT0ibWFyZ2luOiAwcHg7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IiBjbGFzcz0iIj48c3Bh biBzdHlsZT0iZm9udC1rZXJuaW5nOiBub25lIiBjbGFzcz0iIj5iKSBETlMgUHVzaC1zcGVjaWZp YyBwYXJ0PC9zcGFuPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PGEg aHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG5zc2QtcHVzaC0w NyIgY2xhc3M9IiI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtZG5zc2Qt cHVzaC0wNzwvYT4mbmJzcDs8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Jm5ic3A7ICZuYnNwOyBVcGRh dGUgdG8gY29tZSwgcmVtb3ZpbmcgdGhlIHNlc3Npb24gc2lnbmFsbGluZyBwYXJ0LCBiZWZvcmUg SUVURjk2LiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+NCkgbUROUy9ETlMtU0QgcHJpdmFjeSBkcmFmdDwvZGl2Pg0KPGRpdiBj bGFzcz0iIj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaHVpdGVt YS1kbnNzZC1wcml2YWN5LTAxIiBjbGFzcz0iIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaHVpdGVtYS1kbnNzZC1wcml2YWN5LTAxPC9hPjwvZGl2Pg0KPGRpdiBjbGFzcz0iIj5E cmFmdCBoYXMgYmVlbiB1cGRhdGVkIHdpdGggbmV3IGF1dGhvciBzaW5jZSBJRVRGOTUsIHN0ZXBw aW5nIGludG8gc29sdXRpb24gc3BhY2UuIFNsb3QgYWxyZWFkeSBhZ3JlZWQgZm9yIElFVEY5Niwg YW5kIGxpc3QgZGlzY3Vzc2lvbiBoYXBwZW5pbmc8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+ DQpUaGVyZSBhcmUgYWxzbyB0d28gbmV3IGRyYWZ0cyB0aGF0IHdlIGhvcGUgd2XigJlsbCBoYXZl IGF0IGxlYXN0IGEgLTAwIHN0cmF3bWFuIGZvciBpbiBhZHZhbmNlIG9mIEJlcmxpbjo8L2Rpdj4N CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjUpIEEg bmV3IEktRCBvbiZuYnNwO3JlY29tbWVuZGF0aW9ucyBmb3IgdXNpbmcgdGhlIGh5YnJpZCBwcm94 eSwgZXNwZWNpYWxseSBpbiBhIGNhbXB1cy10eXBlIGVudmlyb25tZW50LiBXaGF0IGFyZSB0aGUg cHJhY3RpY2FsIGRlcGxveW1lbnQgY29uc2lkZXJhdGlvbnM/PGJyIGNsYXNzPSIiPg0KJm5ic3A7 ICZuYnNwO0F1dGhvcnMgYXJlIHdlbGNvbWUhPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz cz0iIj4NCjYpIEEgbmV3IEktRCBvbiBETlMgVXBkYXRlIGFuZCBtZG5zL2h5YnJpZCBwcm94eSBj b2V4aXN0ZW5jZTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4mbmJzcDsgJm5ic3A7VGVkIExlbW9uIHZv bHVudGVlcmVkIHRvIGRvIGEgLTAwIGluIEJ1ZW5vcyBBaXJlczsgaXQgd291bGQgYmUgdXNlZnVs IHRvIGhhdmUgc29tZSB0ZXh0IGJlZm9yZSBJRVRGOTY8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJy IGNsYXNzPSIiPg0KVGhlcmUgYXJlIHNvbWUgb3RoZXIgb3BlbiBxdWVzdGlvbnMgdGhhdCB3ZSBt YXkgd2lzaCB0byBkaXNjdXNzIGluIEJlcmxpbiwgYnV0IHRoZSBhYm92ZSB0b3BpY3MgYXJlIHRo ZSBwcmlvcml0eS48L2Rpdj4NCjxkaXYgY2xhc3M9IiI+VGhvc2UgcXVlc3Rpb25zIGluY2x1ZGU6 PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0gRG9lcyZuYnNwO2RyYWZ0LWlldGYtaG9tZW5ldC1oeWJy aWQtcHJveHktemVyb2NvbmYtMDIgbmVlZCB1cGRhdGluZyBpbiBsaWdodCBvZiB0aGUgcHVibGlj YXRpb24gb2YgUkZDIDc3ODg/PC9kaXY+DQo8ZGl2IGNsYXNzPSIiPi0gRG8gd2UgaGF2ZSBvcGVu IHNvdXJjZSBoeWJyaWQgcHJveHkgaW1wbGVtZW50YXRpb25zIHRoYXQgY291bGQgYmUgdGVzdGVk IGJ5IHVuaXZlcnNpdHkgY2FtcHVzIG5ldHdvcmsgb3BlcmF0b3JzPzwvZGl2Pg0KPGRpdiBjbGFz cz0iIj4tIFdoYXQgdXNlciBpbnRlcmZhY2UgY29uc2lkZXJhdGlvbnMgZXhpc3Q/Jm5ic3A7PGJy IGNsYXNzPSIiPg0KLSBEbyB3ZSBuZWVkIHRvIHJldmlzaXQmbmJzcDtkcmFmdC1hZ2dhcndhbC1k bnNzZC1vcHRpbWl6ZS1xdWVyeS0wMD88YnIgY2xhc3M9IiI+DQotIEhvdyBkbyB3ZSB0YWtlIHRo ZSB0aHJlYXRzIGRyYWZ0IGZvcndhcmQ/IChkcmFmdC1vdGlzLWRuc3NkLXNjYWxhYmxlLWRucy1z ZC10aHJlYXRzLTAzKTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj4tIEFueXRoaW5nIGVsc2Ugd2UgbWlz c2VkPzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xh c3M9IiI+Q29tbWVudHMgd2VsY29tZSE8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi Pg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+VGltIGFuZCBSYWxwaCZuYnNwOzwvZGl2 Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_2F6594AC58394C7F86F54DF59FB005BCjiscacuk_-- From nobody Mon Jun 27 08:23:25 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DB2912D76E for ; Mon, 27 Jun 2016 08:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVnbNAyX5zuI for ; Mon, 27 Jun 2016 08:23:22 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB93C12D747 for ; Mon, 27 Jun 2016 08:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=9oi5sVkYQnWCoymtX0Jev4rZ+zRLdTU8OKa9bE93dGE=; b=Il5Fbe7g9Hqsgqr937bivw6IU7hFkIQNJpx99YSI9KnZNyF/jIk2JIamYVGvNWReLiuUfsgwOf8VP6dikxHkmd1zHECzgaWUiSPnMuFv6kYfVZjIecqM3o3l5A5RZFMe9mMjD1QJGKuJO6iRXDumivAIC0yV5pXcQuIZwdw94IE= Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3lrp0078.outbound.protection.outlook.com [213.199.154.78]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-66-co6yXAUUMV635NSomayWGA-1; Mon, 27 Jun 2016 16:18:28 +0100 Received: from DBXPR07MB462.eurprd07.prod.outlook.com (10.141.231.140) by DBXPR07MB461.eurprd07.prod.outlook.com (10.141.231.139) with Microsoft SMTP Server (TLS) id 15.1.506.9; Mon, 27 Jun 2016 15:18:27 +0000 Received: from DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) by DBXPR07MB462.eurprd07.prod.outlook.com ([10.141.231.140]) with mapi id 15.01.0517.016; Mon, 27 Jun 2016 15:18:27 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: dnssd WG session @ IETF96 Thread-Index: AQHR0IcnxPQYxScYHEK9WeOjKSeTxA== Date: Mon, 27 Jun 2016 15:18:27 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [194.82.140.195] x-ms-office365-filtering-correlation-id: 312988b2-d751-4a81-020a-08d39e9e49fc x-microsoft-exchange-diagnostics: 1; DBXPR07MB461; 5:0hdWEvA1/YDxFTPdn6JMJ5zIkq9FT04pfbLVZ2K2oXAeSbO3iIXOKc25c4N5QPNIO+Bw5LmkRkwGgW1ZuNixfRjJylCRWGN8iLX1YCD0EjbAegPh+YvWBofaY3b3CjSenLnN86uXzh0ACl/KF/IWZQ==; 24:2V2l0Q8U7eXofpUyhzs2k5JFBF5y/j+ILgXh0A8RRpS/3nwjc6zBLIfTvkA61DJ71LOyhRVgBXILMoRMWbASMtDk2TUIzKvHbP66i67nEwk=; 7:pXLa3irNcl/vd/3bQK2B9BrA/PL1imvN4ZvUzS6TuY+pVa5linWDKBJh6v0e9KSTWreAaOiZdX2EjTf+NN90SQWhWwQdjE/wTn8Jv4mIgV0WocOAJ0wtX3Clshnfv0W946rXR2zd3ZZKHtCIQ9Gk/S5JnZRpUB5F3sDFQ6y/XywYkcUNGKxaMUe9HJEsCpXz; 20:hBEyvszrDnKSKMekJHicG7FuDSosHvkj0avcJLdiKaVCOBuYT1pNo4Y0HlQ3KPlWWdr3YX8Mbsk2EjuWIkF6zXw7vImDC8xoQXjKRpBd0KLRlviBeoSPVdT9eGz7wLGN6rb04OBB9jRlhXvObYYT9WDHe7tJ1VsIcEVjW/Fbowc= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DBXPR07MB461; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001); SRVR:DBXPR07MB461; BCL:0; PCL:0; RULEID:; SRVR:DBXPR07MB461; x-forefront-prvs: 09860C2161 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(66654002)(189002)(199003)(2501003)(7736002)(1730700003)(87936001)(122556002)(97736004)(7846002)(558084003)(3280700002)(106356001)(6116002)(77096005)(3660700001)(5002640100001)(11100500001)(2906002)(81156014)(50986999)(110136002)(2900100001)(305945005)(81166006)(8936002)(74482002)(92566002)(10400500002)(66066001)(229853001)(8676002)(68736007)(450100001)(101416001)(82746002)(107886002)(105586002)(189998001)(586003)(83716003)(106116001)(86362001)(3846002)(36756003)(2351001)(5640700001)(33656002)(57306001)(50226002)(102836003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB461; H:DBXPR07MB462.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <6F20FA7101E3E341A5CF3447FF1D1D21@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jun 2016 15:18:27.1344 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB461 X-MC-Unique: co6yXAUUMV635NSomayWGA-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [dnssd] dnssd WG session @ IETF96 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2016 15:23:24 -0000 Hi, Our session at Berlin is now finalised for 2pm - 3.30pm local time on Wedne= sday 20th July. Please send any requests for speaking slots to Ralph/me. Many thanks, Ralph & Tim=20 From nobody Mon Jun 27 18:30:57 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E587F12DAD4 for ; Mon, 27 Jun 2016 18:30:55 -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 (1024-bit key) header.d=dyn.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 o7Q480sigzC3 for ; Mon, 27 Jun 2016 18:30:54 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88DA12DAD0 for ; Mon, 27 Jun 2016 18:30:53 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id h190so4012462ith.1 for ; Mon, 27 Jun 2016 18:30:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dyn.com; s=google; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=UShj4sM57p27CXd9bvSPyTD4zR2coRrOkMzZvVM45Pw=; b=MHSJVTdLX5Yg58n+UrlKFKECu5V6l5c1W3pf8EjugODSl6E7qx4KXjtNKMJK5Q0F+n irrtlNA2zHlj21yjep4s3QaqQ1OIK43cx4Mn8j5Z7jVEamPD42dRbqocf1VBunEXiaTd 0i7RdmND75SS9l4Vc74eeaXqhvj0kefaJfQjs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=UShj4sM57p27CXd9bvSPyTD4zR2coRrOkMzZvVM45Pw=; b=H93pz5gLHkpcyyWUH3Uf1DHgfx+xt6NmdQhr4YWxbkgQZzl2y6etV0RI0xe8P3O+zS XOcykN7F+KIRZXTT6wWNgedVt42BeQXxeLr6KqeTsqy9ek9tmWKE4MckJi5K+hx4h5xM VXv3LwDb4LL2YMAhpkOmJ/EKtumrpYE1sQkPPJICQ5pFtoXO9e7ADfpbs3g/nsNmrqHN G9z5U4nqiKZl3uSmrR6I9akW9FK2lNDvowkjgVXlnjrCurQwSusDUhwyR+ETmwtIT8rg GRdyzQgErpeFHH1mVwo7pbUZVdpTQFKzdCwZ1DCYTNUoxJv0z6hAaceSS2ZlQ9CcXeXp zvUg== X-Gm-Message-State: ALyK8tI8bx1mcTU+1FO9xnoZvAVzBTIG+XmcRzZhGEU/cH9611sG3cEABz3pH+HHoEo5oHh5 X-Received: by 10.36.40.10 with SMTP id h10mr12538444ith.31.1467077452937; Mon, 27 Jun 2016 18:30:52 -0700 (PDT) Received: from dyn.com (192-0-220-231.cpe.teksavvy.com. [192.0.220.231]) by smtp.gmail.com with ESMTPSA id p21sm10584730iop.0.2016.06.27.18.30.51 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 27 Jun 2016 18:30:51 -0700 (PDT) Date: Mon, 27 Jun 2016 21:30:49 -0400 From: Andrew Sullivan To: dnssd@ietf.org Message-ID: <20160628013047.GB1891@dyn.com> References: <2F6594AC-5839-4C7F-86F5-4DF59FB005BC@jisc.ac.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2F6594AC-5839-4C7F-86F5-4DF59FB005BC@jisc.ac.uk> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [dnssd] dnssd WG status / tasks with IETF96 looming X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 01:30:56 -0000 On Mon, Jun 27, 2016 at 03:11:04PM +0000, Tim Chown wrote: > > 2) Label intro draft > https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-02 > Dave Thaler to talk to Andrew Sullivan about editorial (non semantic) updates, then push to IESG. > I asked about text on the list weeks ago, and heard nothing. Shall I go ahead with most of Dave's edits, do what I think best on the topics I asked about, and then send it to you? A -- Andrew Sullivan Dyn asullivan@dyn.com From nobody Tue Jun 28 03:09:23 2016 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3B6B12DD93 for ; Tue, 28 Jun 2016 03:09:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.111 X-Spam-Level: X-Spam-Status: No, score=-4.111 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=jisc365.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QSGzyWDPl-Ir for ; Tue, 28 Jun 2016 03:09:18 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A826612DD06 for ; Tue, 28 Jun 2016 03:07:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc365.onmicrosoft.com; s=selector1-jisc-ac-uk; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q3uOa1t7R6YCc0ZRibB7SGYbDdKL/N9Ms74AVJVlNnc=; b=LmH/hQEeiJYjUgmxP77UnFNrYIbzmphqoxZgncrOCixKbIVbicoBZRzrheN5RGDFIJeTyfz9wKeznBGHyQJ0wujZA1LvQvaaPcsmcflVyRotsK6rmQHatciBVXU87v7tweSLsFbX23hnbGyYcjO4rVIKfsSKELwZmQ1QwKJRl0M= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0216.outbound.protection.outlook.com [213.199.154.216]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-68-ubhlf8wdP2aFzH00iWh32g-1; Tue, 28 Jun 2016 11:07:22 +0100 Received: from AMSPR07MB455.eurprd07.prod.outlook.com (10.242.106.148) by AMSPR07MB453.eurprd07.prod.outlook.com (10.242.106.143) with Microsoft SMTP Server (TLS) id 15.1.506.9; Tue, 28 Jun 2016 10:07:19 +0000 Received: from AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) by AMSPR07MB455.eurprd07.prod.outlook.com ([10.242.106.148]) with mapi id 15.01.0528.017; Tue, 28 Jun 2016 10:07:19 +0000 From: Tim Chown To: Andrew Sullivan , Dave Thaler Thread-Topic: [dnssd] dnssd WG status / tasks with IETF96 looming Thread-Index: AQHR0IYfQsa2jCih6Uygyy6YcSxTXZ/+GFqAgACQYIA= Date: Tue, 28 Jun 2016 10:07:19 +0000 Message-ID: <8F28EBE1-EFD8-4BA4-B7B7-9743ADFD9E21@jisc.ac.uk> References: <2F6594AC-5839-4C7F-86F5-4DF59FB005BC@jisc.ac.uk> <20160628013047.GB1891@dyn.com> In-Reply-To: <20160628013047.GB1891@dyn.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:a88:d510:1101:7966:4d8e:2e2f:bae9] x-ms-office365-filtering-correlation-id: 7f1b8b02-2d0c-4693-6f2b-08d39f3bfdba x-microsoft-exchange-diagnostics: 1; AMSPR07MB453; 5:4gkKe9MVBd5z8Nya5nempw7mCsaYFPNCPH13uvgJleTZ5oeAzlwAuzhjf1jlGBziw2Q+i5KtgzYmENAPPM9PLiisrZMYJ3tBWqU/CGlYhjyVTWoa4DZKb8vyVVcD2mK0jH/r4IB0f4kgFytC0Z/tmg==; 24:4kNYnm0TYBds0093PEcGKogZxZN175b3Y87Sq/ywxAkKR/sIvmUe392n+7oN+aP3U6pEIWapRgLJUWW1JV3ZgWqNk2FO/osoQQ/wdQcoy3Y=; 7:DWX+WCKjsU3Fgp2LCjVmk4jcrbGC7d0buHQ7TpM8buhx4qSlvz2pH5S5hWYXGiXojqDil88beVLdZW/v1P+UhM2pG7UMvzjCQdnaVdljh1yDurcyKNoFYhYwJ+u8KyXD2soHDPhG7/4Jr9um7rDdm5/I/gl/CIoBPFpMzqsNJc5F4Ki2BA8p8/0nwxH5hQvJ; 20:Y6gxTTyQZMg7BvDV4Li53c/EzMSur+ACvN0UjWtnxzwEYcMn/qzw2EblV0pqxavlewz0xqU19GIoxM3dBQY5zEt+nUutyUXmvIHZqBhPOag0eI+xEZtKCItZ49L0nJVxPzFzaCDlFV4zD1pzSodQMJiP7qtI7cYrfSlxs71onME= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AMSPR07MB453; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(115145391015028); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:AMSPR07MB453; BCL:0; PCL:0; RULEID:; SRVR:AMSPR07MB453; x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(189002)(24454002)(2421001)(81156014)(81166006)(57306001)(106116001)(68736007)(36756003)(106356001)(2561002)(5001770100001)(105586002)(97736004)(11100500001)(92566002)(19580395003)(1511001)(33656002)(8666005)(305945005)(2906002)(7736002)(8936002)(4326007)(50226002)(8676002)(50986999)(10400500002)(2950100001)(83716003)(586003)(82746002)(122556002)(76176999)(86362001)(3280700002)(15975445007)(102836003)(19580405001)(2900100001)(3660700001)(5002640100001)(101416001)(77096005)(74482002)(7846002)(6116002)(87936001)(189998001)(3826002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:AMSPR07MB453; H:AMSPR07MB455.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <89D3574153C67448A6275052688E2A98@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2016 10:07:19.6221 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AMSPR07MB453 X-MC-Unique: ubhlf8wdP2aFzH00iWh32g-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "dnssd@ietf.org" Subject: Re: [dnssd] dnssd WG status / tasks with IETF96 looming X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 10:09:22 -0000 Hi Andrew, > On 28 Jun 2016, at 02:30, Andrew Sullivan wrote: >=20 > On Mon, Jun 27, 2016 at 03:11:04PM +0000, Tim Chown wrote: >>=20 >> 2) Label intro draft >> https://tools.ietf.org/html/draft-ietf-dnssd-mdns-dns-interop-02 >> Dave Thaler to talk to Andrew Sullivan about editorial (non semantic) up= dates, then push to IESG. >>=20 >=20 > I asked about text on the list weeks ago, and heard nothing. Shall I > go ahead with most of Dave's edits, do what I think best on the topics > I asked about, and then send it to you? Yes, please. I=92ve copied Dave explicitly above; obviously we=92d like to = get his feedback on your changes, as well as comments from anyone else in t= he WG who would care to do a final review. Ralph and I will discuss a shepherd for the document (volunteers welcome). =20 Tim