
From nobody Fri Nov  2 20:36:16 2018
Return-Path: <mohit.m.sethi@ericsson.com>
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 195EF130E09 for <dnssd@ietfa.amsl.com>; Fri,  2 Nov 2018 20:36:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.771
X-Spam-Level: 
X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=dpc76b7x; dkim=pass (1024-bit key) header.d=ericsson.com header.b=lajonTVi
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C0BlBB32D5pW for <dnssd@ietfa.amsl.com>; Fri,  2 Nov 2018 20:36:13 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E1351277C8 for <dnssd@ietf.org>; Fri,  2 Nov 2018 20:36:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1541216171; x=1543808171; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=MPWX4V9rLv0/ooonDoUBCouS+VhiH0ra4ct+wKrLgXU=; b=dpc76b7x2K8Ek9EZ+YHpt7CYMuFzvRPf3owrTlvDM71+tH0xF9890F2Ul06SKltx VDkzIdQTda1XTvpYEor/CQqVwfmlgxw+z+QJW1gNEbQFBLj+AkEoka2TfXAXhByE rMiH41k4qjk0BAacjRCzN8juwvKDpC5PMyeDi1RLxTE=;
X-AuditID: c1b4fb3a-9c3ff700000063b1-3c-5bdd17ab5757
Received: from ESESBMB502.ericsson.se (Unknown_Domain [153.88.183.115]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B5.19.25521.BA71DDB5; Sat,  3 Nov 2018 04:36:11 +0100 (CET)
Received: from ESESSMR503.ericsson.se (153.88.183.112) by ESESBMB502.ericsson.se (153.88.183.185) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 3 Nov 2018 04:36:10 +0100
Received: from ESESBMB504.ericsson.se (153.88.183.171) by ESESSMR503.ericsson.se (153.88.183.112) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 3 Nov 2018 04:36:11 +0100
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 3 Nov 2018 04:36:10 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=MPWX4V9rLv0/ooonDoUBCouS+VhiH0ra4ct+wKrLgXU=; b=lajonTViYADXXNMxCEzvpO3KgBw4mOr71PXheafNmVsgxKDSk+hCkVbJvWjyLJ0JIwtedczp3yojA/FmGIk7d1DvVmEiF4J2PxoZGaSHTyDwvWuEdBdM9AatpSykR9qqafQKrU+RMtNKwCBQ9TQyP1MccLdGpa4rv1RjVXri7FA=
Received: from VI1PR07MB4717.eurprd07.prod.outlook.com (20.177.54.82) by VI1PR07MB4110.eurprd07.prod.outlook.com (52.134.21.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.15; Sat, 3 Nov 2018 03:36:09 +0000
Received: from VI1PR07MB4717.eurprd07.prod.outlook.com ([fe80::8412:d8ae:dfa0:c61f]) by VI1PR07MB4717.eurprd07.prod.outlook.com ([fe80::8412:d8ae:dfa0:c61f%4]) with mapi id 15.20.1294.027; Sat, 3 Nov 2018 03:36:09 +0000
From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
To: "dnssd@ietf.org" <dnssd@ietf.org>
Thread-Topic: shared public-key vs bi-directional shared public-key
Thread-Index: AQHUcyZc9/bI6EZ0ekqJ/p2KETL/Mw==
Date: Sat, 3 Nov 2018 03:36:09 +0000
Message-ID: <9e7a0f41-9277-a0d7-a22a-144d10b145e8@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
x-originating-ip: [89.166.49.243]
x-clientproxiedby: AM6PR0202CA0064.eurprd02.prod.outlook.com (2603:10a6:20b:3a::41) To VI1PR07MB4717.eurprd07.prod.outlook.com (2603:10a6:803:69::18)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4110; 6:jgg0WywkFCxPHBG5eCH0c+gDH4ezptg6WX1ifIYhglC1Ch7yyzxP1JoPdmRfvDrSdGko4jpg1FgOW/YfIx8eYz5jLOThZYreCi4YRKjxYbCo8qMFhNGUO/IozRUceWV6eKf/lQGkGBzS6M1sHa1dhnV6zb8Fm0+gNaou8ybo86P9KUeOgJbleAaPqhOWTvwlituX5lbcXtvp4NEp8m/DNsIaPHySHlXvHQBD1OQl9gyFL6J92On2p1cH7Q7GkCoTTa9wqompxjGWHbNbE97xQLLXOByEjh+TOQqd7Le4pkvBLkuEv6l6hOv4Cf5bPUBewW2t/Bs4ZxBb5EPo348oDy4rilFR25JJ4rcP0iDF6TH4hCUpZwQq1kkxQIx+k9RSiPmOt9kqLyRpU4ZCcPPTQM0Mb6+09E1mHy/LK/eQxdWgDiOLRznlFxslKMdtJ/mOOlAtSX+rzu3hKMLXW5xHQQ==; 5:Giif/F40ybRbNyMu0QohLx4XUHdNNzRBju4CbFNOsMCzdJF5NLKd9uH94l5Y63tNbkD9aA3qvTILsFwuaQ6xd/9r6dF33ruz7QL36HusLU2+euqCgVvdVJSblxsQxI/CnGBStdIu8BIQxV4/1FzWX7woYXoyO9UZsna8uPSxa40=; 7:VkYaCS2QZUfLP8MW4H8Pq3AntiUfCPwaSBXcy8UU/yukDzg9jDIA1wD+iJ9xDxkWqgt8clmRAZRQjOg4Uce6vOYmf0VRq+0umFIeuyzKZIZColGDjJTQ7QNKt75/GaoIoeRtv4QQfm0yZoLpZofpOg==
x-ms-office365-filtering-correlation-id: 5d01ffe5-0392-4f40-97a7-08d6413d7dcc
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4110; 
x-ms-traffictypediagnostic: VI1PR07MB4110:
x-microsoft-antispam-prvs: <VI1PR07MB41105461EA31646E6CFA9A68D0C80@VI1PR07MB4110.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(190756311086443);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231382)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB4110; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4110; 
x-forefront-prvs: 08457955C4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(136003)(396003)(39860400002)(199004)(189003)(65956001)(36756003)(99286004)(7736002)(14454004)(256004)(14444005)(105586002)(3846002)(486006)(2616005)(6116002)(58126008)(476003)(106356001)(53936002)(2906002)(305945005)(5660300001)(1730700003)(81166006)(81156014)(2900100001)(52116002)(65806001)(65826007)(8936002)(8676002)(6486002)(64126003)(25786009)(71200400001)(2501003)(31696002)(316002)(478600001)(6916009)(386003)(6506007)(71190400001)(2351001)(97736004)(186003)(68736007)(31686004)(66066001)(5640700003)(86362001)(102836004)(26005)(6512007)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4110; H:VI1PR07MB4717.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: QoNAtXZEFlL8fC/xbRGoP0SX42iOcrZCEHAx80LKPArtvyMJC7KJwpNYvPOq4CBjfDtU4Us1U4kIU8zq4cLS7eRKPpbqDlL8IJhXPGjCOO0cd0MXkvSBLqZgaZ3RLymUTgUHUZsXj9zgIhiAJSYUD8x5Kcf0cTF/oPjSrUe+xlDar7cNTS8KnW8Rr8QCcEUFL6Wpn2iP07lqooMse1AHpK5QFVb7xdvPHWlvwnQOxxZYo/RpL9PasuH8kc98zRtGznnigQxzPuGchKzfOIe/2A5XP73yM9mkDJ5q5uVQf8pJqxQf4jzNq2Aj7WhpBbh22tpJQ0QNTNCFDuKwDahiO7/QnWKIw8RnKwa39u9nO/0=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <C22A7EC050EB60469A1B31778F56E676@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 5d01ffe5-0392-4f40-97a7-08d6413d7dcc
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2018 03:36:09.8508 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4110
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupkleLIzCtJLcpLzFFi42KZGbG9WHe1+N1og85NIhbvl85idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrFv25gLHklWPPv3kbGBsUeyi5GTQ0LARGLtxznMXYxcHEIC RxglJt57wAjhfGWU+HrhOTOcM3tpCxuEs5hJ4vjn1SwgDovABGaJM0veQfVMYJKY1vAIquch o8S73ZOZQdawCRhITJ6ygh3EFhFQleidc4oJxBYWsJO4/OgRI0TcWWJ6+0QmCFtP4sK3W2D1 LAIqEj27foDZvAL2EgcX/QGzGQXEJL6fWgNWzywgLnHryXwmiJcEJJbsOc8MYYtKvHz8jxXE FhWIkGg++ZcFIq4ocfbdQyaQQyUEZjJK/Gn9xwYxNFbiw/9+qEE6EmevP2GEsGUlLs3vhrKv sUmcOmoHYftKvO45xggx6DijxLeVc6A2a0l8e3mFHcLOlmjo2QM11Friwtc+qBo5iVW9D1km MBrNQvLELEYOIFtTYv0ufYiwh8Tqj5PZIGxFiSndD9lngcNCUOLkzCcsCxhZVzGKFqcWF+em GxnppRZlJhcX5+fp5aWWbGIEJpCDW35b7WA8+NzxEKMAB6MSD6+u6N1oIdbEsuLK3EOMEhzM SiK8X1rvRAvxpiRWVqUW5ccXleakFh9ilOZgURLndUqziBISSE8sSc1OTS1ILYLJMnFwSjUw sqUnOvjdm8i0v5rv0C/Bmg7jM6v+/tooorCQ72LetvAfr9N2LRQ+ox39lGnbNk+P0gumdheX 71zqNmNW6Ke74VOMT3o6ah19taAlVynDcvkF3o8vvJR/7TC6yFJuv/xFiNVVltsfv5T4HjmW vKbg3dTSjVx8awwdb+clcIh+eykcWBa+88ntTCWW4oxEQy3mouJEAEnemy4cAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/oXIxUweeo9_yKqwaGw_92OAGzYg>
Subject: [dnssd] shared public-key vs bi-directional shared public-key
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Nov 2018 03:36:15 -0000

SGkgRE5TU0QsDQoNCkF0IHRoZSBJRVRGIDEwMiBtZWV0aW5nLCBTdHVhcnQgd2FzIHByZXNlbnRp
bmcgdGhlIHZhcmlvdXMgb3B0aW9ucyBmb3IgDQpzZXJ2aWNlIGRpc2NvdmVyeS4gT25lIG9mIHRo
ZSBidWxsZXRzIG9uIGhpcyBzbGlkZXMgd2FzIHNoYXJlZCBwdWJsaWMta2V5Lg0KDQpJIHdhcyBh
dCB0aGUgbWlrZSBhc2tpbmcgcXVlc3Rpb25zIGFib3V0IHdoYXQgaXMgbWVhbnQgYnkgc2Vydmlj
ZSANCmRpc2NvdmVyeSB3aXRoIHNoYXJlZCBwdWJsaWMta2V5LiBJIHdhcyBleHBsaWNpdGx5IGlu
dGVyZXN0ZWQgdG8gDQp1bmRlcnN0YW5kIHdoYXQgdGhpcyB3b3VsZCBtZWFuIGluIHByYWN0aWNl
Pw0KDQpJIGhhZCB1bmRlcnN0b29kIHRoZSBzaGFyZWQgcHVibGljLWtleSBtb2RlIGZvciBkaXNj
b3ZlcnkgYXMgZm9sbG93czogYSANCnByaW50ZXIgaW4gYSBzaGFyZWQgb2ZmaWNlIHdpbGwgaGF2
ZSBhIFFSIGNvZGUgY29udGFpbmluZyBpdHMgcHVibGljLWtleSANCihvciBwb3NzaWJseSBhIGhh
c2ggb2YgdGhlIHB1YmxpYy1rZXkgdG8gcmVkdWNlIHRoZSBhbW91bnQgb2YgZW5jb2RlZCANCmlu
Zm9ybWF0aW9uIGluIHRoZSBRUiBjb2RlKS4gQW55Ym9keSB0aGF0IHdpc2hlcyB0byBkaXNjb3Zl
ciB0aGUgDQpwcmludGVyLCB3b3VsZCBmaXJzdCBzY2FuIHRoZSBRUiBjb2RlIHRvIG9idGFpbiB0
aGUgcHVibGljLWtleSBvZiB0aGUgDQpwcmludGVyLg0KDQpIb3dldmVyLCB0aGlzIHdvdWxkIG5v
dCBwcmV2ZW50IGEgcm9ndWUgaW52YXNpdmUgYXR0YWNrZXIgZnJvbSBjcmVhdGluZyANCmEgZGF0
YWJhc2Ugb2YgcHVibGljLWtleSBtYXBwaW5ncyB0byBhY3R1YWwgZGV2aWNlcyAoYW5kIHNlcnZp
Y2VzIA0Kb2ZmZXJlZCBieSB0aGUgZGV2aWNlKS4gVGhpcyBpcyBhbmFsb2dvdXMgdG8gd2FyLWRy
aXZpbmcgZm9yIGZyZWUgV2ktRmkgDQpuZXR3b3Jrcy4gQSBkYXRhYmFzZSBjb250YWluaW5nIHRo
ZSBsb25nLXRlcm0gcHVibGljLWtleSBvZiB0aGUgcHJpbnRlciANCndvdWxkIGFsbG93IGFuIGlu
dmFzaXZlIHBlcnNvbiB0byBtb25pdG9yIHRoZSBuZXR3b3JrIGZvciBtZXNzYWdlcyANCmNvbnRh
aW5pbmcgdGhlIHByaW50ZXJzIGxvbmctdGVybSBwdWJsaWMta2V5IChvciBtZXNzYWdlcyBzaWdu
ZWQgd2l0aCANCnRoZSBjb3JyZXNwb25kaW5nIHByaXZhdGUta2V5KS4gV2hlbmV2ZXIgYW4gaW5u
b2NlbnQgdXNlciB0cmllcyB0byB1c2UgDQp0aGUgZGV2aWNlIChhbmQgaXRzIHNlcnZpY2VzKSwg
dGhlIGludmFzaXZlIGF0dGFja2VyIHdvdWxkIGJlIGFibGUgdG8gDQpvYnNlcnZlIHRoaXMgYmVo
YXZpb3IuIFRoaXMgbWlnaHQgYmUgYWNjZXB0YWJsZSBpbiBzb21lIGNhc2VzIA0KKGFkbWl0dGVk
bHkgbm90IGFsbCkuDQoNCkJ1dCBzb21lb25lIHJlc3BvbmRlZCBhdCB0aGUgbWlrZSBsaW5lIHRo
YXQgSSB3YXMgaW5jb3JyZWN0IGFuZCB0aGF0IHlvdSANCmNhbiBpbmRlZWQgZGVyaXZlIGEgRGlm
ZmllLUhlbGxtYW4gc2hhcmVkIHNlY3JldCAodG8gc2VjcmV0bHkgZGlzY292ZXIgYSANCnNlcnZp
Y2UpIHdpdGhvdXQgZXZlciBzZW5kaW5nIGFueSBvZiB0aGUgbG9uZy10ZXJtIHB1YmxpYyBrZXlz
IG9uIHRoZSANCm5ldHdvcmsuDQoNCkkgYmVsaWV2ZSB0aGV5IHdlcmUgcmVmZXJyaW5nIHRvIHRo
ZSBpZGVhcyBwcmVzZW50ZWQgaW4gDQpkcmFmdC1icmFkbGV5LWRuc3NkLXByaXZhdGUtZGlzY292
ZXJ5LTAwLiBCdXQgdGhpcyBkcmFmdCBkb2VzIG5vdCBmb2xsb3cgDQoic2hhcmVkIHB1YmxpYy1r
ZXkiIG1vZGVsLiBJdCBmb2xsb3dzIHdoYXQgd291bGQgY29ycmVjdGx5IGJlIGNhbGxlZCBhcyAN
CiJiaS1kaXJlY3Rpb25hbCBzaGFyZWQgcHVibGljLWtleXMiLiBUaGUgZHJhZnQgYXNzdW1lcyB0
aGF0IGJvdGggdGhlIA0KY29tbXVuaWNhdGluZyBwYXJ0aWVzIGhhdmUgZWFjaCBvdGhlcnMgbG9u
ZyB0ZXJtIHB1YmxpYy1rZXkuIFRoaXMgd291bGQgDQpsaW1pdCBzb21lIHVzZS1jYXNlcy4gSSBj
YW4gZWFzaWx5IGZpbmQgdGhlIHByaW50ZXJzIGxvbmctdGVybSBwdWJsaWMgDQprZXkgYnkgc2Nh
bm5pbmcgYSBRUiBjb2RlLiBCdXQgaG93IGRvIEkgdGVsbCB0aGUgcHJpbnRlciBsb25nIHRlcm0g
DQpwdWJsaWMga2V5cyBvZiBteSBsYXB0b3Agb3IgcGhvbmU/DQoNCkl0IHdvdWxkIGJlIG5pY2Ug
aWYgZWFjaCBkcmFmdCBwcmVzZW50aW5nIGEgc29sdXRpb24gY291bGQgZ2l2ZSBhIA0KY29uY3Jl
dGUgZXhhbXBsZSBvbiBob3cgd291bGQgeW91IHVzZSB0aGUgc29sdXRpb24gaW4gdGhlIHJlYWwt
d29ybGQuDQoNCkkgd2lsbCBzZW5kIGEgbW9yZSB0ZWNobmljYWwgcmV2aWV3IG9mIA0KZHJhZnQt
YnJhZGxleS1kbnNzZC1wcml2YXRlLWRpc2NvdmVyeS0wMCBpbiBhIHNlcGFyYXRlIGVtYWlsLg0K
DQotLU1vaGl0DQoNCg==


From nobody Fri Nov  2 20:36:42 2018
Return-Path: <mohit.m.sethi@ericsson.com>
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 EC51B130E13 for <dnssd@ietfa.amsl.com>; Fri,  2 Nov 2018 20:36:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.771
X-Spam-Level: 
X-Spam-Status: No, score=-4.771 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=M62KbmNZ; dkim=pass (1024-bit key) header.d=ericsson.com header.b=iw96MCHm
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Khbx09Tu7ms for <dnssd@ietfa.amsl.com>; Fri,  2 Nov 2018 20:36:39 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 216F71277C8 for <dnssd@ietf.org>; Fri,  2 Nov 2018 20:36:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1541216197; x=1543808197; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=aAGJaoQk3avlsIohTmpgwmablHbJOn+ua7MnVKMPJAE=; b=M62KbmNZ5PSgbzlnANsmw3d99siUeE+QpDCk9Fxpw2FClmDwCyr9zfBHEjhsjSYb UmgrniPgtMOGZ2rOM1SHOMm537lzNp+saIcfate3VTEGayQ7K+LfLQ7ymndhxyLf 3ZfYR168xsTO7ZFwmapAhRIMtjMlb8r9R6gp81WWao4=;
X-AuditID: c1b4fb2d-425ff7000000434d-8e-5bdd17c55ac8
Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 25.BD.17229.5C71DDB5; Sat,  3 Nov 2018 04:36:37 +0100 (CET)
Received: from ESESBMB503.ericsson.se (153.88.183.170) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 3 Nov 2018 04:36:36 +0100
Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB503.ericsson.se (153.88.183.170) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 3 Nov 2018 04:36:36 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aAGJaoQk3avlsIohTmpgwmablHbJOn+ua7MnVKMPJAE=; b=iw96MCHmdhq+LQW4MHMxPccd0otRcPmWY5kO3W4WkqCczhenSKc6x5X98bWmMY0tX2/JEMweAlDqrq7xSpX3QbsMtM0emFYuDLJzy6hiM+zGRGJqc8EmlaNwAzseZnFLNFBNoB1Q+Bm9waAK5JgthiA9tipHjkKG6ygOU7dxyQY=
Received: from VI1PR07MB4717.eurprd07.prod.outlook.com (20.177.54.82) by VI1PR07MB4110.eurprd07.prod.outlook.com (52.134.21.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.15; Sat, 3 Nov 2018 03:36:36 +0000
Received: from VI1PR07MB4717.eurprd07.prod.outlook.com ([fe80::8412:d8ae:dfa0:c61f]) by VI1PR07MB4717.eurprd07.prod.outlook.com ([fe80::8412:d8ae:dfa0:c61f%4]) with mapi id 15.20.1294.027; Sat, 3 Nov 2018 03:36:36 +0000
From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
To: "dnssd@ietf.org" <dnssd@ietf.org>
Thread-Topic: Review of draft-bradley-dnssd-private-discovery-00
Thread-Index: AQHUcyZs7w//C950yEyaIw2A7G6sdg==
Date: Sat, 3 Nov 2018 03:36:36 +0000
Message-ID: <98e047be-bca9-9f7a-5012-5674c30244bf@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
x-originating-ip: [89.166.49.243]
x-clientproxiedby: HE1PR05CA0139.eurprd05.prod.outlook.com (2603:10a6:7:28::26) To VI1PR07MB4717.eurprd07.prod.outlook.com (2603:10a6:803:69::18)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB4110; 6:cT9ZdozU5e1NgyK2GsxMOn2aAZnpWTQWuD54oIb7dQYO86ZyC9keYesJ1hVsbtLGNAn3EkR1gC53oSf8aK6pRKIy/Uudqcu+Vq+Cjodg11EI2ew9xlm++qN+QMtkOUqzgPcgqcZ0/GyjUUSCzVRcBJlfDZOQICxK/4XcOftTOKXANwKbse/4WrS6jrLOsHpw3Mn8tKz5yuUIuXAaNkcmoT5iADdhwSUVDaRvOw/qGRZ91Z+yeRB8aPjzSvvmq77GKSiC4esDMGwfPMFdIXaP4mdxdbY053wIBfwFQf6LXEZaVGh87Xg2CJo9c3jGaHgTJOUJe3cj9A1YLs3umb87By598PLmovY6Ex8CCabFmuK4NW/3/MVncOyAow8DrTFv06JjF8bMnVgBOJQcMLcvS9y9Jjkp2ld4W5A7MCB+ZaNqoFb4i7OLL2hVfA5tSMcbQ69+ClN/SamaPJNQ/G0cJQ==; 5:uINsVKLBPKqyat6BOqeUYoj2Xljxs1voAFpsbvCJxTXqJ6RWbsE5F622kVQY9vRoDbk/9QhTSX1bSt7mFPd+igqWWOwI/Ht0YkHetBDTdOYLiBMMaT8hTJ5cHOElACO4frvUJgmBLQA2TgkEHpfEmbqKXFG+Hihao2M71ADiWC0=; 7:TUMPGKsNW729vNojgFw+GIIiKg2/SSkuNhNQe+Lbq0Nt1ro9XDxsiaBo2PX5up5bYMOv9HW0xwVZJyvyrV0ErfOM4L8pCq8W8PpWwiSwfh5VBJUM8nDQsO/6trnCGrd/B8y/Pmov3UN0tiP4Znzdag==
x-ms-office365-filtering-correlation-id: 6f0abb20-1639-4046-9ada-08d6413d8e86
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600074)(711020)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB4110; 
x-ms-traffictypediagnostic: VI1PR07MB4110:
x-microsoft-antispam-prvs: <VI1PR07MB4110C8D393AA7D9692236F6BD0C80@VI1PR07MB4110.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:;
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3231382)(944501410)(52105095)(3002001)(10201501046)(93006095)(93001095)(148016)(149066)(150057)(6041310)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB4110; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB4110; 
x-forefront-prvs: 08457955C4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(376002)(136003)(396003)(39860400002)(199004)(189003)(65956001)(36756003)(99286004)(7736002)(14454004)(256004)(14444005)(105586002)(3846002)(486006)(2616005)(6116002)(58126008)(476003)(106356001)(53936002)(2906002)(305945005)(5660300001)(1730700003)(81166006)(81156014)(2900100001)(52116002)(65806001)(65826007)(8936002)(8676002)(6486002)(64126003)(25786009)(71200400001)(2501003)(31696002)(316002)(478600001)(6916009)(386003)(6506007)(71190400001)(2351001)(97736004)(186003)(68736007)(31686004)(66066001)(5640700003)(86362001)(102836004)(26005)(6512007)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB4110; H:VI1PR07MB4717.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: El4L9GUWlWjJYaYTpkuTQ16imv9P+UeE/eZHFcw5vE/Q6B1wQKz/ZXjN9Bb74GGZilaOHx40QP6oJ3K60ZNeoYG0AyM/GiFke7Z7iLaaOgBzvSpS8onvnEjqAdnRAniLtGRHag3JvWt8+kspMRHwPjBhE8YYNoMdlUigR5md6hJEN6GNdp606DO9FMg/ZOEWnFOitgHPjog/mqiZSyhnrNP96tU1Sqwlpkz89wZ3+S6kayXKBjPRbN9m7+9+iElSpvdTPrpm/C1wZ9ssuy+DW2DHoasLGvv/dwDph1nXetOsPhQ8aaoUZMBzOzungb6CxH80MPAaC7vrrEqPzGWkYncdavN/Y/r8e3jlSuzQNpI=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <CE4B283CC942544EA5BDA4E0A715D5AB@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6f0abb20-1639-4046-9ada-08d6413d8e86
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2018 03:36:36.1501 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4110
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjleLIzCtJLcpLzFFi42KZGbG9XPeo+N1og0/zhSzeL53F6MDosWTJ T6YAxigum5TUnMyy1CJ9uwSujPONK1gLnshUzP7wibWBsUWmi5GTQ0LARGL9lw8sXYxcHEIC RxglNrz4yAjhfGWUeHzpFCNIlZDAYiaJU5urQBIsAhOYJbbO+MQOUTWBSWLet2XMEFUPGSV+ XWAHsdkEDCQmT1kBZosIqEr0zjnFBGILC1hL9G6eDRTnAIo7SDRPU4Yo0ZNoXbeKDcRmEVCR +H+9A6ycV8Be4vWEHywgNqOAmMT3U2vA4swC4hK3nsxngnhBQGLJnvPMELaoxMvH/1hBbFGB CInmk39ZIOKKEmffPWQCuVlCYCqjxIKLXWwQQ2MlPvzvhxqkI3H2+hNGCFtW4tL8bkaIhmts Ese33oaa5Cux/dM3VojEcUaJbyvnQK3Wkvj28go7hJ0t8WX+MzaYeMeRWVAb5CRW9T5kgWpm lmjYuIxtAqPhLCQvzQKGDLOApsT6XfoQpofElruuEBWKElO6H7LPAgeMoMTJmU9YFjCyrmIU LU4tLs5NNzLWSy3KTC4uzs/Ty0st2cQITB0Ht/zW3cG4+rXjIUYBDkYlHt4JonejhVgTy4or cw8xSnAwK4nwfmm9Ey3Em5JYWZValB9fVJqTWnyIUZqDRUmcV2/VnighgfTEktTs1NSC1CKY LBMHpxQwCf3bKuz8WvnA1OiZZfd29HgW35iaOi0wI0zRwXvX/28zz66Pcwy6ajJnp/+bD5ZP 3H4diXy6YZv2ZCHvkmcHlGJKmnSalR5vf+55ZJaPbFLG2/Kfnf+cliamvUiY9NgoZ/02tU+b yxnEjApvTdrdc5i/qcq490/j++lbkrJSJ/0SPOzSM3NPshJLcUaioRZzUXEiAFVvjFkZAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/imlrzQA5XmYzCW-zHkBR6bQ4XyY>
Subject: [dnssd] Review of draft-bradley-dnssd-private-discovery-00
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Nov 2018 03:36:41 -0000

SGkgRE5TU0QsDQoNCk5vdyB0byB0aGUgYWN0dWFsIHRlY2huaWNhbCBpZGVhcyBpbiANCmRyYWZ0
LWJyYWRsZXktZG5zc2QtcHJpdmF0ZS1kaXNjb3ZlcnktMDAuIEkgdGhpbmsgdGhlcmUgc29tZSBj
aGFsbGVuZ2luZyANCmltcGxlbWVudGF0aW9uIGFzcGVjdHMgaW4gdGhlIGRyYWZ0Og0KDQotIFRo
ZSBwZXJmb3JtYW5jZSBvZiB0aGUgZHJhZnQgd291bGQgZ2V0IHdvcnNlIGFuZCB3b3JzZSBhcyB5
b3VyIG5ldHdvcmsgDQpzY2FsZXMuIEkgd29uZGVyIGhvdyBpdCBtZWV0cyB0aGUgcmVxdWlyZW1l
bnRzIG9mIHNjYWxpbmcgdGhhdCBTdHVhcnQgDQpwcmVzZW50ZWQuDQoNCi0gQ2hyaXN0aWFuIHJp
Z2h0bHkgb2JzZXJ2ZXMgdGhhdCBhIGRldmljZSB3b3VsZCBoYXZlIHRvIGdvIHRocm91Z2ggdGhl
IA0KbGlzdCBvZiBhbGwgbG9uZyB0ZXJtIHB1YmxpYy1rZXlzIGl0IGhhcyBpbiB0aGUgbGlzdCBv
ZiBpdHMgZnJpZW5kcy4gQnV0IA0KaXQgZG9lc24ndCBjYXB0dXJlIHRoZSBlbnRpcmUgY29tcGxl
eGl0eSBvZiBvcGVyYXRpb25zIGludm9sdmVkLg0KDQotIExldCBtZSBleHBsYWluIGluIG1vcmUg
ZGV0YWlsLCB3aGVuZXZlciBhIGRldmljZSBzZW5kcyBhIG11bHRpY2FzdCANCnByb2JlIHRvIGRp
c2NvdmVyIGZyaWVuZHMsIGFsbCBkZXZpY2VzIG9uIHRoZSBtdWx0aWNhc3QgbmV0d29yayBNVVNU
Og0KIMKgwqDCoCDCoMKgwqAgLT4gQ2hlY2sgdGhlIHRpbWUgc3RhbXANCiDCoMKgwqDCoMKgwqDC
oCAtPiBUcnkgdG8gdmVyaWZ5IHNpZ25hdHVyZXMgaW4gdGhlIHByb2JlIHdpdGggYWxsIHRoZSBw
dWJsaWMgDQprZXlzIGluIHRoZSBsaXN0IG9mIGl0cyBmcmllbmRzLiBJZiBhIGRldmljZSBvbiB0
aGUgbmV0d29yayBoYXMgMTAgDQpmcmllbmRzLCB0aGVuIGl0IHdvdWxkIGhhdmUgdG8gcGVyZm9y
bSAxMCBzaWduYXR1cmUgdmVyaWZpY2F0aW9uIA0Kb3BlcmF0aW9ucyBiZWZvcmUgZmFpbGluZy4N
CiDCoMKgwqDCoMKgwqDCoCAtPiBJZiB0aGUgcHJvYmUgd2FzIGluZGVlZCBmcm9tIGEgZnJpZW5k
LCB0aGUgZGV2aWNlIHdvdWxkIA0KZ2VuZXJhdGUgYSBjb3JyZXNwb25kaW5nIHJlc3BvbnNlLg0K
DQotIEFmdGVyIHJlY2VpdmluZyBwcm9iZSByZXNwb25zZShzKSwgdGhlIGRldmljZSB0aGF0IHNl
bnQgdGhlIHByb2JlIE1VU1QgDQpwZXJmb3JtIHRoZSBmb2xsb3dpbmcgZm9yIGVhY2ggcmVzcG9u
c2U6DQogwqDCoMKgIMKgIMKgIC0+IFBlcmZvcm0gYSBESCBvcGVyYXRpb24gdG8gZGVyaXZlIGEg
c2hhcmVkIHNlY3JldCB3aXRoIHRoZSANCmVwaGVtZXJhbCBwdWJsaWMta2V5cy4NCiDCoCDCoCDC
oCDCoCAtPiBUcnkgdG8gdmVyaWZ5IHRoZSBzeW1tZXRyaWMgc2lnbmF0dXJlIHdpdGggdGhlIERI
IHNoYXJlZCANCnNlY3JldCBkZXJpdmVkLiBJZiBpdCBmYWlscywgdHJ5IHdpdGggbm9uY2UgKy8t
IDEgdXAgdG8gOC4gVGhpcyBpcyANCmFscmVhZHkgcXVpdGUgYSBsYXJnZSBudW1iZXIgb2Ygb3Bl
cmF0aW9ucyBiZWZvcmUgZmFpbGluZy4NCiDCoCDCoMKgIMKgwqAgLT4gT24gc3VjY2Vzc2Z1bCBz
eW1tZXRyaWMgc2lnbmF0dXJlIHZlcmlmaWNhdGlvbiwgdHJ5IHRvIA0KdmVyaWZ5IHNpZ25hdHVy
ZXMgaW4gdGhlIHByb2JlIHJlc3BvbnNlIHdpdGggYWxsIHRoZSBwdWJsaWMga2V5cyBpbiB0aGUg
DQpsaXN0IG9mIGl0cyBmcmllbmRzLiBJZiBhIGRldmljZSBvbiB0aGUgbmV0d29yayBoYXMgMTAg
ZnJpZW5kcywgdGhlbiBpdCANCndvdWxkIGhhdmUgdG8gcGVyZm9ybSAxMCBzaWduYXR1cmUgdmVy
aWZpY2F0aW9uIG9wZXJhdGlvbnMgYmVmb3JlIGZhaWxpbmcuDQoNClRoZXNlIGFyZSBhbHJlYWR5
IHF1aXRlIGEgbG90IG9mIGNvbXB1dGF0aW9uYWxseSBoZWF2eSB0YXNrcyBhbmQgSSANCmhhdmVu
J3QgZGVzY3JpYmVkIHRoZSBRdWVyeSwgQW5zd2VyIGFuZCBBbm5vdW5jZW1lbnQgbWVzc2FnZXMu
IEkgdGhpbmsgDQp0aGVyZSBpcyBhbiBhZGRpdGlvbmFsIGltcGxlbWVudGF0aW9uIGNoYWxsZW5n
ZSAoSSBjb3VsZCBiZSB3cm9uZyk6DQoNCiDCoC0gQWxsIHRoZSBvcGVyYXRpb25zIGxpc3RlZCBh
Ym92ZSBtdXN0IGJlIHBlcmZvcm1lZCBpbiBjb25zdGFudCANCih3b3JzdC10aW1lKSB0byBwcmV2
ZW50IGxlYWtpbmcgc2lkZS1jaGFubmVsIGluZm9ybWF0aW9uIHdoZW4gaHVudGluZyANCmFuZCBw
ZWNraW5nIGZvciBmcmllbmRzIGluIHRoZSBsaXN0LiAoT3IgdGhlbiB0aGUgaHVudGluZyBhbmQg
cGVja2luZyANCmZvciB0aGUgZnJpZW5kcyBsb25nIHRlcm0gcHVibGljIGtleXMgbmVlZHMgdG8g
cmFuZG9taXplZC4pDQoNCi0gRmluYWxseSwgc2luY2UgU0lHMSBpcyBzdGlsbCBzaW5nZWQgYnkg
dGhlIGxvbmctdGVybSBwcml2YXRlIGtleSBvZiANCnRoZSBkZXZpY2Ugc2VuZGluZyB0aGUgcHJv
YmUsIGlmIEkgY2FuIG1hbmFnZSB0byBjb2xsZWN0IGEgbGlzdCBvZiANCmxvbmctdGVybSBwdWJs
aWMta2V5cywgSSBjYW4gc3RpbGwgc2VlIGF0IGxlYXN0IHdobyBpcyBzZW5kaW5nIHRoZSANCnBy
b2JlLiBIb3dldmVyLCBJIHVuZGVyc3RhbmQgdGhhdCBpdCBpcyBhIGxpbWl0YXRpb24gb2YgaG93
IGtleXMgYXJlIA0KZGlzdHJpYnV0ZWQvc2hhcmVkIGFuZCB0aGlzIHByb2JsZW0gaXMgbm90IGxp
bWl0ZWQgdG8gDQpkcmFmdC1icmFkbGV5LWRuc3NkLXByaXZhdGUtZGlzY292ZXJ5LTAwLg0KDQot
LU1vaGl0DQoNCg==


From nobody Fri Nov  2 20:43:32 2018
Return-Path: <mohit.m.sethi@ericsson.com>
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 8F892130E1D for <dnssd@ietfa.amsl.com>; Fri,  2 Nov 2018 20:43:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.77
X-Spam-Level: 
X-Spam-Status: No, score=-4.77 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=C6hhMyZa; dkim=pass (1024-bit key) header.d=ericsson.com header.b=BGZR9c8H
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XuIcMyAF5bp5 for <dnssd@ietfa.amsl.com>; Fri,  2 Nov 2018 20:43:29 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F56E128A6E for <dnssd@ietf.org>; Fri,  2 Nov 2018 20:43:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple;  q=dns/txt; i=@ericsson.com; t=1541216606; x=1543808606; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=hIil//35WTpcZgWlhGu38gCHLPruhHcPlAFlcdhgoWw=; b=C6hhMyZanhrpL0ck98aOKPE2A2eMRC3GhYfuAXIQA7jNJxCmqIMzRjC/btsxu6Gu C+gV2mNL7XZEhV6KVc8q5uEGvh1UcXNJAKukW++wO7Aw1nnahGZ8eP3zc6kB1W5C 5IPV0oTw+khaeaZks5cqwREizKlO9R9Wkvv7RdqenL8=;
X-AuditID: c1b4fb30-1ebff70000007d19-4e-5bdd195e9f0a
Received: from ESESBMB504.ericsson.se (Unknown_Domain [153.88.183.117]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id A8.35.32025.E591DDB5; Sat,  3 Nov 2018 04:43:26 +0100 (CET)
Received: from ESESBMR506.ericsson.se (153.88.183.202) by ESESBMB504.ericsson.se (153.88.183.171) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 3 Nov 2018 04:43:26 +0100
Received: from ESESSMB501.ericsson.se (153.88.183.162) by ESESBMR506.ericsson.se (153.88.183.202) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 3 Nov 2018 04:43:26 +0100
Received: from EUR03-AM5-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB501.ericsson.se (153.88.183.162) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Sat, 3 Nov 2018 04:43:25 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hIil//35WTpcZgWlhGu38gCHLPruhHcPlAFlcdhgoWw=; b=BGZR9c8HiSF/bGkefeOtE39U0/k4keiZoTy4f7SV+p+X6IeM6clXn6+3rjIjdQSd01oxBpy9WR+wR3u1kWIhKT4CZ3qzjlEC8bY7NbFi/UBt5vs4pQsEqPuOpEgygAQKQp5z6xlCApLJwvExb5f5+a6Qre5JZRHRfg7zevoLb9c=
Received: from VI1PR07MB4717.eurprd07.prod.outlook.com (20.177.54.82) by VI1PR07MB3277.eurprd07.prod.outlook.com (10.175.243.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1294.14; Sat, 3 Nov 2018 03:43:25 +0000
Received: from VI1PR07MB4717.eurprd07.prod.outlook.com ([fe80::8412:d8ae:dfa0:c61f]) by VI1PR07MB4717.eurprd07.prod.outlook.com ([fe80::8412:d8ae:dfa0:c61f%4]) with mapi id 15.20.1294.027; Sat, 3 Nov 2018 03:43:25 +0000
From: Mohit Sethi M <mohit.m.sethi@ericsson.com>
To: Christian Huitema <huitema@huitema.net>, Lanlan Pan <abbypan@gmail.com>
CC: dnssd <dnssd@ietf.org>
Thread-Topic: [dnssd] Next steps for privacy discovery
Thread-Index: AQHUcydfEGC1Hs6wvEyMfFltSPw4DQ==
Date: Sat, 3 Nov 2018 03:43:24 +0000
Message-ID: <bae4578e-9f1d-0d65-8829-eb301d7f70db@ericsson.com>
References: <48bc4612-018e-7aac-6492-05657c466313@huitema.net> <CANLjSvXkQS3hGYCHoXu-jNP0Hvad02XBw4AsPMwTM02BvQkKKQ@mail.gmail.com> <0f32e79a-447a-f308-4888-4037a41716dd@huitema.net>
In-Reply-To: <0f32e79a-447a-f308-4888-4037a41716dd@huitema.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
x-originating-ip: [89.166.49.243]
x-clientproxiedby: AM5PR0602CA0012.eurprd06.prod.outlook.com (2603:10a6:203:a3::22) To VI1PR07MB4717.eurprd07.prod.outlook.com (2603:10a6:803:69::18)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; VI1PR07MB3277; 6:rf2BbzoIfRnJtPZZqqt+6+5zplzVfdt/HqTplBTh7ZZODvHKSr6LA5hXCqoG5pTUoKnObbEFF5D4YM6Qsur1sLm3vm09plY+GFK3rroFD2iLyegnF9Wr/0NNPUK9MM9ZvmpqVgxeLq0vJPSAwQtHe7I3YgzB0iNmNCn6gogBY5g6t6aZdpRfAqTWvkx6ZP+qJqGoqTafej3ofp+xDAsLWHM78dl18lwvLgpI2HcMcwskDDCzLn0kSmbVx/NEwgybBI+osgvLFTWFzv29V/wjLohNcPO0OrKBZ/vUtEypmanM2beL69EqAyNeOtgWD+VLPn+5Oz4kDj/s8KSVNIL9gnLtHR/puTOTP3GCw9DRXnbVK/UuJzfm/F7HtI747HHo90y+gTlZiGkp4XKnx5rRfo/V6gwJ8WRU0RIxeDMw8OG+Sg+XDM78ZuVndP8iROG9XcfINM5kTANJBXnLJOBjeA==; 5:X1H7Frjiu0865M0S9Mpw8fi0t1v67MJe/3hpzBQNlDSz1hBWoGftLTXpPupp1vO+6yh2lo43tEORnSBwyu++c9S8rLPKlFzBumLTOS5iQxyWnqpSr0Euzt6CrOPLOvD7YxDPFlJX/h3DRQ+b++P9LSZUjq/xEKbFdCCjQ+13pzY=; 7:ts5S4n+6WOKnrwHlnS2Zg/8WHSCMwTvFSG/wGAuKDWAfjjg6gpxiAfr/+YU6XjHbrwaHVS4383Igp6gyThn8FuhBRUUD4Jz2HrZelXFdmpTuj/zqfek0o4qG25a+nNZtg2tPT0vf6qYudUcRP6sv/g==
x-ms-office365-filtering-correlation-id: 586d22e0-ee48-43bc-054a-08d6413e820b
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(7020095)(4652040)(8989299)(5600074)(711020)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:VI1PR07MB3277; 
x-ms-traffictypediagnostic: VI1PR07MB3277:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=mohit.m.sethi@ericsson.com; 
x-microsoft-antispam-prvs: <VI1PR07MB327790576696D01DF89E8544D0C80@VI1PR07MB3277.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(85827821059158);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(5005006)(8121501046)(3231382)(944501410)(52105095)(10201501046)(93006095)(93001095)(3002001)(148016)(149066)(150057)(6041310)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123562045)(20161123564045)(201708071742011)(7699051)(76991095); SRVR:VI1PR07MB3277; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB3277; 
x-forefront-prvs: 08457955C4
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(39860400002)(366004)(136003)(54094003)(199004)(189003)(86362001)(97736004)(6486002)(6116002)(2906002)(31686004)(36756003)(102836004)(110136005)(7736002)(316002)(68736007)(14454004)(58126008)(6436002)(65826007)(105586002)(106356001)(966005)(53546011)(2900100001)(229853002)(386003)(6506007)(606006)(5660300001)(3846002)(31696002)(4326008)(81166006)(66066001)(476003)(65806001)(2616005)(65956001)(486006)(256004)(39060400002)(25786009)(11346002)(81156014)(71200400001)(71190400001)(8936002)(53936002)(76176011)(186003)(26005)(478600001)(6306002)(54896002)(64126003)(52116002)(99286004)(6246003)(446003)(8676002)(6512007)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3277; H:VI1PR07MB4717.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; 
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: bH6DQgHD6xcRSZXWFG1+i7Bx4b37vPM3V9HxT1bXTCWe/VBsfL+4RQVCSjzPv3ErFbE9QcUt6nJZfjbQ3N/UwgueaS4jadsN52s+SDce7EmXzN0kGgH1H9sHwt+3nyfGQYSUIH/vb3IAfAlBB0AK2hwNTU4DLoIw5flyglnkkXzRdwwhLbo1dGIDHYiJDXYysPrvfKxuKIX1vKg/VFuNKzZo9ljiwxneqq70ja3z3o5EtxqWAgu7GJo6cAljNXJdz/UDhuCERjC4o/ONtBQ3R+JRLXPIqFpH5YdJA0MMOlM4bA2JNKRj4O5CfJ0J+UAxP1vF75V8otbVmeohvU2Qnx4BXe8WcIyPsksFS5MYdGE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_bae4578e9f1d0d658829eb301d7f70dbericssoncom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 586d22e0-ee48-43bc-054a-08d6413e820b
X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Nov 2018 03:43:24.9034 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3277
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA02Sb0hTURjGO/fe7V6Xg9Ny+mZIOYRSSqdlGqQmfRmGFdYHcWVNvbihTtlU MigUlUIz/5JuWhlOUrHMNM0ZgSaZpmZ+yPAPORrVkpxgK020tt0Vfvs97/Oc877v4TCkaIDn zajU2axGrUiX8AWULr4352Dirnm5tNLkH/5u00iHW5v1KLy6oJ4+Tsr69PO0bKZulJIZDGvE GTJBcCyFTVflspqgyEsCpbnjJ5U1E3X59UwPPx+tRJQgNwbwYbjfOkmUIAEjwkMI8tsb+Jyw ITDYpnn/xUjvG5oTTQSs9q07HQpXkPBi0kBxThUBLytWXMKEwGhtoh1t+FgK1TUtTvbAJ2Fx sp/vYBJ7w0RXKeHgnTgUJu4WEFzmCDyqW7XnGTsHQv7jVEeZwn7Q0NzCc7AQR0FVxUPXsEYE 5bWc4WY3nn6wOu9H2BN+jbYTXC8vmDHfI7i1MRievyU5FoPl06bzrBjHQ+HIBsXVfWF8yeTK 6xCsVO/h+ACMT5sRxz4wda8UOYYA/J4Ps+U6mjNi4fO3JYozhhFc/2pz3RoAloVV13QXYPlP OVGBDum3DMhxMtjWKvl656Y7YERnpvT2xyCxP3QYg7iIL9SUmmiO90Nxwx0Xy6BA30ZvzTQi pg2Jtaw2KSM1JCSQ1aiStdpMdaCazX6C7B9roHtd+gxZvkQPIswgibtwUTwvF/EUudq8jEEE DCnxEP4onpOLhCmKvCusJvOiJied1Q6i3Qwl8RKGn+pKEOFURTabxrJZrOafSzBu3vnobHxn SsBcdmdGyUKkNC7iQXNVn7Q/OO5G7O/uTh8wuV8tkgfVBxf5Zc5+vDZ885aHerWs1LptLCxk yq02KO+cbF9aTExNqzL5fIKisjY0d+z07Q36aKU4VKnbUJ1I7OmTv7Ki7dOFZcvRkR1DVr+x 70krcZYwT2EV1hcrG/eOSSitUhEcQGq0ir99dphSVAMAAA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/YmqqiMmOM9Nh3gmxKK5CRMFg2GU>
Subject: Re: [dnssd] Next steps for privacy discovery
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Nov 2018 03:43:31 -0000

--_000_bae4578e9f1d0d658829eb301d7f70dbericssoncom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgQ2hyaXN0aWFuLA0KDQpJIHdvdWxkIHJlY29tbWVuZCB5b3UgdG8gaGF2ZSBhIGxvb2sgYXQg
RUFQLU5PT0IgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hdXJhLWVhcC1ub29i
LTA0KS4gVGhlIGRyYWZ0IGlzIGRvaW5nIHRoaW5ncyBhdCBhIGRpZmZlcmVudCBsYXllciBhbmQg
aXMgc29sdmluZyBhIGRpZmZlcmVudCBwcm9ibGVtLiBJdCBpcyBkb2luZyBwYWlyaW5nIGJldHdl
ZW4gYSBkZXZpY2UgYW5kIGEgdmlydHVhbCBjbG91ZCBzZXJ2aWNlIChFQVAgc2VydmVyKS4NCg0K
SG93ZXZlciwgbWFueSBvZiB0aGluZ3MgYXJlIHJlbGF0ZWQgYW5kIGNvdWxkIGJlIHVzZWZ1bCBm
b3IgeW91ciB3b3JrLiBBcyB5b3UgcmlnaHRseSBub3RlIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5v
cmcvaHRtbC9kcmFmdC1pZXRmLWRuc3NkLXBhaXJpbmctaW5mby0wMiwgT09CIGNoYW5uZWxzIGRv
IG5vdCBwcm92aWRlIGNvbmZpZGVudGlhbGl0eS4gRUFQLU5PT0IgaXMgZGVzaWduZWQgaW4gYSB3
YXkgdGhhdCAgcHJldmVudHMgaW1wZXJzb25hdGlvbiBhbmQgbWFuLWluLXRoZS1taWRkbGUgYXR0
YWNrcyBldmVuIGluIHNpdHVhdGlvbnMgd2hlcmUgdGhlIGF0dGFja2VyIGlzIGFibGUgdG8gZWF2
ZXNkcm9wIHRoZSBPT0IgY2hhbm5lbC4gVGhlICJBdXRoZW50aWNhdGlvbiBwcmluY2lwbGUiIHNl
Y3Rpb24gaGFzIG1vcmUgZGV0YWlsczogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0
LWF1cmEtZWFwLW5vb2ItMDQjc2VjdGlvbi02LjENCg0KLS1Nb2hpdA0KDQpPbiAxMC8zMC8xOCAx
MjoyMCBBTSwgQ2hyaXN0aWFuIEh1aXRlbWEgd3JvdGU6DQoNCg0KT24gMTAvMjgvMjAxOCA2OjQ4
IFBNLCBMYW5sYW4gUGFuIHdyb3RlOg0KDQoNCkNocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1
aXRlbWEubmV0PG1haWx0bzpodWl0ZW1hQGh1aXRlbWEubmV0Pj7kuo4yMDE45bm0MTDmnIgyNuaX
peWRqOS6lCDkuIvljYgzOjA55YaZ6YGT77yaDQouLi4NCg0KNCkgSWYgd2Uga2VwdCB0aGUgY3Vy
cmVudCAidHdvIHBoYXNlIiBzdHJ1Y3R1cmUsIHVzZSBhIFRMUyBwcm90b2NvbA0KZXh0ZW5zaW9u
IHRvIGRlbW9uc3RyYXRlIGtub3dsZWRnZSBvZiB0aGUgc2VydmVyJ3MgcHVibGljIGtleSBpbiB0
aGUNCmNsaWVudCBoZWxsby4gSSB0aGluayB3ZSBjYW4gYnVpbGQgb24gdGhlIHdvcmsgZG9uZSBm
b3IgU05JIGVuY3J5cHRpb24sDQp3aGljaCB3b3VsZCBmaXQgcXVpdGUgd2VsbC4NCg0KSSB3b25k
ZXIgaWYgd2UgY291bGQgY29uc2lkZXIgYWJvdXQgdXNlIHRscyBwc2sgKHByZS1zaGFyZWQga2V5
KSA/ICBzZXJ2ZXIgY2FuIGFzc2lnbiBkaWZmZXJlbnQga2V5IHRvIGRpZmZlcmVudCBjbGllbnQu
DQoNClRoYXQncyB3aGF0IHdlIHdlcmUgc3BlY2lmeWluZyBpbiB0aGUgY3VycmVudCBwcml2YWN5
IGRyYWZ0LiBUaGVyZSBhcmUgdHdvIGlzc3Vlcy4gVGhlIGZpcnN0IG9uZSBpcyB0aGF0IGlmIHlv
dSB1c2UgVExTLVBTSywgdGhlIENsaWVudCBIZWxsbyBtdXN0IGluY2x1ZGUgYSBrZXkgaWRlbnRp
Zmllci4gSWYgdGhlcmUgaXMgYSBkaWZmZXJlbnQga2V5IGZvciBlYWNoIGNsaWVudCwgdGhlIGtl
eSBpZGVudGlmaWVyIGNvdWxkIGJlY29tZSBhIGNsaWVudCBpZGVudGlmaWVyLiBXZSBzb2x2ZWQg
dGhhdCAgYnkgdXNpbmcgYSAicHJlZGljdGFibGUgbm9uY2UiIGZvciBrZXkgaWRlbnRpZmllci4g
VGhlIHNlY29uZCBpc3N1ZSBpcyBvZiBjb3Vyc2UgdGhhdCBhc3NpZ25pbmcgZGlmZmVyZW50IGtl
eXMgdG8gZGlmZmVyZW50IGNsaWVudHMgcmVxdWlyZXMgZXh0cmEgbWFuYWdlbWVudCBhdCB0aGUg
c2VydmVyLCBzb21ldGhpbmcgdGhhdCBpcyBub3QgbmVlZGVkIGluIHRoZSAicHJpdmF0ZSBwdWJs
aWMga2V5IiBjbGFzcyBvZiBzb2x1dGlvbnMuDQoNCi0tIENocmlzdGlhbiBIdWl0ZW1hDQoNCg0K
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KZG5zc2Qg
bWFpbGluZyBsaXN0DQpkbnNzZEBpZXRmLm9yZzxtYWlsdG86ZG5zc2RAaWV0Zi5vcmc+DQpodHRw
czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Ruc3NkDQoNCg==

--_000_bae4578e9f1d0d658829eb301d7f70dbericssoncom_
Content-Type: text/html; charset="utf-8"
Content-ID: <C1F654686D361F48A4E9C1D301B5EF6A@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHRleHQ9IiMwMDAwMDAi
IGJnY29sb3I9IiNGRkZGRkYiPg0KPHA+SGkgQ2hyaXN0aWFuLDwvcD4NCjxwPkkgd291bGQgcmVj
b21tZW5kIHlvdSB0byBoYXZlIGEgbG9vayBhdCBFQVAtTk9PQiAoPGEgbW96LWRvLW5vdC1zZW5k
PSJ0cnVlIiBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYXVyYS1lYXAt
bm9vYi0wNCI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF1cmEtZWFwLW5vb2It
MDQ8L2E+KS4gVGhlIGRyYWZ0IGlzIGRvaW5nIHRoaW5ncyBhdCBhIGRpZmZlcmVudCBsYXllciBh
bmQgaXMgc29sdmluZyBhDQogZGlmZmVyZW50IHByb2JsZW0uIEl0IGlzIGRvaW5nIHBhaXJpbmcg
YmV0d2VlbiBhIGRldmljZSBhbmQgYSB2aXJ0dWFsIGNsb3VkIHNlcnZpY2UgKEVBUCBzZXJ2ZXIp
Lg0KPGJyPg0KPC9wPg0KPHA+SG93ZXZlciwgbWFueSBvZiB0aGluZ3MgYXJlIHJlbGF0ZWQgYW5k
IGNvdWxkIGJlIHVzZWZ1bCBmb3IgeW91ciB3b3JrLiBBcyB5b3UgcmlnaHRseSBub3RlIGluDQo8
YSBtb3otZG8tbm90LXNlbmQ9InRydWUiIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt
bC9kcmFmdC1pZXRmLWRuc3NkLXBhaXJpbmctaW5mby0wMiI+DQpodHRwczovL3Rvb2xzLmlldGYu
b3JnL2h0bWwvZHJhZnQtaWV0Zi1kbnNzZC1wYWlyaW5nLWluZm8tMDI8L2E+LCBPT0IgY2hhbm5l
bHMgZG8gbm90IHByb3ZpZGUgY29uZmlkZW50aWFsaXR5LiBFQVAtTk9PQiBpcyBkZXNpZ25lZCBp
biBhIHdheSB0aGF0Jm5ic3A7IHByZXZlbnRzIGltcGVyc29uYXRpb24gYW5kIG1hbi1pbi10aGUt
bWlkZGxlIGF0dGFja3MgZXZlbiBpbiBzaXR1YXRpb25zIHdoZXJlIHRoZSBhdHRhY2tlciBpcyBh
YmxlIHRvIGVhdmVzZHJvcA0KIHRoZSBPT0IgY2hhbm5lbC4gVGhlICZxdW90O0F1dGhlbnRpY2F0
aW9uIHByaW5jaXBsZSZxdW90OyBzZWN0aW9uIGhhcyBtb3JlIGRldGFpbHM6IDxhIG1vei1kby1u
b3Qtc2VuZD0idHJ1ZSIgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWF1
cmEtZWFwLW5vb2ItMDQjc2VjdGlvbi02LjEiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s
L2RyYWZ0LWF1cmEtZWFwLW5vb2ItMDQjc2VjdGlvbi02LjE8L2E+PGJyPg0KPC9wPg0KPHA+LS1N
b2hpdDxicj4NCjwvcD4NCjxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMTAvMzAvMTgg
MTI6MjAgQU0sIENocmlzdGlhbiBIdWl0ZW1hIHdyb3RlOjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOjBmMzJlNzlhLTQ0N2EtZjMwOC00ODg4LTQwMzdhNDE3
MTZkZEBodWl0ZW1hLm5ldCI+DQo8cD48YnI+DQo8L3A+DQo8YnI+DQo8ZGl2IGNsYXNzPSJtb3ot
Y2l0ZS1wcmVmaXgiPk9uIDEwLzI4LzIwMTggNjo0OCBQTSwgTGFubGFuIFBhbiB3cm90ZTo8YnI+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpDQU5MalN2WGtRUzNo
R1lDSG9YdS1qTlAwSHZhZDAyWEJ3NEFzUE13VE0wMkJ2UWtLS1FAbWFpbC5nbWFpbC5jb20iPg0K
PGRpdiBkaXI9Imx0ciI+PGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPg0KPGRp
diBkaXI9Imx0ciI+Q2hyaXN0aWFuIEh1aXRlbWEgJmx0OzxhIGhyZWY9Im1haWx0bzpodWl0ZW1h
QGh1aXRlbWEubmV0IiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmh1aXRlbWFAaHVpdGVtYS5uZXQ8
L2E+Jmd0O+S6jjIwMTjlubQxMOaciDI25pel5ZGo5LqUIOS4i+WNiDM6MDnlhpnpgZPvvJo8YnI+
DQo8L2Rpdj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdpbjow
IDAgMAoNCiAgICAgICAgICAgICAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRk
aW5nLWxlZnQ6MWV4Ij4NCi4uLjxicj4NCjxicj4NCjQpIElmIHdlIGtlcHQgdGhlIGN1cnJlbnQg
JnF1b3Q7dHdvIHBoYXNlJnF1b3Q7IHN0cnVjdHVyZSwgdXNlIGEgVExTIHByb3RvY29sPGJyPg0K
ZXh0ZW5zaW9uIHRvIGRlbW9uc3RyYXRlIGtub3dsZWRnZSBvZiB0aGUgc2VydmVyJ3MgcHVibGlj
IGtleSBpbiB0aGU8YnI+DQpjbGllbnQgaGVsbG8uIEkgdGhpbmsgd2UgY2FuIGJ1aWxkIG9uIHRo
ZSB3b3JrIGRvbmUgZm9yIFNOSSBlbmNyeXB0aW9uLDxicj4NCndoaWNoIHdvdWxkIGZpdCBxdWl0
ZSB3ZWxsLjxicj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pkkgd29u
ZGVyIGlmIHdlIGNvdWxkIGNvbnNpZGVyIGFib3V0IHVzZSA8c3BhbiBjbGFzcz0iaW5ib3gtaW5i
b3gtc3QiPnRscyBwc2sgKHByZS1zaGFyZWQga2V5KSA/Jm5ic3A7IHNlcnZlciBjYW4gYXNzaWdu
IGRpZmZlcmVudCBrZXkgdG8gZGlmZmVyZW50IGNsaWVudC48L3NwYW4+PGJyPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KVGhhdCdzIHdoYXQgd2Ugd2VyZSBz
cGVjaWZ5aW5nIGluIHRoZSBjdXJyZW50IHByaXZhY3kgZHJhZnQuIFRoZXJlIGFyZSB0d28gaXNz
dWVzLiBUaGUgZmlyc3Qgb25lIGlzIHRoYXQgaWYgeW91IHVzZSBUTFMtUFNLLCB0aGUgQ2xpZW50
IEhlbGxvIG11c3QgaW5jbHVkZSBhIGtleSBpZGVudGlmaWVyLiBJZiB0aGVyZSBpcyBhIGRpZmZl
cmVudCBrZXkgZm9yIGVhY2ggY2xpZW50LCB0aGUga2V5IGlkZW50aWZpZXIgY291bGQgYmVjb21l
IGEgY2xpZW50DQogaWRlbnRpZmllci4gV2Ugc29sdmVkIHRoYXQmbmJzcDsgYnkgdXNpbmcgYSAm
cXVvdDtwcmVkaWN0YWJsZSBub25jZSZxdW90OyBmb3Iga2V5IGlkZW50aWZpZXIuIFRoZSBzZWNv
bmQgaXNzdWUgaXMgb2YgY291cnNlIHRoYXQgYXNzaWduaW5nIGRpZmZlcmVudCBrZXlzIHRvIGRp
ZmZlcmVudCBjbGllbnRzIHJlcXVpcmVzIGV4dHJhIG1hbmFnZW1lbnQgYXQgdGhlIHNlcnZlciwg
c29tZXRoaW5nIHRoYXQgaXMgbm90IG5lZWRlZCBpbiB0aGUgJnF1b3Q7cHJpdmF0ZSBwdWJsaWMg
a2V5JnF1b3Q7DQogY2xhc3Mgb2Ygc29sdXRpb25zLjxicj4NCjxicj4NCi0tIENocmlzdGlhbiBI
dWl0ZW1hPGJyPg0KPGJyPg0KPGZpZWxkc2V0IGNsYXNzPSJtaW1lQXR0YWNobWVudEhlYWRlciI+
PC9maWVsZHNldD4NCjxwcmUgY2xhc3M9Im1vei1xdW90ZS1wcmUiIHdyYXA9IiI+X19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmRuc3NkIG1haWxpbmcgbGlz
dA0KPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCIgaHJlZj0ibWFpbHRvOmRuc3Nk
QGlldGYub3JnIj5kbnNzZEBpZXRmLm9yZzwvYT4NCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJl
ZXRleHQiIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zc2Qi
Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG5zc2Q8L2E+DQo8L3ByZT4N
CjwvYmxvY2txdW90ZT4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_bae4578e9f1d0d658829eb301d7f70dbericssoncom_--


From nobody Sat Nov  3 18:55:48 2018
Return-Path: <huitema@huitema.net>
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 2512D12D4E6 for <dnssd@ietfa.amsl.com>; Sat,  3 Nov 2018 18:55:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMUmxx9saJx3 for <dnssd@ietfa.amsl.com>; Sat,  3 Nov 2018 18:55:44 -0700 (PDT)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE3E5128BCC for <dnssd@ietf.org>; Sat,  3 Nov 2018 18:55:43 -0700 (PDT)
Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gJ7dd-0008JJ-JW for dnssd@ietf.org; Sun, 04 Nov 2018 02:55:42 +0100
Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1gJ7dY-0002Oi-SO for dnssd@ietf.org; Sat, 03 Nov 2018 21:55:37 -0400
Received: (qmail 14392 invoked from network); 4 Nov 2018 01:55:32 -0000
Received: from unknown (HELO [31.133.149.93]) (Authenticated-user:_huitema@huitema.net@[31.133.149.93]) (envelope-sender <huitema@huitema.net>) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for <dnssd@ietf.org>; 4 Nov 2018 01:55:31 -0000
To: dnssd@ietf.org
References: <48bc4612-018e-7aac-6492-05657c466313@huitema.net> <28F9784B-6243-453E-8926-A4EA039217C9@apple.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata= xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <bd86e271-2cb8-e3c1-8a2b-7b6ad1b07363@huitema.net>
Date: Sun, 4 Nov 2018 08:55:29 +0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <28F9784B-6243-453E-8926-A4EA039217C9@apple.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
X-Originating-IP: 168.144.250.231
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.32)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5iYr/1f9DhKXKEeud1fu/w5602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxsUJvgTFbE6bpcsiQLR68qVDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5gla7yk9cQlpQyisTE3JepE5EpHPznVavQp4h 1cyzxbQFXqQgkkYk8mNUb0+uxPxh1SJjtqxg9ToQOYgvpTXfiGuWFHL2CFALT37iujGyMC2K4cpU ualkQCN89mFr4hzV9Toz96geSJlwqLmXoHr6lp7KuHNaaKdg7iBEZefdsNV4YIf5ImMTjwbMKp8Y PS53nf7PGnOpecYaJDTU+UZIqwmLmW5xejNwBYllkh0bdnaMr5g51/dlPiU31fwEOKxqkVWClPVv bW5lVyQanRxw5nX9q2g89emBxjk4vbSaEK4mBBZyuzyr5ZxdVdkNxbnSdADg25CDX78caB9Pgj1m GtOITDa6LxNU+V0EKPyMEBNyxTnaYDGrcFhcWdN8WJ/kojmX5u6QQ8A3tr7Vu+yOdzuUcUw82oJH NumIeSk+phZG047RODDSOAU8VRBdjarRhquvBzKEzdsRbaiLpp7t87ZNvhN3LQlcXUm7c+4sJSS4 E4wEuUnsmRe7F3MGeyJeF38+1Ld/o5jGCpWO7tD53Zo5mMl7zU5iUyA2L29tUc1gy7a4XBIVNwIx j/+TVqdzhN6k/jWdd5JAUDIoPsO/pO/BYTkEOOb1RnEQ4ngzvGbLm0j/4xGRSH4jmGjWq+Sp9R/2 gMGq0KWAzmMf+ibVDrD2Ztt6Q8YW92VRrLWLRLx3Cau2PfsL3/JUcd0arQH0qgmimWMOaQfKKyR3 R8Z5yFss+n2ffnQxt6aJ7klZab+hIGHWVnRxW2VRSAIC84Y0TCFzbdHp875yVjNUvaMOXYpado7U VGYebUJcnJQ5nNwxL7hrJSk60SF3F6RYOYr2
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/kneh_x0GR3ehPpGF_C24p6QL7tw>
Subject: Re: [dnssd] Next steps for privacy discovery
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 04 Nov 2018 01:55:46 -0000

On 10/26/2018 11:57 PM, Bob Bradley wrote:
> If I understand correctly, a revision to draft-ietf-dnssd-privacy-05 wo=
uld change it from each server advertising a _pds._tcp service instance f=
or each of its paired peers to advertising a single _pds._tcp service ins=
tance for only itself (which sounds like a nice improvement). For that ca=
se, I think the scalability comparison between predictable nonces vs tria=
l decryptions would be the cost of filtering additional multicast traffic=
 vs performing additional signature verifications.
>
> Assuming a network with 50 peers and 3 of them I'm paired to, here's my=
 understanding of the work between the two approaches:
>
> Predictable nonces:
>
> When I join the network and start discovery, I announce my own _pds._tc=
p service instance (hash of time). Each peer would receive it and for eac=
h of its paired peers, calculate PrivateInstanceName =3D <time> | hash( <=
time> | <peer public key> ) and compare that to the announced name (47 ig=
nore it, 3 cache it). Then send a PTR query for _pds._tcp. Each peer on t=
he network responds with its own _pds._tcp service instance. For each res=
ponse I receive, calculate a PrivateInstanceName for each of my paired pe=
ers and compare each response to my list of PrivateInstanceNames (47 igno=
red, 3 cached).
>
> Trial decryptions:
>
> When I join the network and start discovery, I announce my availability=
 via a probe (signature of time) . Each would peer would receive it and f=
or each of its paired peers, perform a signature verification (47 ignore =
it and 3 cache it). The 3 paired peers send a response. When I receive ea=
ch response, perform a signature verification against each of my paired p=
eers (which should succeed so it caches all 3 responses).
>
> The question seems to be whether the traffic reduction in the trial dec=
ryption approach of only needing to respond to paired peers is worth the =
CPU cost of additional signature verifications.
>
> Another option could be to use the predictable nonce approach, but in t=
he PTR query for _pds._tcp, include an additional record containing the p=
redictable nonce of the querier. The receiver could use this to suppress =
responses to unpaired peers. This could provide a similar traffic reducti=
on to the trial decryption approach while retaining the CPU optimization =
of predictable nonces.

I do like the reduction in number of queries caused by "trial
decryption". As you point out the CPU cost could be mitigated by adding
a predictable nonce to the client queries, with the "proof" part of the
nonce computed by hashing the client's public key.

The idea of sending queries signed by the client is indeed sound, as it
enables servers to only respond to authorized clients. But it requires
that servers process queries in real time, and that's not compatible
with the "server based" mode of DNSSD, in which application servers
prepare responses in advance and store them in records published by the
DNS servers. So the decision boils down to how much compatibility we
want to retain with the "server based" more of operation.

-- Christian Huitema


From nobody Sun Nov  4 23:14:05 2018
Return-Path: <internet-drafts@ietf.org>
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 29D5B1271FF; Sun,  4 Nov 2018 23:13:59 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: <i-d-announce@ietf.org>
Cc: dnssd@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.87.3
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: dnssd@ietf.org
Message-ID: <154140203914.26545.5434828079350971440@ietfa.amsl.com>
Date: Sun, 04 Nov 2018 23:13:59 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/hDmbTDog1XfFZld-9-guNFk_LLg>
Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-16.txt
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2018 07:13:59 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Extensions for Scalable DNS Service Discovery WG of the IETF.

        Title           : DNS Push Notifications
        Authors         : Tom Pusateri
                          Stuart Cheshire
	Filename        : draft-ietf-dnssd-push-16.txt
	Pages           : 37
	Date            : 2018-11-04

Abstract:
   The Domain Name System (DNS) was designed to return matching records
   efficiently for queries for data that are relatively static.  When
   those records change frequently, DNS is still efficient at returning
   the updated results when polled, as long as the polling rate is not
   too high.  But there exists no mechanism for a client to be
   asynchronously notified when these changes occur.  This document
   defines a mechanism for a client to be notified of such changes to
   DNS records, called DNS Push Notifications.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnssd-push-16
https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-push-16

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-16


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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Sun Nov  4 23:17:20 2018
Return-Path: <pusateri@bangj.com>
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 831DE1271FF for <dnssd@ietfa.amsl.com>; Sun,  4 Nov 2018 23:17:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 0fI3gVQ-N3mX for <dnssd@ietfa.amsl.com>; Sun,  4 Nov 2018 23:17:16 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2452130DCE for <dnssd@ietf.org>; Sun,  4 Nov 2018 23:17:16 -0800 (PST)
Received: from [172.16.10.101] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 3DFCE21C39 for <dnssd@ietf.org>; Mon,  5 Nov 2018 02:17:15 -0500 (EST)
From: Tom Pusateri <pusateri@bangj.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Mon, 5 Nov 2018 02:17:13 -0500
References: <154140203914.26545.5434828079350971440@ietfa.amsl.com>
To: dnssd@ietf.org
In-Reply-To: <154140203914.26545.5434828079350971440@ietfa.amsl.com>
Message-Id: <812EE021-F975-44F4-9926-F6802C0DC534@bangj.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/TLdh_8L_1dVSa0eiqNoHVNHUjZs>
Subject: Re: [dnssd] I-D Action: draft-ietf-dnssd-push-16.txt
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2018 07:17:20 -0000

This new version addresses the comments received from Ted Lemon and Jan =
Komissar during the working group last call. If you followed the =
discussion on the list, Ted provided some thoughtful clarification text =
and Jan kept us honest following the DNS Stateful Operations draft.

Thanks,
Tom


> On Nov 5, 2018, at 2:13 AM, internet-drafts@ietf.org wrote:
>=20
>=20
> A New Internet-Draft is available from the on-line Internet-Drafts =
directories.
> This draft is a work item of the Extensions for Scalable DNS Service =
Discovery WG of the IETF.
>=20
>        Title           : DNS Push Notifications
>        Authors         : Tom Pusateri
>                          Stuart Cheshire
> 	Filename        : draft-ietf-dnssd-push-16.txt
> 	Pages           : 37
> 	Date            : 2018-11-04
>=20
> Abstract:
>   The Domain Name System (DNS) was designed to return matching records
>   efficiently for queries for data that are relatively static.  When
>   those records change frequently, DNS is still efficient at returning
>   the updated results when polled, as long as the polling rate is not
>   too high.  But there exists no mechanism for a client to be
>   asynchronously notified when these changes occur.  This document
>   defines a mechanism for a client to be notified of such changes to
>   DNS records, called DNS Push Notifications.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-dnssd-push/
>=20
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-dnssd-push-16
> https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-push-16
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dnssd-push-16
>=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
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>=20
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd


From nobody Wed Nov  7 07:57:45 2018
Return-Path: <daniel.kaiser@uni-konstanz.de>
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 8EE4D130DCA for <dnssd@ietfa.amsl.com>; Wed,  7 Nov 2018 07:57:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t28m3gbeJ0wF for <dnssd@ietfa.amsl.com>; Wed,  7 Nov 2018 07:57:40 -0800 (PST)
Received: from thurn.uni-konstanz.de (thurn.uni-konstanz.de [134.34.240.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66EC9130DC8 for <dnssd@ietf.org>; Wed,  7 Nov 2018 07:57:40 -0800 (PST)
Received: from lyrae.kim.uni-konstanz.de (lyrae.kim.uni-konstanz.de [134.34.240.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by thurn.uni-konstanz.de (Postfix) with ESMTPS id 42qrf92wPJzVW; Wed,  7 Nov 2018 16:57:37 +0100 (CET)
Received: from [192.168.1.12] (unknown [87.240.243.50]) by lyrae.kim.uni-konstanz.de (Postfix) with ESMTPSA id 400301179DC4C; Wed,  7 Nov 2018 16:57:37 +0100 (CET)
References: <48bc4612-018e-7aac-6492-05657c466313@huitema.net> <28F9784B-6243-453E-8926-A4EA039217C9@apple.com> <bd86e271-2cb8-e3c1-8a2b-7b6ad1b07363@huitema.net>
From: Daniel Kaiser <daniel.kaiser@uni-konstanz.de>
To: dnssd@ietf.org, bradley@apple.com
Cc: Christian Huitema <huitema@huitema.net>
Message-ID: <2241b60d-6d28-40c4-38ea-3545f04ce57c@uni-konstanz.de>
Date: Wed, 7 Nov 2018 16:57:36 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <bd86e271-2cb8-e3c1-8a2b-7b6ad1b07363@huitema.net>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/Yd9b-Hl0li8fTcWwkMiqPTnWbhQ>
Subject: Re: [dnssd] Next steps for privacy discovery
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2018 15:57:44 -0000

Summarizing, the differences between our privacy draft and the new
privacy draft are:

(1)  keys derived from shared secrets    vs     keys derived from
asymmetric keys
(2)  hints (using predictable nonces)      vs     trial decryptions
(3)  backwards compatibility                  vs     defining new RRs


My question is: Why do we need another privacy draft?
The new draft also uses our two-stage approach, meaning first
discovering paired peers and then engaging in direct discovery with them.
Issue (1) already came up during past meetings; as soon as we have
consensus, we can go ahead and adapt our draft accordingly.
Regarding issue (2) nobody opposed when we suggested using hints instead
of trial decryptions for performance reasons. We could assess this issue
again.
I also like the idea Bob Bradley pointed out: sending a predictable
nonce in the client PTR query to allow for suppressing unnecessary messages.
This is similar to our direct query method, which also reduces the
number of sent messages (we should discuss this as well).
We should try to get consensus on (3) tomorrow; if defining new RRs is
the preferred way, we could merge that part into our draft.

Further, in past meetings there has been discussion as to whether we
should switch to a one-stage approach supporting a per-app model, or
stick with our two-stage approach.
We could also support both, which I would prefer, modeling the second
stage of the two-stage approach as a service of
a "DNS server app" that is discoverable via a privacy preserving
one-stage solution.

Also, I wanted to ask if the new draft is meant for DNS-SD/mDNS
exclusively or also for DNS-SD/DNS.
I think, the protocol should not be called Bonjour, because Bonjour is
the name of a concrete implementation of DNS-SD/mDNS.


Kind regards,
Daniel Kaiser


-- 

Dr. Daniel Kaiser
Research Associate
SnT- Interdisciplinary Centre for Security, Reliability and Trust

University of Luxembourg
Maison du Nombre (MNO)
6, avenue de la Fonte
L-4364 Esch-sur-Alzette
Office: E02 0225-010




On 11/04/2018 02:55 AM, Christian Huitema wrote:
>
> On 10/26/2018 11:57 PM, Bob Bradley wrote:
>> If I understand correctly, a revision to draft-ietf-dnssd-privacy-05 would change it from each server advertising a _pds._tcp service instance for each of its paired peers to advertising a single _pds._tcp service instance for only itself (which sounds like a nice improvement). For that case, I think the scalability comparison between predictable nonces vs trial decryptions would be the cost of filtering additional multicast traffic vs performing additional signature verifications.
>>
>> Assuming a network with 50 peers and 3 of them I'm paired to, here's my understanding of the work between the two approaches:
>>
>> Predictable nonces:
>>
>> When I join the network and start discovery, I announce my own _pds._tcp service instance (hash of time). Each peer would receive it and for each of its paired peers, calculate PrivateInstanceName = <time> | hash( <time> | <peer public key> ) and compare that to the announced name (47 ignore it, 3 cache it). Then send a PTR query for _pds._tcp. Each peer on the network responds with its own _pds._tcp service instance. For each response I receive, calculate a PrivateInstanceName for each of my paired peers and compare each response to my list of PrivateInstanceNames (47 ignored, 3 cached).
>>
>> Trial decryptions:
>>
>> When I join the network and start discovery, I announce my availability via a probe (signature of time) . Each would peer would receive it and for each of its paired peers, perform a signature verification (47 ignore it and 3 cache it). The 3 paired peers send a response. When I receive each response, perform a signature verification against each of my paired peers (which should succeed so it caches all 3 responses).
>>
>> The question seems to be whether the traffic reduction in the trial decryption approach of only needing to respond to paired peers is worth the CPU cost of additional signature verifications.
>>
>> Another option could be to use the predictable nonce approach, but in the PTR query for _pds._tcp, include an additional record containing the predictable nonce of the querier. The receiver could use this to suppress responses to unpaired peers. This could provide a similar traffic reduction to the trial decryption approach while retaining the CPU optimization of predictable nonces.
> I do like the reduction in number of queries caused by "trial
> decryption". As you point out the CPU cost could be mitigated by adding
> a predictable nonce to the client queries, with the "proof" part of the
> nonce computed by hashing the client's public key.
>
> The idea of sending queries signed by the client is indeed sound, as it
> enables servers to only respond to authorized clients. But it requires
> that servers process queries in real time, and that's not compatible
> with the "server based" mode of DNSSD, in which application servers
> prepare responses in advance and store them in records published by the
> DNS servers. So the decision boils down to how much compatibility we
> want to retain with the "server based" more of operation.
>
> -- Christian Huitema
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd


From nobody Wed Nov  7 08:00:37 2018
Return-Path: <daniel.kaiser@uni-konstanz.de>
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 3769D130DC8 for <dnssd@ietfa.amsl.com>; Wed,  7 Nov 2018 08:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level: 
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzW4xqto0UHT for <dnssd@ietfa.amsl.com>; Wed,  7 Nov 2018 08:00:33 -0800 (PST)
Received: from tasso.uni-konstanz.de (tasso.uni-konstanz.de [134.34.240.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB3751274D0 for <dnssd@ietf.org>; Wed,  7 Nov 2018 08:00:32 -0800 (PST)
Received: from lyrae.kim.uni-konstanz.de (lyrae.kim.uni-konstanz.de [134.34.240.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by tasso.uni-konstanz.de (Postfix) with ESMTPS id 42qrjV4zM9zpm; Wed,  7 Nov 2018 17:00:30 +0100 (CET)
Received: from [192.168.1.12] (unknown [87.240.243.50]) by lyrae.kim.uni-konstanz.de (Postfix) with ESMTPSA id 9197D117A01C7; Wed,  7 Nov 2018 17:00:30 +0100 (CET)
References: <48bc4612-018e-7aac-6492-05657c466313@huitema.net> <28F9784B-6243-453E-8926-A4EA039217C9@apple.com> <bd86e271-2cb8-e3c1-8a2b-7b6ad1b07363@huitema.net>
From: Daniel Kaiser <daniel.kaiser@uni-konstanz.de>
To: "dnssd@ietf.org" <dnssd@ietf.org>
Cc: Christian Huitema <huitema@huitema.net>
Message-ID: <618389df-c34e-5ffd-f157-98dff7876746@uni-konstanz.de>
Date: Wed, 7 Nov 2018 17:00:30 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <bd86e271-2cb8-e3c1-8a2b-7b6ad1b07363@huitema.net>
Content-Type: multipart/mixed; boundary="------------8B3AAD7DC83BF840CD8D8D3B"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/0HOqG7xc1cAWD4a-DK5jL6U6VU0>
Subject: Re: [dnssd] Next steps for privacy discovery
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2018 16:00:36 -0000

This is a multi-part message in MIME format.
--------------8B3AAD7DC83BF840CD8D8D3B
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Regarding the trade-off between hinting using predictable nonces and
trial decryptions,
I wanted to add that we could also use a bloomfilter based solution for
reducing the
number of necessary hinting messages while not needing costly trial
decryptions.

I summarized the current state of my idea in the attached markdown document.
If you are interested, I could elaborate on this idea.

Kind regards,
Daniel Kaiser


-- 

Dr. Daniel Kaiser
Research Associate
SnT- Interdisciplinary Centre for Security, Reliability and Trust

University of Luxembourg
Maison du Nombre (MNO)
6, avenue de la Fonte
L-4364 Esch-sur-Alzette
Office: E02 0225-010



On 11/04/2018 02:55 AM, Christian Huitema wrote:
>
> On 10/26/2018 11:57 PM, Bob Bradley wrote:
>> If I understand correctly, a revision to draft-ietf-dnssd-privacy-05 would change it from each server advertising a _pds._tcp service instance for each of its paired peers to advertising a single _pds._tcp service instance for only itself (which sounds like a nice improvement). For that case, I think the scalability comparison between predictable nonces vs trial decryptions would be the cost of filtering additional multicast traffic vs performing additional signature verifications.
>>
>> Assuming a network with 50 peers and 3 of them I'm paired to, here's my understanding of the work between the two approaches:
>>
>> Predictable nonces:
>>
>> When I join the network and start discovery, I announce my own _pds._tcp service instance (hash of time). Each peer would receive it and for each of its paired peers, calculate PrivateInstanceName = <time> | hash( <time> | <peer public key> ) and compare that to the announced name (47 ignore it, 3 cache it). Then send a PTR query for _pds._tcp. Each peer on the network responds with its own _pds._tcp service instance. For each response I receive, calculate a PrivateInstanceName for each of my paired peers and compare each response to my list of PrivateInstanceNames (47 ignored, 3 cached).
>>
>> Trial decryptions:
>>
>> When I join the network and start discovery, I announce my availability via a probe (signature of time) . Each would peer would receive it and for each of its paired peers, perform a signature verification (47 ignore it and 3 cache it). The 3 paired peers send a response. When I receive each response, perform a signature verification against each of my paired peers (which should succeed so it caches all 3 responses).
>>
>> The question seems to be whether the traffic reduction in the trial decryption approach of only needing to respond to paired peers is worth the CPU cost of additional signature verifications.
>>
>> Another option could be to use the predictable nonce approach, but in the PTR query for _pds._tcp, include an additional record containing the predictable nonce of the querier. The receiver could use this to suppress responses to unpaired peers. This could provide a similar traffic reduction to the trial decryption approach while retaining the CPU optimization of predictable nonces.
> I do like the reduction in number of queries caused by "trial
> decryption". As you point out the CPU cost could be mitigated by adding
> a predictable nonce to the client queries, with the "proof" part of the
> nonce computed by hashing the client's public key.
>
> The idea of sending queries signed by the client is indeed sound, as it
> enables servers to only respond to authorized clients. But it requires
> that servers process queries in real time, and that's not compatible
> with the "server based" mode of DNSSD, in which application servers
> prepare responses in advance and store them in records published by the
> DNS servers. So the decision boils down to how much compatibility we
> want to retain with the "server based" more of operation.
>
> -- Christian Huitema
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd


--------------8B3AAD7DC83BF840CD8D8D3B
Content-Type: text/plain; charset=UTF-8;
 name="bloomfilter_discovery.md"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
 filename="bloomfilter_discovery.md"

QWJzdHJhY3QKPT09ClRoZSBtZXRob2QgcHJvcG9zZWQgaW4gdGhpcyBkb2N1bWVudCBzaWdu
aWZpY2FudGx5IHJlZHVjZXMgdGhlIG51bWJlciBvZiBtdWx0aWNhc3QgKHB1YmxpYykgbWVz
c2FnZXMKZm9yIG91ciAxOjEgcGFpcmluZyBiYXNlZCBETlMtU0QgcHJpdmFjeSBleHRlbnNp
b24gW2RyYWZ0LWlldGYtZG5zc2QtcHJpdmFjeS0wNV0uCkl0IHVzZXMgQmxvb21maWx0ZXIg
aGludHMgYW5kIGFuIGFkZGl0aW9uYWwgcm91bmQgb2YgbWVzc2FnZXMuClRoZSBhZGRpdGlv
bmFsIHJvdW5kIG9mIG1lc3NhZ2VzIGNvdWxkIGJlIHNraXBwZWQgYXQgdGhlIGNvc3Qgb2Yg
bG9zaW5nIGEgbGl0dGxlIHNlcnZlci1zaWRlIHByaXZhY3kuCgoKUHJvdG9jb2wKPT09ClRo
aXMgc2VjdGlvbiBpbGx1c3RyYXRlcyB2YXJpb3VzIHNjZW5hcmlvcyB3aGVyZSBBbGljZSB3
YW50cyB0byBkaXNjb3ZlciBhIHBzZHMgc2VydmljZSBpbnN0YW5jZSwKYW5kIEJvYiBvZmZl
cnMgc3VjaCBhbiBpbnN0YW5jZS4KV2hpbGUgdGhpcyBkb2N1bWVudCBmb2N1c2VzIG9uIGRp
c2NvdmVyaW5nIGEgcHNkcyBzZXJ2aWNlIGluc3RhbmNlICh0d28tc3RhZ2Ugc29sdXRpb24p
LAp0aGUgcHJvcG9zZWQgbWV0aG9kIGNhbiBhbHNvIGJlIHVzZWQgd2l0aCBvdGhlciBzZXJ2
aWNlIHR5cGVzIHN1cHBvcnRpbmcgYSBvbmUtc3RhZ2Ugc29sdXRpb24uCgpbYmZcXzFdLC4u
LixbYmZcX25dIGFyZSBCbG9vbWZpbHRlcnMgd2hvc2UgY29uc3RydWN0aW9uIGlzIGRlc2Ny
aWJlZCBpbiB0aGUgbmV4dCBzZWN0aW9uLgoKIyMjIHBhaXJpbmcgZXhpc3RzCgogICAgQWxp
Y2UgICAgICAgICAgICAgICAgICAgICAgICAgIEJvYgogICAgCiAgICBfcHNkcz8KICAgICAg
ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+CiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIFtiZl8xXS5fcHNkcwogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAu
Li4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2JmX25dLl9wc2RzCiAgICAg
ICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogICAgW2JmXzFdLl9wc2RzPwogICAgICAg
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBub25jZQogICAgICAgIDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KICAgIGhhc2go
ZGVyaXZlKHNlY3JldCl8fG5vbmNlKQogICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LT4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTUlYsVFhULEEKICAgICAgICA8
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAgICBjb25uZWN0IHRvIHNlcnZpY2UKICAgICAg
ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+CgpPbmx5IHRoZSBmaXJzdCB0d28gbWVzc2Fn
ZXMgYXJlIG11bHRpY2FzdCAocHVibGljKS4KVGhlIGNoYWxsZW5nZSByZXNwb25zZSBtZXNz
YWdlcyBjb3VsZCBiZSBza2lwcGVkIGF0IHRoZSBjb3N0IG9mIGEgbGl0dGxlIHNlcnZlci1z
aWRlIHByaXZhY3kuCgojIyMgcGFpcmluZyBkb2VzIG5vdCBleGlzdAoKYSkgbm8gZmFsc2Ug
cG9zaXRpdmU6CgogICAgQWxpY2UgICAgICAgICAgICAgICAgICAgICAgICAgIEJvYgogICAg
CiAgICBfcHNkcz8KICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+CiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgIFtiZl8xXS5fcHNkcwogICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAuLi4KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
W2JmX25dLl9wc2RzCiAgICAgICAgPC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQogICAgbm9u
ZSBvZiB0aGUKICAgIGJsb29tZmlsdGVycwogICAgbWF0Y2gKCkluIHRoaXMgY2FzZSwgYSBs
b3Qgb2YgbWVzc2FnZXMgd2VyZSBzYXZlZCwgYXMgYSBzZXZlcmVseSBjb21wcmVzc2VkIHZl
cnNpb24Kb2YgdGhlIGhpbnRzIHdhcyBzdWZmaWNpZW50IGZvciBBbGljZSB0byByZWFsaXpl
IHRoYXQgdGhpcyBzZXJ2aWNlIGluc3RhbmNlIHdhcyBub3QKbWVhbnQgZm9yIGhlci4KCmEp
IGZhbHNlIHBvc2l0aXZlOgoKICBBbGljZSAgICAgICAgICAgICAgICAgICAgICAgICAgQm9i
CiAgICAKICAgIF9wc2RzPwogICAgICAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT4KICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW2JmXzFdLl9wc2RzCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgIC4uLgogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBbYmZfbl0uX3BzZHMKICAgICAgICA8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAg
ICBbYmYxXS5fcHNkcz8KICAgICAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+CiAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgbm9uY2UKICAgICAgICA8LS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tCiAgICBoYXNoKChkZXJpdmUoc2VjcmV0KXx8bm9uY2UpCiAgICAgICAg
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPgogICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgIG5vIG1hdGNoCgpCb2IgY291bGQgYWxzbyBzZW5kIGUuZy4gYW4gZW5jcnlwdGVkIHRp
bWVzdGFtcApzbyB0aGF0IEFsaWNlIGNhbiBjaGVjayB0aGUgaGl0IHdhcyBhIGZhbHNlIHBv
c2l0aXZlLCBhbmQgaWYgeWVzLApub3Qgc2VuZCB0aGUgY2hhbGxlbmdlIHJlc3BvbnNlLgpJ
biB0aGlzIGNhc2UsIHRoZSBhbW91bnQgb2YgbWVzc2FnZXMgc2F2ZWQgc2hvdWxkIHN0aWxs
Cmp1c3RpZnkgdGhlIHNtYWxsIGludHJvZHVjZWQgY29tcHV0YXRpb25hbCBvdmVyaGVhZCBh
bmQgdGhlIGFkZGl0aW9uYWwgdW5pY2FzdCBtZXNzYWdlcy4KCkFnYWluc3QgYW4gYXR0YWNr
ZXIgd2hvIHRyaWVzIHRvIGRlY2VpdmUgQm9iLAp0aGUgZGlhZ3JhbSBsb29rcyB0aGUgc2Ft
ZSwgYXMgdGhlIGF0dGFja2VyIHdpbGwgbm90IGJlIGFibGUgdG8Kc2VuZCBhIG1hdGNoaW5n
IGNoYWxsZW5nZSByZXNwb25zZS4KCgoKQ29uc3RydWN0aW9uIG9mIHRoZSBCbG9vbWZpbHRl
cnMKPT09ClRoZSBCbG9vbWZpbHRlcnMsIFtiZlxfMV0sLi4uLFtiZlxfbl0sIGluIHRoZQpw
cm90b2NvbCBkZXNjcmlwdGlvbiBhYm92ZSwgYXJlIGNvbnN0cnVjdGVkIGFzIGZvbGxvd3M6
CgoqIGZvciBlYWNoIHBhaXJlZCBjbGllbnQsIHB1dCBhbiBpZGVudGlmaWVyIG9mIHRoZSBm
b3JtIGhhc2goZGVyaXZlKHNlY3JldCl8fG5vbmNlKQogIGludG8gYSBCbG9vbWZpbHRlciBi
ZlxfMS4KKiBpZiB0aGUgZmFsc2UtcG9zaXRpdmUgcHJvYmFiaWxpdHkgb2YgYmZcX2kgZXhj
ZWVkcyBhIGNlcnRhaW4gdGhyZXNob2xkICh0byBiZSBpbnZlc3RpZ2F0ZWQpLAogIHN0YXJ0
IGEgbmV3IEJsb29tZmlsdGVyIGJmXF9pKzEuCiogZW5jb2RlIHRoZSBCbG9vbWZpbHRlcnMg
aW4gYmFzZTY0IGFuZCBwdWJsaXNoIHRoZW0gYXMgc2VydmljZSBpbnN0YW5jZXMgb2YgdHlw
ZSBwc2RzLgoK
--------------8B3AAD7DC83BF840CD8D8D3B--


From nobody Wed Nov  7 23:27:40 2018
Return-Path: <cheshire@apple.com>
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 575D6127332 for <dnssd@ietfa.amsl.com>; Wed,  7 Nov 2018 23:27:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.47
X-Spam-Level: 
X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sL0jfF7Yl_9Q for <dnssd@ietfa.amsl.com>; Wed,  7 Nov 2018 23:27:37 -0800 (PST)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95440124408 for <dnssd@ietf.org>; Wed,  7 Nov 2018 23:27:37 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id wA87RA1t048277 for <dnssd@ietf.org>; Wed, 7 Nov 2018 23:27:36 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : content-transfer-encoding : subject : message-id : date : to; s=20180706; bh=GwsCUVC+HTfZAmgNGNj4koggzhO30AuCCH6ozfh4C/s=; b=J6c7IkVBjFP7cWxSRG74gpUn6Ha7Qg/EBPnm/P6L+7wdoAYycumurvB3BFW6dsSPZdsi 628u7hpubxu1j2Ck0KuX0Jnj9vPNE1uXcjFS7yiWfSRxoHz/yXwYrzGIhc30HpzhXW2f hD6saVbtO1YdrRbl9ACVnAeC4xPofet/skVoW3MHrUnGD6M2w++Z3Z1W8KLwx0GXq4Qj eDRGPIDX5PhlUlrxm9f1QKfOPWuIIx0JieEdJQVZDiK2J9NAHN+GyK0P9enoLSXJ8AK8 dRBDBRTXkhFs45K6NpgLaoGcE8+dq+oqJ/bpnfpNiaTU+Twipm7gk7VZ0zQNyA37AkGc vQ== 
Received: from mr2-mtap-s02.rno.apple.com (mr2-mtap-s02.rno.apple.com [17.179.226.134]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2njw0p251v-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dnssd@ietf.org>; Wed, 07 Nov 2018 23:27:36 -0800
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Received: from ma1-mmpp-sz10.apple.com (ma1-mmpp-sz10.apple.com [17.171.128.150]) by mr2-mtap-s02.rno.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PHV006RM61ZT470@mr2-mtap-s02.rno.apple.com> for dnssd@ietf.org; Wed, 07 Nov 2018 23:27:35 -0800 (PST)
Received: from process_viserion-daemon.ma1-mmpp-sz10.apple.com by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHV008004O7SF00@ma1-mmpp-sz10.apple.com> for dnssd@ietf.org; Wed, 07 Nov 2018 23:27:35 -0800 (PST)
X-Va-A: 
X-Va-T-CD: 30a9c062f6936833101a7e3ef1ad5808
X-Va-E-CD: ca1944080701937c2687519b2dfbcadb
X-Va-R-CD: 3a88c0f604259e996926854105981d4a
X-Va-CD: 0
X-Va-ID: eaaa0eec-7cfb-44ac-a522-dba4d6736bf7
X-V-A: 
X-V-T-CD: 9cb739ef05cf90679a21e4dc783575a9
X-V-E-CD: ca1944080701937c2687519b2dfbcadb
X-V-R-CD: 3a88c0f604259e996926854105981d4a
X-V-CD: 0
X-V-ID: b033e376-028b-4461-8482-1b88ce9bab6b
Received: from process_milters-daemon.ma1-mmpp-sz10.apple.com by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PHV00D004VI3F00@ma1-mmpp-sz10.apple.com> for dnssd@ietf.org; Wed, 07 Nov 2018 23:27:33 -0800 (PST)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-08_03:,, signatures=0
Received: from [17.234.146.214] (unknown [17.234.146.214]) by ma1-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PHV00MIE61Q8I00@ma1-mmpp-sz10.apple.com> for dnssd@ietf.org; Wed, 07 Nov 2018 23:27:33 -0800 (PST)
Sender: cheshire@apple.com
From: Stuart Cheshire <cheshire@apple.com>
Content-transfer-encoding: quoted-printable
Message-id: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com>
Date: Thu, 08 Nov 2018 14:27:24 +0700
To: dnssd@ietf.org
X-Mailer: Apple Mail (2.3445.9.1)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-08_03:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/A7c1oJuCo8gRxgYlSzuZm9gp44U>
Subject: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 07:27:39 -0000

Here is a link to the new draft Ted Lemon and I wrote as a result of our =
work at the Hackathon here at IETF 103.

<https://tools.ietf.org/html/draft-sctl-dnssd-unicast-autoconfig-00>

Here=E2=80=99s a brief summary of what the document is about:

   Because multicast can be inefficient and unreliable, work is
   taking place to enable DNS-Based Service Discovery to operate
   with less reliance on multicast.  One current target use case
   for this work is Thread wireless mesh networking.

   Existing work describes how DNS-Based Service Discovery can
   be performed using unicast on such a network.  Devices on
   the Thread mesh offering services use Service Registration
   Protocol to register their services at a Service Registration
   Server.  Devices seeking to discover these services send
   unicast queries to the Service Registration Server using
   unicast DNS for single individual queries, and using DNS Push
   Notifications where ongoing change notification is required.

   For proof-of-concept experiments, the necessary information can
   be configured manually, and this has been done successfully.
   For deployment, we need to determine how the necessary information
   will be learned and configured automatically in real-world scenarios.

Stuart Cheshire


From nobody Thu Nov  8 00:26:14 2018
Return-Path: <swmike@swm.pp.se>
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 9A0EE127333 for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 00:26:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9-0dzuJOOBKQ for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 00:26:10 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851BE124408 for <dnssd@ietf.org>; Thu,  8 Nov 2018 00:26:10 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4290EB0; Thu,  8 Nov 2018 09:26:08 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1541665568; bh=QNZibL1caxuOibM1Vadu5/VzkM2X8e1OParH2PNARpA=; h=Date:From:To:Subject:From; b=TsZkIDePlkH2eNtcuAcxaUDxoSVoKjAsgLBjSX7NGMPgQEcFjyUDpk4yS8C7zAe+b HSSns0c6HG5+dbnBfUF4VlDvuVitdG4GxAFJF1wd3rPAOUQtN9B8WIMD8IfgIusz78 XDQk4/Xp/4MP+KSkJj4cMWHcoyoglSG5uVkVbIFA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 40D91AF for <dnssd@ietf.org>; Thu,  8 Nov 2018 09:26:08 +0100 (CET)
Date: Thu, 8 Nov 2018 09:26:08 +0100 (CET)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: dnssd@ietf.org
Message-ID: <alpine.DEB.2.20.1811080925290.29822@uplift.swm.pp.se>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/RCxb2qc0wY6_gWFTRPu_MdRS7Ks>
Subject: [dnssd] regarding the multicast over wireless statements I made in the session today
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 08:26:13 -0000

https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-03

This is the draft I was talking about.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Thu Nov  8 07:35:31 2018
Return-Path: <touch@strayalpha.com>
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 71349128BCC for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 07:35:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 12a3BoMjqnNC for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 07:35:28 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BDC2124BAA for <dnssd@ietf.org>; Thu,  8 Nov 2018 07:35:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sy49+NpCieA4hgQWRxo9d6WbadOzj0G8B2RRK40DD0Q=; b=IhwLIXHwQBWtECqDHr7NfEpwx N1QDgXGmv71OTizDqkpAImHkXc6tesj+mGB+JntjMbzMO/GR+fG4ePEer0UpSyMUN2xbvkfU3rJub cWBGkCTVYD0otZNZiqPNf+L1GlV6lR1EUGDynmlyl3LnMTKT/2VwalvsM9c1HTUGjJvms6AHrxKlG bm7x+KBcNM/P6K2OE1HEHMrxghE7izEazUqUDWihC6BmPQQ+aT8/BW6rng+SI9qe76tjlaHo3AXM7 xRe94ytO9tkrebF0FBbTICDN1W/K0Ff4+YX5v+sotADY0z9DJSh2ZgoXsnN4aN93Y97mbGgW7BOZf mBnn6n8xg==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53228 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1gKmL7-002P4t-Me; Thu, 08 Nov 2018 10:35:27 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com>
Date: Thu, 8 Nov 2018 07:35:24 -0800
Cc: dnssd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com>
To: Stuart Cheshire <cheshire@apple.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/3A6n3UPNGy33Nc7jdl6b6VBcbv8>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 15:35:30 -0000

Hi Stuart, et al.,

I=E2=80=99m confused by the text below; given IPv6 configuration relies =
on multicast, why is it not reasonable to assume similarly useful =
multicast here?

Joe

> On Nov 7, 2018, at 11:27 PM, Stuart Cheshire <cheshire@apple.com> =
wrote:
>=20
> Here is a link to the new draft Ted Lemon and I wrote as a result of =
our work at the Hackathon here at IETF 103.
>=20
> <https://tools.ietf.org/html/draft-sctl-dnssd-unicast-autoconfig-00>
>=20
> Here=E2=80=99s a brief summary of what the document is about:
>=20
>   Because multicast can be inefficient and unreliable, work is
>   taking place to enable DNS-Based Service Discovery to operate
>   with less reliance on multicast.  One current target use case
>   for this work is Thread wireless mesh networking.
>=20
>   Existing work describes how DNS-Based Service Discovery can
>   be performed using unicast on such a network.  Devices on
>   the Thread mesh offering services use Service Registration
>   Protocol to register their services at a Service Registration
>   Server.  Devices seeking to discover these services send
>   unicast queries to the Service Registration Server using
>   unicast DNS for single individual queries, and using DNS Push
>   Notifications where ongoing change notification is required.
>=20
>   For proof-of-concept experiments, the necessary information can
>   be configured manually, and this has been done successfully.
>   For deployment, we need to determine how the necessary information
>   will be learned and configured automatically in real-world =
scenarios.
>=20
> Stuart Cheshire
>=20
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd


From nobody Thu Nov  8 13:10:54 2018
Return-Path: <pusateri@bangj.com>
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 DCFB212D7F8 for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 13:10:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3jnwyhzrN8Pd for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 13:10:51 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F089312D4E8 for <dnssd@ietf.org>; Thu,  8 Nov 2018 13:10:50 -0800 (PST)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 9A53C2219C; Thu,  8 Nov 2018 16:10:49 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com>
Date: Thu, 8 Nov 2018 16:10:47 -0500
Cc: Stuart Cheshire <cheshire@apple.com>, dnssd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/8qL0cj47ECmfkTSBqZaPW0wOeM4>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 21:10:53 -0000

If multicast packets are dropped during IPv6 configuration, you won=E2=80=99=
t get an IPv6 address and you won=E2=80=99t be able to communicate via =
IPv6. This is easy to detect. When multicast packets are lost during =
busy periods on wifi and services are not reliably discovered, there=E2=80=
=99s no easy way to detect this.

On busy wifi networks, multicast just isn=E2=80=99t reliable.

See =
https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-03

Tom

> On Nov 8, 2018, at 10:35 AM, Joe Touch <touch@strayalpha.com> wrote:
>=20
> Hi Stuart, et al.,
>=20
> I=E2=80=99m confused by the text below; given IPv6 configuration =
relies on multicast, why is it not reasonable to assume similarly useful =
multicast here?
>=20
> Joe
>=20
>> On Nov 7, 2018, at 11:27 PM, Stuart Cheshire <cheshire@apple.com> =
wrote:
>>=20
>> Here is a link to the new draft Ted Lemon and I wrote as a result of =
our work at the Hackathon here at IETF 103.
>>=20
>> <https://tools.ietf.org/html/draft-sctl-dnssd-unicast-autoconfig-00>
>>=20
>> Here=E2=80=99s a brief summary of what the document is about:
>>=20
>>  Because multicast can be inefficient and unreliable, work is
>>  taking place to enable DNS-Based Service Discovery to operate
>>  with less reliance on multicast.  One current target use case
>>  for this work is Thread wireless mesh networking.
>>=20
>>  Existing work describes how DNS-Based Service Discovery can
>>  be performed using unicast on such a network.  Devices on
>>  the Thread mesh offering services use Service Registration
>>  Protocol to register their services at a Service Registration
>>  Server.  Devices seeking to discover these services send
>>  unicast queries to the Service Registration Server using
>>  unicast DNS for single individual queries, and using DNS Push
>>  Notifications where ongoing change notification is required.
>>=20
>>  For proof-of-concept experiments, the necessary information can
>>  be configured manually, and this has been done successfully.
>>  For deployment, we need to determine how the necessary information
>>  will be learned and configured automatically in real-world =
scenarios.
>>=20
>> Stuart Cheshire
>>=20
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
>=20
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd


From nobody Thu Nov  8 13:54:54 2018
Return-Path: <touch@strayalpha.com>
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 87AC5130934 for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 13:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.988
X-Spam-Level: 
X-Spam-Status: No, score=-1.988 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 5llXhG-3s_01 for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 13:54:49 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C42A712D4E8 for <dnssd@ietf.org>; Thu,  8 Nov 2018 13:54:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=UIe3kQaAZxrTcwAfhamZP9L3hf1ZmuReduJwBDmuyso=; b=Ks0TnuKUS+YeHILOn0JyaxnK7 Fu1xFsrt87dgmSCudDSg3u1L959b1s8kWC5hIvK0z9lylbiVIS7k1hIlXqDQdEJVW0TC074qHsPCr 0mWnQqpdbhB0rVcTrf0rXtgq5gvy4gSVZ8JkwJIryEpSqGnPrIHNmLexFNRQlfA0CMLDcjrMK/BQQ G+LOeRUq/ClZ/Fp6PAuKh+LfxE8MdscI0pO39bNhSBxKai30CboZ1l3OPhnlFyf5ihU5FH61X+sNy mGlqcSsJtJe8Y8msIz2l4ELifLsro3AmU/fVX0eg31vH2+HHqGdJH9avADalIwBnT7HbOSYqWFBjs J+DlHOlXQ==;
Received: from [172.58.23.224] (port=23804 helo=[IPv6:2607:fb90:5a88:8a7c:3c1d:f4b:c3c7:e062]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1gKsGC-003azH-8z; Thu, 08 Nov 2018 16:54:47 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Joe Touch <touch@strayalpha.com>
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com>
Date: Thu, 8 Nov 2018 13:54:43 -0800
Cc: Stuart Cheshire <cheshire@apple.com>, dnssd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com> <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com>
To: Tom Pusateri <pusateri@bangj.com>
X-OutGoing-Spam-Status: No, score=-0.2
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/8IwJwBQLITDzjaVtITs9fdJoxkA>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 21:54:53 -0000

UDP isn=E2=80=99t reliable, period. Retransmit.=20

> On Nov 8, 2018, at 1:10 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>=20
> If multicast packets are dropped during IPv6 configuration, you won=E2=80=99=
t get an IPv6 address and you won=E2=80=99t be able to communicate via IPv6.=
 This is easy to detect. When multicast packets are lost during busy periods=
 on wifi and services are not reliably discovered, there=E2=80=99s no easy w=
ay to detect this.
>=20
> On busy wifi networks, multicast just isn=E2=80=99t reliable.
>=20
> See https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-0=
3
>=20
> Tom
>=20
>> On Nov 8, 2018, at 10:35 AM, Joe Touch <touch@strayalpha.com> wrote:
>>=20
>> Hi Stuart, et al.,
>>=20
>> I=E2=80=99m confused by the text below; given IPv6 configuration relies o=
n multicast, why is it not reasonable to assume similarly useful multicast h=
ere?
>>=20
>> Joe
>>=20
>>> On Nov 7, 2018, at 11:27 PM, Stuart Cheshire <cheshire@apple.com> wrote:=

>>>=20
>>> Here is a link to the new draft Ted Lemon and I wrote as a result of our=
 work at the Hackathon here at IETF 103.
>>>=20
>>> <https://tools.ietf.org/html/draft-sctl-dnssd-unicast-autoconfig-00>
>>>=20
>>> Here=E2=80=99s a brief summary of what the document is about:
>>>=20
>>> Because multicast can be inefficient and unreliable, work is
>>> taking place to enable DNS-Based Service Discovery to operate
>>> with less reliance on multicast.  One current target use case
>>> for this work is Thread wireless mesh networking.
>>>=20
>>> Existing work describes how DNS-Based Service Discovery can
>>> be performed using unicast on such a network.  Devices on
>>> the Thread mesh offering services use Service Registration
>>> Protocol to register their services at a Service Registration
>>> Server.  Devices seeking to discover these services send
>>> unicast queries to the Service Registration Server using
>>> unicast DNS for single individual queries, and using DNS Push
>>> Notifications where ongoing change notification is required.
>>>=20
>>> For proof-of-concept experiments, the necessary information can
>>> be configured manually, and this has been done successfully.
>>> For deployment, we need to determine how the necessary information
>>> will be learned and configured automatically in real-world scenarios.
>>>=20
>>> Stuart Cheshire
>>>=20
>>> _______________________________________________
>>> dnssd mailing list
>>> dnssd@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnssd
>>=20
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
>=20


From nobody Thu Nov  8 14:08:35 2018
Return-Path: <mellon@fugue.com>
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 69183128C65 for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 14:08:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEUS68QNTvCT for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 14:08:30 -0800 (PST)
Received: from mail-yw1-xc41.google.com (mail-yw1-xc41.google.com [IPv6:2607:f8b0:4864:20::c41]) (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 4B377128A5C for <dnssd@ietf.org>; Thu,  8 Nov 2018 14:08:30 -0800 (PST)
Received: by mail-yw1-xc41.google.com with SMTP id v199-v6so8738493ywg.1 for <dnssd@ietf.org>; Thu, 08 Nov 2018 14:08:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=8x9eqFf696iWIJwdJglb4XTpckXwICBjRACQXYCN4IY=; b=tyyTttr7jFj4q3zAIAiAAcRJuknNs+wstY3X4iN2yg0nbg9eN4vGNVBHjlgKUl5tSu bsc4TkZ2r/0cSqy9kflLvtRB239kUcmE5DiUgI+cGt35HEjOyF8YvmZMpl/5e2DF1V51 4Uuj8I75bk3UCrJhYDidFLu5Uod9nvXCyVnCGojPfTQDqVMUMYUw45ZJTqj/w40NkCvi yU6N0fzx5TWZFM8Nd0S3iqTUkoetDzKCy/bjBvDZ2W2kSrOv+vp3GQTSoNoTvF3ol8Ot EtBaudE86OWa5q0/+x+mrglrv9WAko4pNx68DkrQQqsQXMq+XpK6w43xJWCaWyPowo41 n5vQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=8x9eqFf696iWIJwdJglb4XTpckXwICBjRACQXYCN4IY=; b=fr1+KGIiTkB2mD6mU7xcSGH2C7WRwIXmbm7Q+fOQRYeuZQlgMmKmIn/1gVfD72YQwA Ybn8b12G+/6Z4jgE0U8mnlkj5Sd80ha2XbS2qF9l20INwINcMnOo8CKTTo8X81ggzEXx wLJ9bGVVhE9T0Fb6H4GslBTViyZv19BldjcR7UGZOFBqbtM8IINuiabwJhiE/x5tpTdo oBujUcxG+iU1/tsl1bP6LWe/LrNoWL3I5aeyl/pKtVw8DTde4E0VL5bjb6SNK/SGmH0o yXsaK2CoSnU8b8NHYNmFuooTQgmRBpoVMyvwhVGlaLugb9WU09QuoQq28AKdHEdjf1l+ nJLw==
X-Gm-Message-State: AGRZ1gIhMy8UpQze6VlOdO/VBWb/GMWQEWEe1r5TkYaB0tTRb+RpiNkN LUhaPgTpa2zPNzg68qqZzMnO167O4s8tXkZMm43q9BSSa70=
X-Google-Smtp-Source: AJdET5cHv6lUCmiCw3Ry0Xpg7wWCV3+tLeNNB/kNe01xq6S8HQJMgZE5rNK1CKgk1MNcxq8FeSE3PaOHXXDoTUDT5v4=
X-Received: by 2002:ac8:24d4:: with SMTP id t20mr6339468qtt.43.1541714909376;  Thu, 08 Nov 2018 14:08:29 -0800 (PST)
MIME-Version: 1.0
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com> <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com> <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com>
In-Reply-To: <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 9 Nov 2018 05:07:53 +0700
Message-ID: <CAPt1N1=fgEoWLeYp6zzCJBs49-+zjCkTuXN2EOm2J1f-Asfxpg@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: Tom Pusateri <pusateri@bangj.com>, Stuart Cheshire <cheshire@apple.com>, dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000084c990057a2e7903"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/Nl4PKGH9PlKdKTcBSr-4VEp7vmY>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 22:08:33 -0000

--00000000000084c990057a2e7903
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Joe, are you saying that the characteristics of UDP over multicast are
identical to the characteristics of UDP over unicast on all layer twos?
 Otherwise, I don't think you've made a useful point here.   Our experience
is that packet loss rates are on the order of 70% for multicast in crowded
environments (that is, where there is cross-interference between WiFi
networks, as is typical in a city).

On Fri, Nov 9, 2018 at 4:55 AM Joe Touch <touch@strayalpha.com> wrote:

> UDP isn=E2=80=99t reliable, period. Retransmit.
>
> > On Nov 8, 2018, at 1:10 PM, Tom Pusateri <pusateri@bangj.com> wrote:
> >
> > If multicast packets are dropped during IPv6 configuration, you won=E2=
=80=99t
> get an IPv6 address and you won=E2=80=99t be able to communicate via IPv6=
. This is
> easy to detect. When multicast packets are lost during busy periods on wi=
fi
> and services are not reliably discovered, there=E2=80=99s no easy way to =
detect
> this.
> >
> > On busy wifi networks, multicast just isn=E2=80=99t reliable.
> >
> > See
> https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-03
> >
> > Tom
> >
> >> On Nov 8, 2018, at 10:35 AM, Joe Touch <touch@strayalpha.com> wrote:
> >>
> >> Hi Stuart, et al.,
> >>
> >> I=E2=80=99m confused by the text below; given IPv6 configuration relie=
s on
> multicast, why is it not reasonable to assume similarly useful multicast
> here?
> >>
> >> Joe
> >>
> >>> On Nov 7, 2018, at 11:27 PM, Stuart Cheshire <cheshire@apple.com>
> wrote:
> >>>
> >>> Here is a link to the new draft Ted Lemon and I wrote as a result of
> our work at the Hackathon here at IETF 103.
> >>>
> >>> <https://tools.ietf.org/html/draft-sctl-dnssd-unicast-autoconfig-00>
> >>>
> >>> Here=E2=80=99s a brief summary of what the document is about:
> >>>
> >>> Because multicast can be inefficient and unreliable, work is
> >>> taking place to enable DNS-Based Service Discovery to operate
> >>> with less reliance on multicast.  One current target use case
> >>> for this work is Thread wireless mesh networking.
> >>>
> >>> Existing work describes how DNS-Based Service Discovery can
> >>> be performed using unicast on such a network.  Devices on
> >>> the Thread mesh offering services use Service Registration
> >>> Protocol to register their services at a Service Registration
> >>> Server.  Devices seeking to discover these services send
> >>> unicast queries to the Service Registration Server using
> >>> unicast DNS for single individual queries, and using DNS Push
> >>> Notifications where ongoing change notification is required.
> >>>
> >>> For proof-of-concept experiments, the necessary information can
> >>> be configured manually, and this has been done successfully.
> >>> For deployment, we need to determine how the necessary information
> >>> will be learned and configured automatically in real-world scenarios.
> >>>
> >>> Stuart Cheshire
> >>>
> >>> _______________________________________________
> >>> dnssd mailing list
> >>> dnssd@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/dnssd
> >>
> >> _______________________________________________
> >> dnssd mailing list
> >> dnssd@ietf.org
> >> https://www.ietf.org/mailman/listinfo/dnssd
> >
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>

--00000000000084c990057a2e7903
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Joe, are you saying that the characteristics of UDP over m=
ulticast are identical to the characteristics of UDP over unicast on all la=
yer twos?=C2=A0 =C2=A0Otherwise, I don&#39;t think you&#39;ve made a useful=
 point here.=C2=A0 =C2=A0Our experience is that packet loss rates are on th=
e order of 70% for multicast in crowded environments (that is, where there =
is cross-interference between WiFi networks, as is typical in a city).</div=
><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Nov 9, 2018 at 4:5=
5 AM Joe Touch &lt;<a href=3D"mailto:touch@strayalpha.com">touch@strayalpha=
.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">UDP isn=E2=80=
=99t reliable, period. Retransmit. <br>
<br>
&gt; On Nov 8, 2018, at 1:10 PM, Tom Pusateri &lt;<a href=3D"mailto:pusater=
i@bangj.com" target=3D"_blank">pusateri@bangj.com</a>&gt; wrote:<br>
&gt; <br>
&gt; If multicast packets are dropped during IPv6 configuration, you won=E2=
=80=99t get an IPv6 address and you won=E2=80=99t be able to communicate vi=
a IPv6. This is easy to detect. When multicast packets are lost during busy=
 periods on wifi and services are not reliably discovered, there=E2=80=99s =
no easy way to detect this.<br>
&gt; <br>
&gt; On busy wifi networks, multicast just isn=E2=80=99t reliable.<br>
&gt; <br>
&gt; See <a href=3D"https://tools.ietf.org/html/draft-ietf-mboned-ieee802-m=
cast-problems-03" rel=3D"noreferrer" target=3D"_blank">https://tools.ietf.o=
rg/html/draft-ietf-mboned-ieee802-mcast-problems-03</a><br>
&gt; <br>
&gt; Tom<br>
&gt; <br>
&gt;&gt; On Nov 8, 2018, at 10:35 AM, Joe Touch &lt;<a href=3D"mailto:touch=
@strayalpha.com" target=3D"_blank">touch@strayalpha.com</a>&gt; wrote:<br>
&gt;&gt; <br>
&gt;&gt; Hi Stuart, et al.,<br>
&gt;&gt; <br>
&gt;&gt; I=E2=80=99m confused by the text below; given IPv6 configuration r=
elies on multicast, why is it not reasonable to assume similarly useful mul=
ticast here?<br>
&gt;&gt; <br>
&gt;&gt; Joe<br>
&gt;&gt; <br>
&gt;&gt;&gt; On Nov 7, 2018, at 11:27 PM, Stuart Cheshire &lt;<a href=3D"ma=
ilto:cheshire@apple.com" target=3D"_blank">cheshire@apple.com</a>&gt; wrote=
:<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Here is a link to the new draft Ted Lemon and I wrote as a res=
ult of our work at the Hackathon here at IETF 103.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; &lt;<a href=3D"https://tools.ietf.org/html/draft-sctl-dnssd-un=
icast-autoconfig-00" rel=3D"noreferrer" target=3D"_blank">https://tools.iet=
f.org/html/draft-sctl-dnssd-unicast-autoconfig-00</a>&gt;<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Here=E2=80=99s a brief summary of what the document is about:<=
br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Because multicast can be inefficient and unreliable, work is<b=
r>
&gt;&gt;&gt; taking place to enable DNS-Based Service Discovery to operate<=
br>
&gt;&gt;&gt; with less reliance on multicast.=C2=A0 One current target use =
case<br>
&gt;&gt;&gt; for this work is Thread wireless mesh networking.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Existing work describes how DNS-Based Service Discovery can<br=
>
&gt;&gt;&gt; be performed using unicast on such a network.=C2=A0 Devices on=
<br>
&gt;&gt;&gt; the Thread mesh offering services use Service Registration<br>
&gt;&gt;&gt; Protocol to register their services at a Service Registration<=
br>
&gt;&gt;&gt; Server.=C2=A0 Devices seeking to discover these services send<=
br>
&gt;&gt;&gt; unicast queries to the Service Registration Server using<br>
&gt;&gt;&gt; unicast DNS for single individual queries, and using DNS Push<=
br>
&gt;&gt;&gt; Notifications where ongoing change notification is required.<b=
r>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; For proof-of-concept experiments, the necessary information ca=
n<br>
&gt;&gt;&gt; be configured manually, and this has been done successfully.<b=
r>
&gt;&gt;&gt; For deployment, we need to determine how the necessary informa=
tion<br>
&gt;&gt;&gt; will be learned and configured automatically in real-world sce=
narios.<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; Stuart Cheshire<br>
&gt;&gt;&gt; <br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; dnssd mailing list<br>
&gt;&gt;&gt; <a href=3D"mailto:dnssd@ietf.org" target=3D"_blank">dnssd@ietf=
.org</a><br>
&gt;&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dnssd" rel=3D=
"noreferrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/dnssd<=
/a><br>
&gt;&gt; <br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; dnssd mailing list<br>
&gt;&gt; <a href=3D"mailto:dnssd@ietf.org" target=3D"_blank">dnssd@ietf.org=
</a><br>
&gt;&gt; <a href=3D"https://www.ietf.org/mailman/listinfo/dnssd" rel=3D"nor=
eferrer" target=3D"_blank">https://www.ietf.org/mailman/listinfo/dnssd</a><=
br>
&gt; <br>
<br>
_______________________________________________<br>
dnssd mailing list<br>
<a href=3D"mailto:dnssd@ietf.org" target=3D"_blank">dnssd@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dnssd" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/dnssd</a><br>
</blockquote></div>

--00000000000084c990057a2e7903--


From nobody Thu Nov  8 14:14:48 2018
Return-Path: <pusateri@bangj.com>
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 D8B3C12D4EC for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 14:14:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoo7xVUslvwq for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 14:14:43 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F573128A5C for <dnssd@ietf.org>; Thu,  8 Nov 2018 14:14:43 -0800 (PST)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 9EB6F221B8; Thu,  8 Nov 2018 17:14:42 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com>
Date: Thu, 8 Nov 2018 17:14:40 -0500
Cc: Stuart Cheshire <cheshire@apple.com>, dnssd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3CFB0A4A-7732-4333-97CF-F0E68FD962E7@bangj.com>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com> <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com> <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/cle4bONmS_EQQuU7rCkhMQybeSk>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 22:14:46 -0000

Exactly. Which is why it=E2=80=99s important to only use it in cases =
where either it can be detected or it doesn=E2=80=99t matter if loss =
happens.

There is a mechanism to detect if autoconfiguration doesn=E2=80=99t work =
for IPv6.

I=E2=80=99m not aware of a mechanism to detect if you don=E2=80=99t =
receive a service advertisement with mDNS.

Thanks,
Tom


> On Nov 8, 2018, at 4:54 PM, Joe Touch <touch@strayalpha.com> wrote:
>=20
> UDP isn=E2=80=99t reliable, period. Retransmit.=20
>=20
>> On Nov 8, 2018, at 1:10 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>>=20
>> If multicast packets are dropped during IPv6 configuration, you =
won=E2=80=99t get an IPv6 address and you won=E2=80=99t be able to =
communicate via IPv6. This is easy to detect. When multicast packets are =
lost during busy periods on wifi and services are not reliably =
discovered, there=E2=80=99s no easy way to detect this.
>>=20
>> On busy wifi networks, multicast just isn=E2=80=99t reliable.
>>=20
>> See =
https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-03
>>=20
>> Tom
>>=20
>>> On Nov 8, 2018, at 10:35 AM, Joe Touch <touch@strayalpha.com> wrote:
>>>=20
>>> Hi Stuart, et al.,
>>>=20
>>> I=E2=80=99m confused by the text below; given IPv6 configuration =
relies on multicast, why is it not reasonable to assume similarly useful =
multicast here?
>>>=20
>>> Joe
>>>=20
>>>> On Nov 7, 2018, at 11:27 PM, Stuart Cheshire <cheshire@apple.com> =
wrote:
>>>>=20
>>>> Here is a link to the new draft Ted Lemon and I wrote as a result =
of our work at the Hackathon here at IETF 103.
>>>>=20
>>>> =
<https://tools.ietf.org/html/draft-sctl-dnssd-unicast-autoconfig-00>
>>>>=20
>>>> Here=E2=80=99s a brief summary of what the document is about:
>>>>=20
>>>> Because multicast can be inefficient and unreliable, work is
>>>> taking place to enable DNS-Based Service Discovery to operate
>>>> with less reliance on multicast.  One current target use case
>>>> for this work is Thread wireless mesh networking.
>>>>=20
>>>> Existing work describes how DNS-Based Service Discovery can
>>>> be performed using unicast on such a network.  Devices on
>>>> the Thread mesh offering services use Service Registration
>>>> Protocol to register their services at a Service Registration
>>>> Server.  Devices seeking to discover these services send
>>>> unicast queries to the Service Registration Server using
>>>> unicast DNS for single individual queries, and using DNS Push
>>>> Notifications where ongoing change notification is required.
>>>>=20
>>>> For proof-of-concept experiments, the necessary information can
>>>> be configured manually, and this has been done successfully.
>>>> For deployment, we need to determine how the necessary information
>>>> will be learned and configured automatically in real-world =
scenarios.
>>>>=20
>>>> Stuart Cheshire
>>>>=20
>>>> _______________________________________________
>>>> dnssd mailing list
>>>> dnssd@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>=20
>>> _______________________________________________
>>> dnssd mailing list
>>> dnssd@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dnssd
>>=20
>=20


From nobody Thu Nov  8 14:16:51 2018
Return-Path: <pusateri@bangj.com>
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 70774128A5C for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 14:16:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rKP53OaRzyK1 for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 14:16:47 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 502B21274D0 for <dnssd@ietf.org>; Thu,  8 Nov 2018 14:16:47 -0800 (PST)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 95453221BA; Thu,  8 Nov 2018 17:16:46 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <3CFB0A4A-7732-4333-97CF-F0E68FD962E7@bangj.com>
Date: Thu, 8 Nov 2018 17:16:45 -0500
Cc: Stuart Cheshire <cheshire@apple.com>, dnssd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <058903CD-3120-468F-8211-C9A816DC77F0@bangj.com>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com> <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com> <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com> <3CFB0A4A-7732-4333-97CF-F0E68FD962E7@bangj.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/qMQmiGWpF6mvFnHo7RcRvc0wdfQ>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 22:16:49 -0000

To be clear, when a service first advertises itself, it sends multiple =
copies of the advertisement (usually 2) to try to counter this loss =
potential. But after that, it only sends a single copy in response to a =
query.

Thanks,
Tom


> On Nov 8, 2018, at 5:14 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>=20
> Exactly. Which is why it=E2=80=99s important to only use it in cases =
where either it can be detected or it doesn=E2=80=99t matter if loss =
happens.
>=20
> There is a mechanism to detect if autoconfiguration doesn=E2=80=99t =
work for IPv6.
>=20
> I=E2=80=99m not aware of a mechanism to detect if you don=E2=80=99t =
receive a service advertisement with mDNS.
>=20
> Thanks,
> Tom
>=20
>=20
>> On Nov 8, 2018, at 4:54 PM, Joe Touch <touch@strayalpha.com> wrote:
>>=20
>> UDP isn=E2=80=99t reliable, period. Retransmit.=20
>>=20
>>> On Nov 8, 2018, at 1:10 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>>>=20
>>> If multicast packets are dropped during IPv6 configuration, you =
won=E2=80=99t get an IPv6 address and you won=E2=80=99t be able to =
communicate via IPv6. This is easy to detect. When multicast packets are =
lost during busy periods on wifi and services are not reliably =
discovered, there=E2=80=99s no easy way to detect this.
>>>=20
>>> On busy wifi networks, multicast just isn=E2=80=99t reliable.
>>>=20
>>> See =
https://tools.ietf.org/html/draft-ietf-mboned-ieee802-mcast-problems-03
>>>=20
>>> Tom
>>>=20
>>>> On Nov 8, 2018, at 10:35 AM, Joe Touch <touch@strayalpha.com> =
wrote:
>>>>=20
>>>> Hi Stuart, et al.,
>>>>=20
>>>> I=E2=80=99m confused by the text below; given IPv6 configuration =
relies on multicast, why is it not reasonable to assume similarly useful =
multicast here?
>>>>=20
>>>> Joe
>>>>=20
>>>>> On Nov 7, 2018, at 11:27 PM, Stuart Cheshire <cheshire@apple.com> =
wrote:
>>>>>=20
>>>>> Here is a link to the new draft Ted Lemon and I wrote as a result =
of our work at the Hackathon here at IETF 103.
>>>>>=20
>>>>> =
<https://tools.ietf.org/html/draft-sctl-dnssd-unicast-autoconfig-00>
>>>>>=20
>>>>> Here=E2=80=99s a brief summary of what the document is about:
>>>>>=20
>>>>> Because multicast can be inefficient and unreliable, work is
>>>>> taking place to enable DNS-Based Service Discovery to operate
>>>>> with less reliance on multicast.  One current target use case
>>>>> for this work is Thread wireless mesh networking.
>>>>>=20
>>>>> Existing work describes how DNS-Based Service Discovery can
>>>>> be performed using unicast on such a network.  Devices on
>>>>> the Thread mesh offering services use Service Registration
>>>>> Protocol to register their services at a Service Registration
>>>>> Server.  Devices seeking to discover these services send
>>>>> unicast queries to the Service Registration Server using
>>>>> unicast DNS for single individual queries, and using DNS Push
>>>>> Notifications where ongoing change notification is required.
>>>>>=20
>>>>> For proof-of-concept experiments, the necessary information can
>>>>> be configured manually, and this has been done successfully.
>>>>> For deployment, we need to determine how the necessary information
>>>>> will be learned and configured automatically in real-world =
scenarios.
>>>>>=20
>>>>> Stuart Cheshire
>>>>>=20
>>>>> _______________________________________________
>>>>> dnssd mailing list
>>>>> dnssd@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>>=20
>>>> _______________________________________________
>>>> dnssd mailing list
>>>> dnssd@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dnssd
>>>=20
>>=20
>=20
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd


From nobody Thu Nov  8 15:03:38 2018
Return-Path: <touch@strayalpha.com>
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 EE9C81271FF for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 15:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 6hemkftiXvHC for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 15:03:35 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52887123FFD for <dnssd@ietf.org>; Thu,  8 Nov 2018 15:03:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=vicvXfgQsjfKCfkmO1EOKGPmEqM+HjzfLjEzTavegLo=; b=3wj2r/sMK6S7fZvaNp21byD8O D82igH2+x3b6GWtwHmqEOkhqt3UUABoh4IDLraJ8h9yotLTVrNFoZbd23e5NsCJtqkpXE1r5nQuHD E2mR7fQbFGSwnlgw+FwqH6O+UJcAa/LKtVy4ckutyJvIS7uIqmhN7UcbjvrN+syHlYdSsbXc04jXT y5lWyaW3Fe56W4zrONmRJBZsMxoMltwOS9118nZUg2bXJMZkQqvKDSkUlAcFTjgGcyysT+lZZ6Tsd Zov3LueAiu8NRSNAc1bZMH8iBS5/2X2fEUJrPYkBv275aNcC29ekcjuh7ZygPNbRXceCDEjiLxI5f fNTenJlfg==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:53978 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1gKtKn-0009ek-Tg; Thu, 08 Nov 2018 18:03:34 -0500
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <058903CD-3120-468F-8211-C9A816DC77F0@bangj.com>
Date: Thu, 8 Nov 2018 15:03:33 -0800
Cc: Stuart Cheshire <cheshire@apple.com>, dnssd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <B2082DFF-B4A4-4EC4-B4A7-2FFAF909D121@strayalpha.com>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com> <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com> <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com> <3CFB0A4A-7732-4333-97CF-F0E68FD962E7@bangj.com> <058903CD-3120-468F-8211-C9A816DC77F0@bangj.com>
To: Tom Pusateri <pusateri@bangj.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/PNRaaWyL5VJ_CXExEQ3NN88Avm8>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 23:03:37 -0000

> On Nov 8, 2018, at 2:16 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>=20
> To be clear, when a service first advertises itself, it sends multiple =
copies of the advertisement (usually 2) to try to counter this loss =
potential. But after that, it only sends a single copy in response to a =
query.

That appears to suggest that:

a) 2 is not necessarily enough in the first round
b) 1 is definitely not enough in later rounds

Unless you can explain why multicast is less likely to be successful at =
all (vs reaching ALL its intended recipients, which should not be =
required here), in which case that issue ought to be the focus.

Either way, it seems like a good place to start digging is in the =
current mechanism, at least before searching for a completely new one.

Joe



From nobody Thu Nov  8 15:18:29 2018
Return-Path: <pusateri@bangj.com>
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 697DF130DDE for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 15:18:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fGiBJvlfwcxd for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 15:18:26 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59F8130DCB for <dnssd@ietf.org>; Thu,  8 Nov 2018 15:18:25 -0800 (PST)
Received: from [10.78.1.124] (mobile-166-172-56-32.mycingular.net [166.172.56.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 1B945221C7; Thu,  8 Nov 2018 18:18:25 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Tom Pusateri <pusateri@bangj.com>
X-Mailer: iPhone Mail (16B92)
In-Reply-To: <B2082DFF-B4A4-4EC4-B4A7-2FFAF909D121@strayalpha.com>
Date: Thu, 8 Nov 2018 18:18:24 -0500
Cc: Stuart Cheshire <cheshire@apple.com>, dnssd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <3C58A01F-79A7-4623-838A-EA7B89F8F421@bangj.com>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com> <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com> <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com> <3CFB0A4A-7732-4333-97CF-F0E68FD962E7@bangj.com> <058903CD-3120-468F-8211-C9A816DC77F0@bangj.com> <B2082DFF-B4A4-4EC4-B4A7-2FFAF909D121@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/nPsnPHm-AiZF69bH7myvLG4dgUk>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 23:18:27 -0000

No matter how many times you retransmit, you can=E2=80=99t be sure it is rec=
eived over UDP.=20

We already have a mechanism to ensure it=E2=80=99s delivered over TCP that a=
lso has well implemented encryption (TLS) and so I prefer this route and so d=
o many others.=20

Otherwise, we=E2=80=99re inventing a reliable multicast protocol and still d=
on=E2=80=99t have a good solution for key exchange for encryption.=20

Tom

> On Nov 8, 2018, at 6:03 PM, Joe Touch <touch@strayalpha.com> wrote:
>=20
>=20
>=20
>> On Nov 8, 2018, at 2:16 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>>=20
>> To be clear, when a service first advertises itself, it sends multiple co=
pies of the advertisement (usually 2) to try to counter this loss potential.=
 But after that, it only sends a single copy in response to a query.
>=20
> That appears to suggest that:
>=20
> a) 2 is not necessarily enough in the first round
> b) 1 is definitely not enough in later rounds
>=20
> Unless you can explain why multicast is less likely to be successful at al=
l (vs reaching ALL its intended recipients, which should not be required her=
e), in which case that issue ought to be the focus.
>=20
> Either way, it seems like a good place to start digging is in the current m=
echanism, at least before searching for a completely new one.
>=20
> Joe
>=20
>=20


From nobody Thu Nov  8 15:27:05 2018
Return-Path: <touch@strayalpha.com>
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 5885D130DCB for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 15:27:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 Nx6oJAT4HLwz for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 15:27:02 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955C2127B92 for <dnssd@ietf.org>; Thu,  8 Nov 2018 15:27:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=thrv+nc881uk4WgGTW5PSwI5kMryJz6OsiqURurWM8g=; b=yrkaOEmX7fYGq/Cyot7zkGg67 Y+We0Xl6IYWfQ+y1xzQqdb7V7PAzIgWnS/Jjo7UKem0PP3kj//1zQ6EOi6Ymnccy+OhXAGi81yKba jiS3QTEBfnr0ufegNpwLvYYwnMX4v8q/olzmBJ+k65f4PoqmWTN/nuoArN4Tw31PiF4YB4HEB/0aD BkJRyXkhIkulv2mn3Cx5+1NYD/ySWOBn1LN5HqLU3/0ed2FazX9ra5L6rX9r2YP4qw27AF91Y3KVj iTz6DGZLNBOyZOhkoQlo4LcS8MMqN7wq2Li9kWv0ETcSC5IFD/clPwnTF1y3ldi2I7uZN0xAD1PWa 9gRRhWNlQ==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:54041 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1gKthV-000T0j-OE; Thu, 08 Nov 2018 18:27:02 -0500
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <3C58A01F-79A7-4623-838A-EA7B89F8F421@bangj.com>
Date: Thu, 8 Nov 2018 15:27:00 -0800
Cc: Stuart Cheshire <cheshire@apple.com>, dnssd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <5B2DE184-5D87-425A-BA83-5042A81DBCB7@strayalpha.com>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com> <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com> <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com> <3CFB0A4A-7732-4333-97CF-F0E68FD962E7@bangj.com> <058903CD-3120-468F-8211-C9A816DC77F0@bangj.com> <B2082DFF-B4A4-4EC4-B4A7-2FFAF909D121@strayalpha.com> <3C58A01F-79A7-4623-838A-EA7B89F8F421@bangj.com>
To: Tom Pusateri <pusateri@bangj.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/ppvKgV2PC8w9RNpJTFnRDH5QddQ>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 23:27:04 -0000

> On Nov 8, 2018, at 3:18 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>=20
> No matter how many times you retransmit, you can=E2=80=99t be sure it =
is received over UDP.=20

You can implement positive confirmation at the app layer.

>=20
> We already have a mechanism to ensure it=E2=80=99s delivered over TCP =
that also has well implemented encryption (TLS) and so I prefer this =
route and so do many others.=20

DTLS will work with UDP; the benefit of UDP is that it can use native =
IP-level multicast where TCP cannot.

>=20
> Otherwise, we=E2=80=99re inventing a reliable multicast protocol and =
still don=E2=80=99t have a good solution for key exchange for =
encryption.=20

Agreed. That=E2=80=99s been tried many times before without a good =
solution.

I=E2=80=99m just suggesting that sending a UDP packet once - or even =
twice - isn=E2=80=99t expected to be all that robust.

Joe


From nobody Thu Nov  8 15:34:16 2018
Return-Path: <mellon@fugue.com>
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 D272E130DD5 for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 15:34:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4zs21vyrwZ-I for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 15:34:12 -0800 (PST)
Received: from mail-yw1-xc2b.google.com (mail-yw1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 203F0127B92 for <dnssd@ietf.org>; Thu,  8 Nov 2018 15:34:12 -0800 (PST)
Received: by mail-yw1-xc2b.google.com with SMTP id v5-v6so4587093ywa.13 for <dnssd@ietf.org>; Thu, 08 Nov 2018 15:34:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=et5xpO/oRdfYVfjznW5aRWy9zq7elve+CZ7PL/wlN9U=; b=tQo7lMqDNYDeR1JoGPGSG8mAUi2EhXiBwX+TArdnunEGn3ma/F4MTOdRMA8jn3/FXV vo5dc8UR/YdlgkK5sAisc+Wg7PAZWB0MU8zxRMLmwgmgvz7gJLur+rOISOp4TGDx7tcm OhVGI9nbd/sxLlgMMTmL4gF0Xx8HxL17kv3BIORSGeXyTM7GLpHrFZAM7PsJUOpHHcsp wtYvcpCkSI+xb5tR5ChydtLB2CbHOhc/DNu7//qy/DvPIf+SkMv9cI+jz2DE9CswzMQ2 +dFgJhkNd1cFyEI+U9QD8DQpa/AHVazClGA+sVnn+QCC7qFSsNoUd5zeEosYkS/Tr2m1 4qVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=et5xpO/oRdfYVfjznW5aRWy9zq7elve+CZ7PL/wlN9U=; b=Ih31Sn7cfFvfd8s6SMdQd4fN4MvjjgB33pMM12hu1IXfIIrMzHN1pZ5IP6gk1TVlNn 45lucWpUZCjLgte0J8hD99Wiwu58TV7O1SIck0fIJyJ6bUHX8yJnyCXtRlP+4VRvcVSJ INDAfpucau2Z8Qdfq4Sa4jaza1fMEDPcXMaALvgINRVGzY21XlPvefai8EUXW6YKd37M lWYeiE0K2A6cxherD/A0f/a9OidSTh1T1xLqlcM3S3wL3cGCD7ivDWJBeIOC65k7E37r 2q+wnaJwmTnJSIY8sAPrK+jovGQVeg7bzc5Q4aazsaIdMEEEs+lmg6gEDHcI7/Zh2631 dGMg==
X-Gm-Message-State: AGRZ1gJoDpIOxEqJKKYvwf3HEQwDdtbgtRphQBg6t6i5hqS1yD5I6p+F 1EM2MR11y5d5rapCsL/sdfIzoUR67MXMz/ze3uX5/A==
X-Google-Smtp-Source: AJdET5cR6gzNEK6zzCd88Lq7vqe9wtoQLb/zYM6RyN0CF7gg7oaIjXz1mNjr571rk0hJjSMTOEhsXCuv0bm3ZUTP/UU=
X-Received: by 2002:ac8:7518:: with SMTP id u24mr6759330qtq.75.1541720051237;  Thu, 08 Nov 2018 15:34:11 -0800 (PST)
MIME-Version: 1.0
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com> <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com> <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com> <3CFB0A4A-7732-4333-97CF-F0E68FD962E7@bangj.com> <058903CD-3120-468F-8211-C9A816DC77F0@bangj.com> <B2082DFF-B4A4-4EC4-B4A7-2FFAF909D121@strayalpha.com> <3C58A01F-79A7-4623-838A-EA7B89F8F421@bangj.com> <5B2DE184-5D87-425A-BA83-5042A81DBCB7@strayalpha.com>
In-Reply-To: <5B2DE184-5D87-425A-BA83-5042A81DBCB7@strayalpha.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 9 Nov 2018 06:34:00 +0700
Message-ID: <CAPt1N1=Y_60RR+hEU9qEiVXV-zhWOX4a8VThFWwxahBMooGtNg@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: Stuart Cheshire <cheshire@apple.com>, Tom Pusateri <pusateri@bangj.com>, dnssd@ietf.org
Content-Type: multipart/alternative; boundary="000000000000ff5ec0057a2fab8c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/KzmuZZZ-ETHHtn7U6dlP628Cj84>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 23:34:15 -0000

--000000000000ff5ec0057a2fab8c
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This is true but irrelevant. Multicast isn=E2=80=99t a great solution anywa=
y. Wakes
everyone up, not just who you are trying to reach.

On Fri, Nov 9, 2018 at 6:27 AM Joe Touch <touch@strayalpha.com> wrote:

>
>
> > On Nov 8, 2018, at 3:18 PM, Tom Pusateri <pusateri@bangj.com> wrote:
> >
> > No matter how many times you retransmit, you can=E2=80=99t be sure it i=
s
> received over UDP.
>
> You can implement positive confirmation at the app layer.
>
> >
> > We already have a mechanism to ensure it=E2=80=99s delivered over TCP t=
hat also
> has well implemented encryption (TLS) and so I prefer this route and so d=
o
> many others.
>
> DTLS will work with UDP; the benefit of UDP is that it can use native
> IP-level multicast where TCP cannot.
>
> >
> > Otherwise, we=E2=80=99re inventing a reliable multicast protocol and st=
ill don=E2=80=99t
> have a good solution for key exchange for encryption.
>
> Agreed. That=E2=80=99s been tried many times before without a good soluti=
on.
>
> I=E2=80=99m just suggesting that sending a UDP packet once - or even twic=
e - isn=E2=80=99t
> expected to be all that robust.
>
> Joe
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>

--000000000000ff5ec0057a2fab8c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">This is true but irrelevant. Multicast isn=E2=80=99t=
 a great solution anyway. Wakes everyone up, not just who you are trying to=
 reach.=C2=A0</div></div><div><br><div class=3D"gmail_quote"><div dir=3D"lt=
r">On Fri, Nov 9, 2018 at 6:27 AM Joe Touch &lt;<a href=3D"mailto:touch@str=
ayalpha.com">touch@strayalpha.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><br>
<br>
&gt; On Nov 8, 2018, at 3:18 PM, Tom Pusateri &lt;<a href=3D"mailto:pusater=
i@bangj.com" target=3D"_blank">pusateri@bangj.com</a>&gt; wrote:<br>
&gt; <br>
&gt; No matter how many times you retransmit, you can=E2=80=99t be sure it =
is received over UDP. <br>
<br>
You can implement positive confirmation at the app layer.<br>
<br>
&gt; <br>
&gt; We already have a mechanism to ensure it=E2=80=99s delivered over TCP =
that also has well implemented encryption (TLS) and so I prefer this route =
and so do many others. <br>
<br>
DTLS will work with UDP; the benefit of UDP is that it can use native IP-le=
vel multicast where TCP cannot.<br>
<br>
&gt; <br>
&gt; Otherwise, we=E2=80=99re inventing a reliable multicast protocol and s=
till don=E2=80=99t have a good solution for key exchange for encryption. <b=
r>
<br>
Agreed. That=E2=80=99s been tried many times before without a good solution=
.<br>
<br>
I=E2=80=99m just suggesting that sending a UDP packet once - or even twice =
- isn=E2=80=99t expected to be all that robust.<br>
<br>
Joe<br>
<br>
_______________________________________________<br>
dnssd mailing list<br>
<a href=3D"mailto:dnssd@ietf.org" target=3D"_blank">dnssd@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dnssd" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/dnssd</a><br>
</blockquote></div></div>

--000000000000ff5ec0057a2fab8c--


From nobody Thu Nov  8 15:59:11 2018
Return-Path: <pusateri@bangj.com>
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 7E4B6130DF1 for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 15:59:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlkNwVc8uK9n for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 15:59:09 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C0E1130DDE for <dnssd@ietf.org>; Thu,  8 Nov 2018 15:59:09 -0800 (PST)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 3192A221D6; Thu,  8 Nov 2018 18:59:08 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Tom Pusateri <pusateri@bangj.com>
In-Reply-To: <5B2DE184-5D87-425A-BA83-5042A81DBCB7@strayalpha.com>
Date: Thu, 8 Nov 2018 18:59:07 -0500
Cc: Stuart Cheshire <cheshire@apple.com>, dnssd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <41C52A1E-53BC-46AC-B886-33B52A059844@bangj.com>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com> <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com> <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com> <3CFB0A4A-7732-4333-97CF-F0E68FD962E7@bangj.com> <058903CD-3120-468F-8211-C9A816DC77F0@bangj.com> <B2082DFF-B4A4-4EC4-B4A7-2FFAF909D121@strayalpha.com> <3C58A01F-79A7-4623-838A-EA7B89F8F421@bangj.com> <5B2DE184-5D87-425A-BA83-5042A81DBCB7@strayalpha.com>
To: Joe Touch <touch@strayalpha.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/u224mqGRc08CAsXJdLxwFFlSn24>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Nov 2018 23:59:11 -0000

> On Nov 8, 2018, at 6:27 PM, Joe Touch <touch@strayalpha.com> wrote:
>=20
>=20
>=20
>> On Nov 8, 2018, at 3:18 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>>=20
>> No matter how many times you retransmit, you can=E2=80=99t be sure it =
is received over UDP.=20
>=20
> You can implement positive confirmation at the app layer.

We don=E2=80=99t want to invent a reliable multicast layer. There are a =
lot of corner cases and an IRTF group has been working on it for years.

>=20
>>=20
>> We already have a mechanism to ensure it=E2=80=99s delivered over TCP =
that also has well implemented encryption (TLS) and so I prefer this =
route and so do many others.=20
>=20
> DTLS will work with UDP; the benefit of UDP is that it can use native =
IP-level multicast where TCP cannot.


DTLS doesn=E2=80=99t work with multicast and it=E2=80=99s not widely =
implemented.

>=20
>>=20
>> Otherwise, we=E2=80=99re inventing a reliable multicast protocol and =
still don=E2=80=99t have a good solution for key exchange for =
encryption.=20
>=20
> Agreed. That=E2=80=99s been tried many times before without a good =
solution.
>=20
> I=E2=80=99m just suggesting that sending a UDP packet once - or even =
twice - isn=E2=80=99t expected to be all that robust.

Can you tell us your best reason NOT to use TCP/TLS?

Tom



From nobody Thu Nov  8 16:49:38 2018
Return-Path: <touch@strayalpha.com>
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 48AB5130DDC for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 16:49:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level: 
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 5E2TSWEn7VRb for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 16:49:34 -0800 (PST)
Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8540112F1A2 for <dnssd@ietf.org>; Thu,  8 Nov 2018 16:49:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id:Cc:Date:In-Reply-To: From:Subject:Mime-Version:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=YqutDbzfN+CfbbO7WKUxkfRvY6fgDrzMdMNzB22ccpk=; b=ZT2kyX6Td/JDBTyATO49w6XVF e9A8LaLokFdjHZmIWuQmhPARgYvJwr/d4iRtBlXNtFE6MJy+S0K/88jDkg5B/s9Jo9QuaslCotmPs gqYX5k9ePt59oncrzTxAxZH6h+jalSShQPIS3i4EZ76N29FNGfEP4CHY1An6UyETizdB93OlV3SIT HlDcHRycKpJFSIIatIDVpekjkeCf733aWuujuMgFMKp3cH5yaHlHlcRsR0pq5IgM70xhEqWGaA2uT L/VtJCYz6IssVESuz+PibGa4VkNR7iMP+si2F5v8cTngnceSBwfj8V0eOIC8YCEnTwEBsdIX55UsE /vytkZewg==;
Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:54115 helo=[192.168.1.77]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.91) (envelope-from <touch@strayalpha.com>) id 1gKuzK-001TzK-77; Thu, 08 Nov 2018 19:49:33 -0500
Content-Type: multipart/alternative; boundary="Apple-Mail=_E43E2A93-5B96-40E8-A157-76F65AE37069"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Joe Touch <touch@strayalpha.com>
In-Reply-To: <CAPt1N1=Y_60RR+hEU9qEiVXV-zhWOX4a8VThFWwxahBMooGtNg@mail.gmail.com>
Date: Thu, 8 Nov 2018 16:49:27 -0800
Cc: Stuart Cheshire <cheshire@apple.com>, Tom Pusateri <pusateri@bangj.com>, dnssd@ietf.org
Message-Id: <A81B945B-3ECC-40BE-84F0-EBEC95834BE1@strayalpha.com>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com> <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com> <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com> <3CFB0A4A-7732-4333-97CF-F0E68FD962E7@bangj.com> <058903CD-3120-468F-8211-C9A816DC77F0@bangj.com> <B2082DFF-B4A4-4EC4-B4A7-2FFAF909D121@strayalpha.com> <3C58A01F-79A7-4623-838A-EA7B89F8F421@bangj.com> <5B2DE184-5D87-425A-BA83-5042A81DBCB7@strayalpha.com> <CAPt1N1=Y_60RR+hEU9qEiVXV-zhWOX4a8VThFWwxahBMooGtNg@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: Apple Mail (2.3445.9.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/Z9_JO0PBIUTBrKEX9qfRqUtez1s>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2018 00:49:37 -0000

--Apple-Mail=_E43E2A93-5B96-40E8-A157-76F65AE37069
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

OK, maybe I=E2=80=99m confused =E2=80=94 the doc appears to imply:

	- multicast doesn=E2=80=99t work for discovery
	- so here=E2=80=99s a unicast mesh instead

That seems broken to me. Multicast ought to be more than sufficient - =
even when unreliable - for discovery.

*once discovered*, sure, use TCP/TLS to exchange config info. But I =
didn=E2=80=99t get the impression that post-discovery config was the =
focus of the draft.

Joe

> On Nov 8, 2018, at 3:34 PM, Ted Lemon <mellon@fugue.com> wrote:
>=20
> This is true but irrelevant. Multicast isn=E2=80=99t a great solution =
anyway. Wakes everyone up, not just who you are trying to reach.=20
>=20
> On Fri, Nov 9, 2018 at 6:27 AM Joe Touch <touch@strayalpha.com =
<mailto:touch@strayalpha.com>> wrote:
>=20
>=20
> > On Nov 8, 2018, at 3:18 PM, Tom Pusateri <pusateri@bangj.com =
<mailto:pusateri@bangj.com>> wrote:
> >=20
> > No matter how many times you retransmit, you can=E2=80=99t be sure =
it is received over UDP.=20
>=20
> You can implement positive confirmation at the app layer.
>=20
> >=20
> > We already have a mechanism to ensure it=E2=80=99s delivered over =
TCP that also has well implemented encryption (TLS) and so I prefer this =
route and so do many others.=20
>=20
> DTLS will work with UDP; the benefit of UDP is that it can use native =
IP-level multicast where TCP cannot.
>=20
> >=20
> > Otherwise, we=E2=80=99re inventing a reliable multicast protocol and =
still don=E2=80=99t have a good solution for key exchange for =
encryption.=20
>=20
> Agreed. That=E2=80=99s been tried many times before without a good =
solution.
>=20
> I=E2=80=99m just suggesting that sending a UDP packet once - or even =
twice - isn=E2=80=99t expected to be all that robust.
>=20
> Joe
>=20
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org <mailto:dnssd@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnssd =
<https://www.ietf.org/mailman/listinfo/dnssd>


--Apple-Mail=_E43E2A93-5B96-40E8-A157-76F65AE37069
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">OK, =
maybe I=E2=80=99m confused =E2=80=94 the doc appears to imply:<div =
class=3D""><br class=3D""></div><div class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>- =
multicast doesn=E2=80=99t work for discovery</div><div class=3D""><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>- so =
here=E2=80=99s a unicast mesh instead</div><div class=3D""><br =
class=3D""></div><div class=3D"">That seems broken to me. Multicast =
ought to be more than sufficient - even when unreliable - for =
discovery.</div><div class=3D""><br class=3D""></div><div class=3D"">*once=
 discovered*, sure, use TCP/TLS to exchange config info. But I didn=E2=80=99=
t get the impression that post-discovery config was the focus of the =
draft.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Joe</div><div class=3D""><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Nov 8, 2018, at 3:34 PM, Ted =
Lemon &lt;<a href=3D"mailto:mellon@fugue.com" =
class=3D"">mellon@fugue.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D""><div =
dir=3D"auto" class=3D"">This is true but irrelevant. Multicast isn=E2=80=99=
t a great solution anyway. Wakes everyone up, not just who you are =
trying to reach.&nbsp;</div></div><div class=3D""><br class=3D""><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"">On Fri, Nov 9, 2018 at =
6:27 AM Joe Touch &lt;<a href=3D"mailto:touch@strayalpha.com" =
class=3D"">touch@strayalpha.com</a>&gt; wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><br class=3D"">
<br class=3D"">
&gt; On Nov 8, 2018, at 3:18 PM, Tom Pusateri &lt;<a =
href=3D"mailto:pusateri@bangj.com" target=3D"_blank" =
class=3D"">pusateri@bangj.com</a>&gt; wrote:<br class=3D"">
&gt; <br class=3D"">
&gt; No matter how many times you retransmit, you can=E2=80=99t be sure =
it is received over UDP. <br class=3D"">
<br class=3D"">
You can implement positive confirmation at the app layer.<br class=3D"">
<br class=3D"">
&gt; <br class=3D"">
&gt; We already have a mechanism to ensure it=E2=80=99s delivered over =
TCP that also has well implemented encryption (TLS) and so I prefer this =
route and so do many others. <br class=3D"">
<br class=3D"">
DTLS will work with UDP; the benefit of UDP is that it can use native =
IP-level multicast where TCP cannot.<br class=3D"">
<br class=3D"">
&gt; <br class=3D"">
&gt; Otherwise, we=E2=80=99re inventing a reliable multicast protocol =
and still don=E2=80=99t have a good solution for key exchange for =
encryption. <br class=3D"">
<br class=3D"">
Agreed. That=E2=80=99s been tried many times before without a good =
solution.<br class=3D"">
<br class=3D"">
I=E2=80=99m just suggesting that sending a UDP packet once - or even =
twice - isn=E2=80=99t expected to be all that robust.<br class=3D"">
<br class=3D"">
Joe<br class=3D"">
<br class=3D"">
_______________________________________________<br class=3D"">
dnssd mailing list<br class=3D"">
<a href=3D"mailto:dnssd@ietf.org" target=3D"_blank" =
class=3D"">dnssd@ietf.org</a><br class=3D"">
<a href=3D"https://www.ietf.org/mailman/listinfo/dnssd" rel=3D"noreferrer"=
 target=3D"_blank" =
class=3D"">https://www.ietf.org/mailman/listinfo/dnssd</a><br class=3D"">
</blockquote></div></div>
</div></blockquote></div><br class=3D""></div></body></html>=

--Apple-Mail=_E43E2A93-5B96-40E8-A157-76F65AE37069--


From nobody Thu Nov  8 16:55:44 2018
Return-Path: <mellon@fugue.com>
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 43CE2130DD0 for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 16:55:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nJmnjkICEzDx for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 16:55:39 -0800 (PST)
Received: from mail-yw1-xc2f.google.com (mail-yw1-xc2f.google.com [IPv6:2607:f8b0:4864:20::c2f]) (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 2BB0D130DC1 for <dnssd@ietf.org>; Thu,  8 Nov 2018 16:55:39 -0800 (PST)
Received: by mail-yw1-xc2f.google.com with SMTP id l2-v6so276454ywb.9 for <dnssd@ietf.org>; Thu, 08 Nov 2018 16:55:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JqYO5UzAfF4ret5FGOBGIDM60xvpsyCQWPB+xeECq7I=; b=JWooummWqbyi8hbpafLu6V58II6o13ACO784F7tKuVdngUgPRBwP9raNawI6GawJnZ MdnIwvfzHO0wRWgYf0a3WAuujDOaDOm6P/Z5Ro5s5zKF4npFnyVj8Vvgn3XclZmBLRZ7 zKkzNZr1edk5TyTBF85NTk/Ti720w+c63vFnh7uXcJOe3EuCXhTXV6T0XyTPS8+3W1hK 8vR6ELWQxpiGBtECv0QU0RB7p4yYgQbtN+RuVRmGqBwFF4Bj8RactbpzFKsQJ0LjhARH D6jgulUeE4CoccyqKatvSX3wk0G6QGEmsv1nZFiD94NJCs2sSvzxtThCo1iJoEj+jRqy jccA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JqYO5UzAfF4ret5FGOBGIDM60xvpsyCQWPB+xeECq7I=; b=mg2O9Fl5DUfKioQzqMKLkIAlDHCkkxeeovN3dgbnRAnynBsQijW+Z4myWxhKOBzwc5 3iIXoOIPLrB1pAxcJnqs/j7DEHgMc+14EBPMIOhFEWD392wqro8NBza9s4IhyfbuEj7A 254C7IzMApO975aGnCqazf5yT5FLcZpffeNk8TFw0C/j9XOCQC7u10A+msjAYdsDziaM vpDU6ET4H2stiYJx3F6sbBdH2CLFgIAUfZW1CCQHtg6u8doWlEWd4JwrSQGBulQGkIGo 1Y3aOp+XJm9qsV1FfG5XryYZ4PZ5EHPgUdi+sSR4j0IQxXvMtKrlAXC27MM4ikXdSoT1 X6Xw==
X-Gm-Message-State: AGRZ1gJ5mT+r4znZfqkcaN21ud01lEjT1/K1tNZH6R4aAf488IrUxYIM Esz9k97Byu6pRQkAkoW9cqUAqJoGAyz5TT6c53+BwQ==
X-Google-Smtp-Source: AJdET5fd3s/6xiWM/PbMJoD4C/Jhv3eLX/5WL/jcnE1KZe008YigOBOfzD7dQ78oaHTMo+sEtDxZDWBVd02NuRubshE=
X-Received: by 2002:ac8:18fa:: with SMTP id o55mr7038769qtk.256.1541724938302;  Thu, 08 Nov 2018 16:55:38 -0800 (PST)
MIME-Version: 1.0
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com> <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com> <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com> <3CFB0A4A-7732-4333-97CF-F0E68FD962E7@bangj.com> <058903CD-3120-468F-8211-C9A816DC77F0@bangj.com> <B2082DFF-B4A4-4EC4-B4A7-2FFAF909D121@strayalpha.com> <3C58A01F-79A7-4623-838A-EA7B89F8F421@bangj.com> <5B2DE184-5D87-425A-BA83-5042A81DBCB7@strayalpha.com> <CAPt1N1=Y_60RR+hEU9qEiVXV-zhWOX4a8VThFWwxahBMooGtNg@mail.gmail.com> <A81B945B-3ECC-40BE-84F0-EBEC95834BE1@strayalpha.com>
In-Reply-To: <A81B945B-3ECC-40BE-84F0-EBEC95834BE1@strayalpha.com>
From: Ted Lemon <mellon@fugue.com>
Date: Fri, 9 Nov 2018 07:55:27 +0700
Message-ID: <CAPt1N1kYXXfn6qy7PVBPqNXFbp_G2v2JPi90JNoyQfmtMA2X3A@mail.gmail.com>
To: Joe Touch <touch@strayalpha.com>
Cc: Stuart Cheshire <cheshire@apple.com>, Tom Pusateri <pusateri@bangj.com>, dnssd@ietf.org
Content-Type: multipart/alternative; boundary="0000000000004a20f3057a30cf3d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/OY4xLbV4MEVd900rIERqxnM6-GU>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2018 00:55:42 -0000

--0000000000004a20f3057a30cf3d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Joe, multicast is much more lossy than unicast on most networks, has high
latency because of waiting for beacon intervals, and reduces overall
bandwidth. Are you saying that this is not a problem, or were you just
unaware of the issue?

On Fri, Nov 9, 2018 at 7:49 AM Joe Touch <touch@strayalpha.com> wrote:

> OK, maybe I=E2=80=99m confused =E2=80=94 the doc appears to imply:
>
> - multicast doesn=E2=80=99t work for discovery
> - so here=E2=80=99s a unicast mesh instead
>
> That seems broken to me. Multicast ought to be more than sufficient - eve=
n
> when unreliable - for discovery.
>
> *once discovered*, sure, use TCP/TLS to exchange config info. But I didn=
=E2=80=99t
> get the impression that post-discovery config was the focus of the draft.
>
> Joe
>
> On Nov 8, 2018, at 3:34 PM, Ted Lemon <mellon@fugue.com> wrote:
>
> This is true but irrelevant. Multicast isn=E2=80=99t a great solution any=
way.
> Wakes everyone up, not just who you are trying to reach.
>
> On Fri, Nov 9, 2018 at 6:27 AM Joe Touch <touch@strayalpha.com> wrote:
>
>>
>>
>> > On Nov 8, 2018, at 3:18 PM, Tom Pusateri <pusateri@bangj.com> wrote:
>> >
>> > No matter how many times you retransmit, you can=E2=80=99t be sure it =
is
>> received over UDP.
>>
>> You can implement positive confirmation at the app layer.
>>
>> >
>> > We already have a mechanism to ensure it=E2=80=99s delivered over TCP =
that also
>> has well implemented encryption (TLS) and so I prefer this route and so =
do
>> many others.
>>
>> DTLS will work with UDP; the benefit of UDP is that it can use native
>> IP-level multicast where TCP cannot.
>>
>> >
>> > Otherwise, we=E2=80=99re inventing a reliable multicast protocol and s=
till
>> don=E2=80=99t have a good solution for key exchange for encryption.
>>
>> Agreed. That=E2=80=99s been tried many times before without a good solut=
ion.
>>
>> I=E2=80=99m just suggesting that sending a UDP packet once - or even twi=
ce -
>> isn=E2=80=99t expected to be all that robust.
>>
>> Joe
>>
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
>
>

--0000000000004a20f3057a30cf3d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div><div dir=3D"auto">Joe, multicast is much more lossy than unicast on mo=
st networks, has high latency because of waiting for beacon intervals, and =
reduces overall bandwidth. Are you saying that this is not a problem, or we=
re you just unaware of the issue?</div></div><div><br><div class=3D"gmail_q=
uote"><div dir=3D"ltr">On Fri, Nov 9, 2018 at 7:49 AM Joe Touch &lt;<a href=
=3D"mailto:touch@strayalpha.com">touch@strayalpha.com</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div style=3D"word-wrap:break-word;line-b=
reak:after-white-space">OK, maybe I=E2=80=99m confused =E2=80=94 the doc ap=
pears to imply:<div><br></div><div><span class=3D"m_-3557225394570297107App=
le-tab-span" style=3D"white-space:pre-wrap">	</span>- multicast doesn=E2=80=
=99t work for discovery</div><div><span class=3D"m_-3557225394570297107Appl=
e-tab-span" style=3D"white-space:pre-wrap">	</span>- so here=E2=80=99s a un=
icast mesh instead</div><div><br></div><div>That seems broken to me. Multic=
ast ought to be more than sufficient - even when unreliable - for discovery=
.</div><div><br></div><div>*once discovered*, sure, use TCP/TLS to exchange=
 config info. But I didn=E2=80=99t get the impression that post-discovery c=
onfig was the focus of the draft.</div></div><div style=3D"word-wrap:break-=
word;line-break:after-white-space"><div><br></div><div>Joe</div><div><div><=
br><blockquote type=3D"cite"><div>On Nov 8, 2018, at 3:34 PM, Ted Lemon &lt=
;<a href=3D"mailto:mellon@fugue.com" target=3D"_blank">mellon@fugue.com</a>=
&gt; wrote:</div><br class=3D"m_-3557225394570297107Apple-interchange-newli=
ne"><div><div><div dir=3D"auto">This is true but irrelevant. Multicast isn=
=E2=80=99t a great solution anyway. Wakes everyone up, not just who you are=
 trying to reach.=C2=A0</div></div><div><br><div class=3D"gmail_quote"><div=
 dir=3D"ltr">On Fri, Nov 9, 2018 at 6:27 AM Joe Touch &lt;<a href=3D"mailto=
:touch@strayalpha.com" target=3D"_blank">touch@strayalpha.com</a>&gt; wrote=
:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bor=
der-left:1px #ccc solid;padding-left:1ex"><br>
<br>
&gt; On Nov 8, 2018, at 3:18 PM, Tom Pusateri &lt;<a href=3D"mailto:pusater=
i@bangj.com" target=3D"_blank">pusateri@bangj.com</a>&gt; wrote:<br>
&gt; <br>
&gt; No matter how many times you retransmit, you can=E2=80=99t be sure it =
is received over UDP. <br>
<br>
You can implement positive confirmation at the app layer.<br>
<br>
&gt; <br>
&gt; We already have a mechanism to ensure it=E2=80=99s delivered over TCP =
that also has well implemented encryption (TLS) and so I prefer this route =
and so do many others. <br>
<br>
DTLS will work with UDP; the benefit of UDP is that it can use native IP-le=
vel multicast where TCP cannot.<br>
<br>
&gt; <br>
&gt; Otherwise, we=E2=80=99re inventing a reliable multicast protocol and s=
till don=E2=80=99t have a good solution for key exchange for encryption. <b=
r>
<br>
Agreed. That=E2=80=99s been tried many times before without a good solution=
.<br>
<br>
I=E2=80=99m just suggesting that sending a UDP packet once - or even twice =
- isn=E2=80=99t expected to be all that robust.<br>
<br>
Joe<br>
<br>
_______________________________________________<br>
dnssd mailing list<br>
<a href=3D"mailto:dnssd@ietf.org" target=3D"_blank">dnssd@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dnssd" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/dnssd</a><br>
</blockquote></div></div>
</div></blockquote></div><br></div></div></blockquote></div></div>

--0000000000004a20f3057a30cf3d--


From nobody Thu Nov  8 19:25:01 2018
Return-Path: <jandrewartha@ccgs.wa.edu.au>
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 664B31292F1 for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 19:25:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level: 
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ccgs.wa.edu.au
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A_KL-RCwiK1P for <dnssd@ietfa.amsl.com>; Thu,  8 Nov 2018 19:24:58 -0800 (PST)
Received: from mail.ccgs.wa.edu.au (io.ccgs.wa.edu.au [203.135.184.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 051741277BB for <dnssd@ietf.org>; Thu,  8 Nov 2018 19:24:57 -0800 (PST)
Received: by mail.ccgs.wa.edu.au (Postfix, from userid 108) id 013981180A7; Fri,  9 Nov 2018 11:24:53 +0800 (AWST)
X-CCGS-ID: 20181109032451-732
X-CCGS-ARGS: jandrewartha@ccgs.wa.edu.au dnssd@ietf.org
Received: from maia.ad.ccgs.wa.edu.au (maia.ad.ccgs.wa.edu.au [10.20.10.33]) by mail.ccgs.wa.edu.au (Postfix) with ESMTPS id 417301180A5 for <dnssd@ietf.org>; Fri,  9 Nov 2018 11:24:51 +0800 (AWST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ccgs.wa.edu.au; s=mail; t=1541733891; bh=6acsoRkzNQuzhuiHnT6xInJ71rfx3CWUaQCCfzeBeBo=; h=Subject:To:References:From:Date:In-Reply-To:From; b=MGX+yIuUZst/eEa/MfSrrW3yrJxXMKCcRiQETE9jKOOMB4atzeoBr9efZr0jbwnM8 yzVna6gaOGO1ifUZbpxyf6tCun79euWig19ZZZXontzKGiwZ7LK2i/9wkdMihaD+2Q VqS6DzoaiT5r1upB4GqGkm9OrnwL7yj/sOlCqI1I=
Received: from [10.10.20.21] (10.10.20.21) by maia.ad.ccgs.wa.edu.au (10.20.10.33) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 9 Nov 2018 11:24:50 +0800
To: <dnssd@ietf.org>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com>
From: James Andrewartha <jandrewartha@ccgs.wa.edu.au>
Organization: Christ Church Grammar School
Message-ID: <493b6594-0a57-5394-3ca9-bd4132fed2f2@ccgs.wa.edu.au>
Date: Fri, 9 Nov 2018 11:24:50 +0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-AU
Content-Transfer-Encoding: 8bit
X-Originating-IP: [10.10.20.21]
X-ClientProxiedBy: maia.ad.ccgs.wa.edu.au (10.20.10.33) To maia.ad.ccgs.wa.edu.au (10.20.10.33)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/w_ladIhlW4qOF88h2tPgdQI1KRE>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2018 03:25:00 -0000

For Apple devices in particular, the wireless chipset will go to sleep
before receiving all broadcast/multicast packets. True since OS X 10.10,
I have the packet traces to prove it. The only solution is proxy ARP,
and that doesn't help with multicast.

-- 
James Andrewartha
Network & Projects Engineer
Christ Church Grammar School
Claremont, Western Australia
Ph. (08) 9442 1757
Mob. 0424 160 877

On 08/11/18 23:35, Joe Touch wrote:
> Hi Stuart, et al.,
> 
> I’m confused by the text below; given IPv6 configuration relies on multicast, why is it not reasonable to assume similarly useful multicast here?
> 
> Joe
> 
>> On Nov 7, 2018, at 11:27 PM, Stuart Cheshire <cheshire@apple.com> wrote:
>>
>> Here is a link to the new draft Ted Lemon and I wrote as a result of our work at the Hackathon here at IETF 103.
>>
>> <https://tools.ietf.org/html/draft-sctl-dnssd-unicast-autoconfig-00>
>>
>> Here’s a brief summary of what the document is about:
>>
>>   Because multicast can be inefficient and unreliable, work is
>>   taking place to enable DNS-Based Service Discovery to operate
>>   with less reliance on multicast.  One current target use case
>>   for this work is Thread wireless mesh networking.
>>
>>   Existing work describes how DNS-Based Service Discovery can
>>   be performed using unicast on such a network.  Devices on
>>   the Thread mesh offering services use Service Registration
>>   Protocol to register their services at a Service Registration
>>   Server.  Devices seeking to discover these services send
>>   unicast queries to the Service Registration Server using
>>   unicast DNS for single individual queries, and using DNS Push
>>   Notifications where ongoing change notification is required.
>>
>>   For proof-of-concept experiments, the necessary information can
>>   be configured manually, and this has been done successfully.
>>   For deployment, we need to determine how the necessary information
>>   will be learned and configured automatically in real-world scenarios.
>>
>> Stuart Cheshire
>>
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
> 


From nobody Fri Nov  9 09:09:20 2018
Return-Path: <pusateri@bangj.com>
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 7DF8D128766 for <dnssd@ietfa.amsl.com>; Fri,  9 Nov 2018 09:09:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7eQktYl8mve for <dnssd@ietfa.amsl.com>; Fri,  9 Nov 2018 09:09:16 -0800 (PST)
Received: from oj.bangj.com (69-77-154-174.static.skybest.com [69.77.154.174]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19C6A12EB11 for <dnssd@ietf.org>; Fri,  9 Nov 2018 09:09:16 -0800 (PST)
Received: from [172.16.10.126] (unknown [107.13.224.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by oj.bangj.com (Postfix) with ESMTPSA id 10EA4222C9; Fri,  9 Nov 2018 12:09:15 -0500 (EST)
From: Tom Pusateri <pusateri@bangj.com>
Message-Id: <F3018925-6D8C-4BF8-A377-60A103365E1C@bangj.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_463B82B5-B8E0-4E5C-9476-1B5A291EC458"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Date: Fri, 9 Nov 2018 12:09:14 -0500
In-Reply-To: <A81B945B-3ECC-40BE-84F0-EBEC95834BE1@strayalpha.com>
Cc: Ted Lemon <mellon@fugue.com>, Stuart Cheshire <cheshire@apple.com>, dnssd@ietf.org
To: Joe Touch <touch@strayalpha.com>
References: <9AB27D25-4B77-4203-B179-59E13458BE61@apple.com> <16290C01-B017-4075-9D55-DE107F8B3D7B@strayalpha.com> <CF8290C5-B84B-4948-9618-F2243BDB3290@bangj.com> <0F95354B-CAB9-42B5-8978-D0AAB898AEA0@strayalpha.com> <3CFB0A4A-7732-4333-97CF-F0E68FD962E7@bangj.com> <058903CD-3120-468F-8211-C9A816DC77F0@bangj.com> <B2082DFF-B4A4-4EC4-B4A7-2FFAF909D121@strayalpha.com> <3C58A01F-79A7-4623-838A-EA7B89F8F421@bangj.com> <5B2DE184-5D87-425A-BA83-5042A81DBCB7@strayalpha.com> <CAPt1N1=Y_60RR+hEU9qEiVXV-zhWOX4a8VThFWwxahBMooGtNg@mail.gmail.com> <A81B945B-3ECC-40BE-84F0-EBEC95834BE1@strayalpha.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/nhRiebP6yo-dWizSRxTYqOLrzx8>
Subject: Re: [dnssd] Unicast Service Discovery Autoconfiguration
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2018 17:09:18 -0000

--Apple-Mail=_463B82B5-B8E0-4E5C-9476-1B5A291EC458
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Agreed. Auto-configuration in general is a use of multicast where loss =
can be detected (like in the IPv6 auto-configuration case) because the =
client either gets a response back or it doesn=E2=80=99t and it can =
retry.

In my opinion, this is a more acceptable use case for multicast =
discovery.

Let=E2=80=99s call it "ANY Discovery=E2=80=9D and it has the following =
properties:

1. You can detect if you get an answer and retry if you don't
2. Any server can respond and provide complete information

Discovering servers where any number of similar but different services =
exist is not a good use of multicast discovery.

Let=E2=80=99s call this =E2=80=9CMANY Discovery=E2=80=9D and it exhibits =
the following properties:

1. You can=E2=80=99t detect if you get responses from ALL of the =
possible services
2. Any server responding typically only has partial information


But in Ted=E2=80=99s case, neither of these apply. He is more concerned =
with other inherent problems with wireless link layer multicast ethernet =
drivers such as excessive delay and power use.

Tom


> On Nov 8, 2018, at 7:49 PM, Joe Touch <touch@strayalpha.com> wrote:
>=20
> OK, maybe I=E2=80=99m confused =E2=80=94 the doc appears to imply:
>=20
> 	- multicast doesn=E2=80=99t work for discovery
> 	- so here=E2=80=99s a unicast mesh instead
>=20
> That seems broken to me. Multicast ought to be more than sufficient - =
even when unreliable - for discovery.
>=20
> *once discovered*, sure, use TCP/TLS to exchange config info. But I =
didn=E2=80=99t get the impression that post-discovery config was the =
focus of the draft.
>=20
> Joe
>=20
>> On Nov 8, 2018, at 3:34 PM, Ted Lemon <mellon@fugue.com =
<mailto:mellon@fugue.com>> wrote:
>>=20
>> This is true but irrelevant. Multicast isn=E2=80=99t a great solution =
anyway. Wakes everyone up, not just who you are trying to reach.=20
>>=20


--Apple-Mail=_463B82B5-B8E0-4E5C-9476-1B5A291EC458
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dutf-8"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" =
class=3D"">Agreed. Auto-configuration in general is a use of multicast =
where loss can be detected (like in the IPv6 auto-configuration case) =
because the client either gets a response back or it doesn=E2=80=99t and =
it can retry.<div class=3D""><br class=3D""></div><div class=3D"">In my =
opinion, this is a more acceptable use case for multicast =
discovery.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Let=E2=80=99s call it "ANY Discovery=E2=80=9D and it has the =
following properties:</div><div class=3D""><br class=3D""></div><div =
class=3D"">1. You can detect if you get an answer and retry if you =
don't</div><div class=3D""><div class=3D"">2. Any server can respond and =
provide complete information</div></div><div class=3D""><br =
class=3D""></div><div class=3D"">Discovering servers where any number of =
similar but different services exist is not a good use of multicast =
discovery.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Let=E2=80=99s call this =E2=80=9CMANY Discovery=E2=80=9D and =
it exhibits the following properties:</div><div class=3D""><br =
class=3D""></div><div class=3D"">1. You can=E2=80=99t detect if you get =
responses from ALL of the possible services</div><div class=3D"">2. Any =
server responding typically only has partial information<br =
class=3D""><div><br class=3D""></div><div><br class=3D""></div><div>But =
in Ted=E2=80=99s case, neither of these apply. He is more concerned with =
other inherent problems with wireless link layer multicast ethernet =
drivers such as excessive delay and power use.</div><div><br =
class=3D""></div><div>Tom</div><div><br class=3D""></div><div><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Nov =
8, 2018, at 7:49 PM, Joe Touch &lt;<a href=3D"mailto:touch@strayalpha.com"=
 class=3D"">touch@strayalpha.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><meta =
http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8" =
class=3D""><div style=3D"word-wrap: break-word; -webkit-nbsp-mode: =
space; line-break: after-white-space;" class=3D"">OK, maybe I=E2=80=99m =
confused =E2=80=94 the doc appears to imply:<div class=3D""><br =
class=3D""></div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>- multicast doesn=E2=80=99t work =
for discovery</div><div class=3D""><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>- so here=E2=80=99s a unicast =
mesh instead</div><div class=3D""><br class=3D""></div><div =
class=3D"">That seems broken to me. Multicast ought to be more than =
sufficient - even when unreliable - for discovery.</div><div =
class=3D""><br class=3D""></div><div class=3D"">*once discovered*, sure, =
use TCP/TLS to exchange config info. But I didn=E2=80=99t get the =
impression that post-discovery config was the focus of the =
draft.</div><div class=3D""><br class=3D""></div><div =
class=3D"">Joe</div><div class=3D""><div class=3D""><br =
class=3D""><blockquote type=3D"cite" class=3D""><div class=3D"">On Nov =
8, 2018, at 3:34 PM, Ted Lemon &lt;<a href=3D"mailto:mellon@fugue.com" =
class=3D"">mellon@fugue.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div class=3D""><div =
dir=3D"auto" class=3D"">This is true but irrelevant. Multicast isn=E2=80=99=
t a great solution anyway. Wakes everyone up, not just who you are =
trying to reach.&nbsp;</div></div><div class=3D""><br =
class=3D""></div></div></blockquote></div></div></div></div></blockquote><=
/div><br class=3D""></div></body></html>=

--Apple-Mail=_463B82B5-B8E0-4E5C-9476-1B5A291EC458--


From nobody Wed Nov 14 17:37:16 2018
Return-Path: <dschinazi.ietf@gmail.com>
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 AE5C7130E4D for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 17:37:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aC4MPioegCMu for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 17:37:12 -0800 (PST)
Received: from mail-pl1-x62c.google.com (mail-pl1-x62c.google.com [IPv6:2607:f8b0:4864:20::62c]) (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 D01FB130E4B for <dnssd@ietf.org>; Wed, 14 Nov 2018 17:37:12 -0800 (PST)
Received: by mail-pl1-x62c.google.com with SMTP id b22-v6so3208704pls.7 for <dnssd@ietf.org>; Wed, 14 Nov 2018 17:37:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=YvO7O1EzmQDm4Irla3JRVG0xeqVIb2vrynLgTcsxxVo=; b=PYUPkgj7iuVS+EM/IanfCjyAhV0vfoD4KR6tLo2B1YaqaQ5kcWggXDU3iBcogMzlNL DOjyXFqsvtx4C9UixvT4M85yMlaMFunOOKzUiOhYXuMH6j/MdhGsqmKj0wWnPxFfXiFS cwURLXLTurfiLdFHelCWFaVBKN9MbfBD47W8ta/pzEXFxS9TKiPkQk5bWFv8KvTgxWe4 p0MZfEVt0kzagPIZY9sYmU3+3l7ldRfqgbtCCrJk7ZAB6drmzaLrExxuughWuZJ6lu86 EwruYJXQvIJh6YGAUymnyVsR8/Oac72IqncztC6bUMEtd/fwsoC30kM/T8zBkc/h4DNI V3nA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YvO7O1EzmQDm4Irla3JRVG0xeqVIb2vrynLgTcsxxVo=; b=babxFdnegZZPlQg0KHtzwslSZ5CF9E1Ys2TtikVl6iKL1Y++M5dzJA5UpMfxrWvqHE SFQ77OnJGIhBccHDPqYUT32frxFMhjPkcCOnXX0v0cYOcn8RV6ogtze5zLJX8Pmmp8Wx qZp2Od+Xh7V3PJreDG3RmnCTWQiuHgJ4gPI7D3Li+kACPfkllUr9TCTFLx1VRNksGsD4 jr6MQkLOSJf+gfEb2pOlFLjN1UuYpv3ut2lZG49EWIRuzDQ9J6Ed4rhQST3j74pr0+1d SkSK0od8rfJVKxjN31ebEJuV0HbbAVjWC1PzsenmdTcoaj3XPGFw8GcQRW1IXHr9HyUh pSqg==
X-Gm-Message-State: AGRZ1gLhizU1Tq3LXOzLe8Qe7TH2wUMAYStxHZ/I/jZazSaySWBYwa0F nKnQm5Svr5VegZUFErKSxes36E3oN7N/JuZ1l20DR/YO
X-Google-Smtp-Source: AJdET5eNUJ7bqmV9MNQusihY1hMlfe9+v5rXnZGTKL/u2g1ESMzw2EJlOGPmWXWUF7sGmbNWCaGUN5elV2JMybbc2n4=
X-Received: by 2002:a17:902:9f8c:: with SMTP id g12-v6mr3650158plq.127.1542245831873;  Wed, 14 Nov 2018 17:37:11 -0800 (PST)
MIME-Version: 1.0
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Wed, 14 Nov 2018 17:37:00 -0800
Message-ID: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com>
To: DNSSD <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f717fd057aaa165b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/8TyDpW_lgBumP0g9zTV-12ATDmQ>
Subject: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 01:37:15 -0000

--000000000000f717fd057aaa165b
Content-Type: text/plain; charset="UTF-8"

Hello everyone,

It the room at IETF 103, there was a very productive discussion about DNSSD
privacy:
https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s

During that discussion, the room reached consensus on the following items:

1) single-stage approach -- Up until now, we were considering two
approaches: single-stage (send encrypted and authenticated service
identifier, receive encrypted and authenticated service response) and
two-stage (send encryption and authenticated identifier, receive encrypted
and authenticated response, derive secrets, send and receive subsequent
queries encrypted using derived secrets). There was consensus in the room
to go with the single-stage approach.

2) Use of TLS -- The single-stage approach no longer requires a key
exchange mechanism such as TLS. There was consensus in the room that we do
not need TLS as part of this protocol.

3) Evolution of documents -- It was proposed that we would take all input
and compound it into a single document and only advance that one. We will
use draft-ietf-dnssd-privacy since that document has already been adopted
by the working group. Christian Huitema has offered for Bob Bradley to join
as co-author if Bob would like.

If you disagree with any of these points, please say so before 2018-12-02.

Thanks,
David

--000000000000f717fd057aaa165b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div di=
r=3D"ltr">Hello everyone,<div><br></div><div>It the room at IETF 103, there=
 was a very productive discussion about DNSSD privacy:</div><div><a href=3D=
"https://www.youtube.com/watch?v=3DhPuTD19R-uQ&amp;t=3D28m43s">https://www.=
youtube.com/watch?v=3DhPuTD19R-uQ&amp;t=3D28m43s</a><br></div><div><br></di=
v><div>During that discussion, the room reached consensus on the following =
items:</div><div><br></div><div>1) single-stage approach -- Up until now, w=
e were considering two approaches: single-stage (send encrypted and authent=
icated service identifier, receive encrypted and authenticated service resp=
onse) and two-stage (send encryption and authenticated identifier, receive =
encrypted and authenticated response, derive secrets, send and receive subs=
equent queries encrypted using derived secrets). There was consensus in the=
 room to go with the single-stage approach.</div><div><br></div><div>2) Use=
 of TLS -- The single-stage approach no longer requires a key exchange mech=
anism such as TLS. There was consensus in the room that we do not need TLS =
as part of this protocol.</div><div><br></div><div>3) Evolution of document=
s -- It was proposed that we would take all input and compound it into a si=
ngle document and only advance that one. We will use=C2=A0draft-ietf-dnssd-=
privacy since that document has already been adopted by the working group. =
Christian Huitema has offered for Bob Bradley to join as co-author if Bob w=
ould like.</div><div><br></div><div>If you disagree with any of these point=
s, please say so before 2018-12-02.</div><div><br></div><div>Thanks,</div><=
div>David</div></div></div></div></div></div>

--000000000000f717fd057aaa165b--


From nobody Wed Nov 14 17:37:23 2018
Return-Path: <dschinazi.ietf@gmail.com>
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 6400C130E4D for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 17:37:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXwJP8VYk27u for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 17:37:15 -0800 (PST)
Received: from mail-pg1-x52f.google.com (mail-pg1-x52f.google.com [IPv6:2607:f8b0:4864:20::52f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED589130E4B for <dnssd@ietf.org>; Wed, 14 Nov 2018 17:37:14 -0800 (PST)
Received: by mail-pg1-x52f.google.com with SMTP id y4so8204942pgc.12 for <dnssd@ietf.org>; Wed, 14 Nov 2018 17:37:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to; bh=C/N8MbSbKtoXINe1ip0i9sm7CsZw9NO7sP853FeQYf4=; b=s0RzepmPuVeA2+BiEC534LlaIBbEAZIQoPHhibqggSOjGh3VBEYC5SadB0nV5PC6kl oE54+uXYLKhgD6TDUpjpRcDb4I6yvSrxYHiSgKhHo0OBlwyNjipFZAjA+11UrBAtPjCU QB+w8U1awsT3i3b0jDks4n9eQ/hyMj+NvhckG8PXQW1gO5tHVp7MIhAK56oBdF44tSc9 i8Q3ep9Ep/0QaTDDFp+u+KgqlI5Nu9Gl1gEmf4Y/l4BqUTBFeGdjlXk+Vflk676JSbCX U7wxGmbvs/PPzfQ66zUYYrlSvLSyo+TnIq7wun6zfa6aaWKMx4zp1TRre42huCee8ed2 hnOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=C/N8MbSbKtoXINe1ip0i9sm7CsZw9NO7sP853FeQYf4=; b=TmtDO7EPyohOh85Q9ZDU24/CxoOU/UWzL6fCJEJfBvHCg2fYS/aVep8riqJ35IEdZn CKTaie2UkjRWzwxsVJcDNvw+1qRF5tj5BacQr7hqQHMQnULEml73am12EtFM2jepUxju eHjX3tc5ET/pZs52wm+34YYqdK63mxzPG8zOAa85xwhcEnHzHY22nGdGAistN/kfkLi+ 0M2Zy8VFb7HZkqrgdnC7vL4NklfRQZHQcvCtKtX8dUc6nX4q0XAXbbMzlPKIKCa/gTbf 7aPT1FssCXBkg6JLVJ5djq8B7cgjpscurAYvVKfr8JqWrW0aa2IOqXSSShKBHdGHFs+X bQTw==
X-Gm-Message-State: AGRZ1gLGlvdSZVOryOpTR7+ssV4hdvWK/cj86uV8dCRDZybnt+RoKJxI NQVWUOY75X/Y+yoVfNwPglhDYqdi32HAnrMpzIaHmyuW
X-Google-Smtp-Source: AJdET5eFiULj8HXvNe7lqHQZuveP/Y68haLq75quAWW4OC+SNh0k/ki4hHVUuyOG5mD/pqZn69yNJGky2NQa1C45R8w=
X-Received: by 2002:a63:4f20:: with SMTP id d32mr3982570pgb.47.1542245834248;  Wed, 14 Nov 2018 17:37:14 -0800 (PST)
MIME-Version: 1.0
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Wed, 14 Nov 2018 17:37:03 -0800
Message-ID: <CAPDSy+7HeQQnWXMJZyzJ170tAE83jzQuUsEn7GQHCtuL4Gn74Q@mail.gmail.com>
To: DNSSD <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000001b5700057aaa17a6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/psSOulPr6_EG7twm6qMFRokJM0o>
Subject: [dnssd] Minutes posted for the DNSSD Bangkok meeting
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 01:37:16 -0000

--0000000000001b5700057aaa17a6
Content-Type: text/plain; charset="UTF-8"

Hello everyone,

We've posted the minutes for the DNSSD Bangkok meeting:
https://datatracker.ietf.org/meeting/103/materials/minutes-103-dnssd

Thanks to Barbara Stark and Chris Wood for taking minutes!

Please review them to ensure your contributions were correctly represented.

Thanks,
David

--0000000000001b5700057aaa17a6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">Hello everyone,<div><br></div><div>We&#39=
;ve posted the minutes for the DNSSD Bangkok meeting:</div><div><a href=3D"=
https://datatracker.ietf.org/meeting/103/materials/minutes-103-dnssd">https=
://datatracker.ietf.org/meeting/103/materials/minutes-103-dnssd</a><br></di=
v><div><br></div><div>Thanks to Barbara Stark and Chris Wood for taking min=
utes!</div><div><br></div><div>Please review them to ensure your contributi=
ons were correctly represented.</div><div><br></div><div>Thanks,</div><div>=
David</div></div></div>

--0000000000001b5700057aaa17a6--


From nobody Wed Nov 14 17:43:04 2018
Return-Path: <dschinazi.ietf@gmail.com>
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 DF174130E73 for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 17:43:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baSOrTk94VLt for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 17:43:00 -0800 (PST)
Received: from mail-pf1-x42a.google.com (mail-pf1-x42a.google.com [IPv6:2607:f8b0:4864:20::42a]) (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 60B40130E6F for <dnssd@ietf.org>; Wed, 14 Nov 2018 17:43:00 -0800 (PST)
Received: by mail-pf1-x42a.google.com with SMTP id 64so4363079pfr.9 for <dnssd@ietf.org>; Wed, 14 Nov 2018 17:43:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:from:date:message-id:subject:to:cc; bh=BUaAbATsdMXv3mWxSRqVlD+nc+4ZpUvAn+YO9/15yJc=; b=I67hDnt3haUbMMnUcmpAuF5gumK0BbAGgjj7h1ycxCjNqp+doGxA75Agcxp8gjh6E+ L3igcvrdg17Clom01+wS2uBdVmjSOEomT1n7cUSQtmqgSv0Ajx2kj2kuhgNV4JAzzw7q mnYH8TIzdG4P7GKY6aV4CPstfxSywyeTYF3xzCPndXQedQRg24VBXbKiK9k9DiSbfsO3 bguAOFZGZgr7Ab3scWXx2iQtMsMnioYKqBkzJ8y+Rzu7wkn9Px98Uy6Mw9oO/kL1JPBd xjSlH9ch2KB4mg9uIH29EfPP/Gi7tA4I37YyJ5WOI1DeycHFs5xpH3xx4VVIDK50hOWh KPxA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=BUaAbATsdMXv3mWxSRqVlD+nc+4ZpUvAn+YO9/15yJc=; b=ZhubZPDPqHjQLf5OpCY6Vh+1r03kuHAWbfsLp6A8uqiupfiB8LhqSsC5NL4zTeuOgY m+3wHvdsdYaBZs7d3kFifOVL6h8mp3+JXaFprDO0tBfWE19I2Bt6EDgKxeYkZZwHd0+G eP6rArJkBIKIBqte/LvTwYPcbRtZAs4CKPqmDjBjalJ2YerHwpeaZgrXEhF+UqcVJym6 ULbi4zrNJMKFjd65dmrTVO+KHmffNOGzBEesIhUh865TUyZMofh+O3lxtNRrqeaF+MKR 5AoVPr2NK7UIU8imWoBtmNG30XVv8N2tKvPWBYSkOQdF3D1XVUfSJM3Hi+P7nP+TbqVg rteQ==
X-Gm-Message-State: AGRZ1gIjmB5IYSTayAaGCAxvDwT5ipBd2XyLYr3XP1cuCE9dU3iSSGxV rIZxmZDqUDl2OfoQgiVIY6kWB6dC47WqLbWlOB+XXJJC
X-Google-Smtp-Source: AJdET5f4AL6u/c8OJ+i23tDbVU2RSeT8AZ6r9pfwuwR+DcLL7rq7acUUuphPJjqr1cJTUOZyTow6dnoESRlF1eF7G18=
X-Received: by 2002:a65:55ca:: with SMTP id k10mr3934613pgs.448.1542246179986;  Wed, 14 Nov 2018 17:42:59 -0800 (PST)
MIME-Version: 1.0
From: David Schinazi <dschinazi.ietf@gmail.com>
Date: Wed, 14 Nov 2018 17:42:48 -0800
Message-ID: <CAPDSy+7gKd2tbm6GEiGJMU=WP1rswBvrEmKzuQe=MXXsRAMQGg@mail.gmail.com>
To: Stuart Cheshire <cheshire@apple.com>
Cc: DNSSD <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000b6de4c057aaa2bb7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/jFb1-fx-YQFFQ6_JaQXes6CBsQo>
Subject: [dnssd] WG Adoption of draft-cheshire-dnssd-roadmap
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 01:43:03 -0000

--000000000000b6de4c057aaa2bb7
Content-Type: text/plain; charset="UTF-8"

Hi Stuart,

When you have a minute, please resubmit draft-cheshire-dnssd-roadmap as WG
document draft-ietf-dnssd-roadmap.

We discussed this in Bangkok and everyone in the room agreed that we should
adopt it, and it turns out the WG all already reached consensus and we were
just waiting for you to submit a revision:
https://www.ietf.org/mail-archive/web/dnssd/current/msg01138.html

Thanks,
David

--000000000000b6de4c057aaa2bb7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hi Stua=
rt,<div><br></div><div>When you have a minute, please resubmit=C2=A0draft-c=
heshire-dnssd-roadmap as WG document draft-ietf-dnssd-roadmap.</div><div><b=
r></div><div>We discussed this in Bangkok and everyone in the room agreed t=
hat we should adopt it, and it turns out the WG all already reached consens=
us and we were just waiting for you to submit a revision:</div><div><a href=
=3D"https://www.ietf.org/mail-archive/web/dnssd/current/msg01138.html">http=
s://www.ietf.org/mail-archive/web/dnssd/current/msg01138.html</a><br></div>=
<div><br></div><div>Thanks,</div><div>David</div></div></div></div></div>

--000000000000b6de4c057aaa2bb7--


From nobody Wed Nov 14 17:51:54 2018
Return-Path: <christopherwood07@gmail.com>
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 898C6130E90 for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 17:51:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krrbLsXgWWsw for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 17:51:50 -0800 (PST)
Received: from mail-it1-x131.google.com (mail-it1-x131.google.com [IPv6:2607:f8b0:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C32C7130D7A for <dnssd@ietf.org>; Wed, 14 Nov 2018 17:51:50 -0800 (PST)
Received: by mail-it1-x131.google.com with SMTP id f84-v6so5843354ita.1 for <dnssd@ietf.org>; Wed, 14 Nov 2018 17:51:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Vjnk2TzZGrCBWqLBRHaBHFZlPCBUDv/PKiE0tciTZbw=; b=HaBnOD2gOMONhYVXX6iV2hD3vNF+khUpgcPItjUVSlChbmZOKnGtWC57IVzoMYEMOu MJJUPzvJTvDqAmO8TPtFrlN3X+G2oig6KiVzmqGaNmnSlQA+pAORwtbuJoLCVTQSpSQs 48cSo14veCRCOmw/U4Sek0SRfkMvfwYZFm0BTLy5182hqYmPqf3SFuxiqa5nLLhlzop7 KaVFN/bpWG0xsV2GuegyiRWA3TTMXMxRpO4nEIJXsEN7jVPcjbCpjCccHpWgqwYsj4/g rIigDHLvDtjtEv0RHBGLxc1l8Q+pCo96wJIaU8N8GgQrdWsv509KaY5QULmrn5nyT3A0 XjmA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Vjnk2TzZGrCBWqLBRHaBHFZlPCBUDv/PKiE0tciTZbw=; b=ZAvahDFTNgMexxPpPe1DGzstD9lewPH1pBR1laBK8C8g9pz9q3y4Av5yY6N+v0GwqB VzrLwtFYxiTkifa2R02za6y2sJ35jP1A3dVrYUH7J9Jc77X/bJEp4vHFW9YCCh26TxVg n2HjC4FxXVJXUYQzRWpBxRyvHcfUjIrNV/SCyLDwjH5q3senE6j/8hOZptuDjCQoBYYD boxxDg8Up8cMxBOy6RAADQ7yzfT6bK7QM5kWUy1qSKOvi5Jud5VJi5v4nI4mDB0LJD5P jVgjd1hINGXbP4MGST6YhewZa1ALyyIO/QqHAw9fkm7yJfszzc1Xh0RPAviGB3C+tosV Na2w==
X-Gm-Message-State: AGRZ1gIB1A7Z+MKMMmdO9dPjH4Iw1u7V1jKVC3QSw+5d+XXN0kOz7vsD Y4EyjMBJYPhTR7sYeP3Dohd5gDiL9q3jkqBbdW8=
X-Google-Smtp-Source: AJdET5e7u9eohsomk5jx1pvQSgO2KekPri7IXuexeOBiDrLrLro/brV7I9F2HCrh77S72pJT38/0bDmY0YFqj90WQr8=
X-Received: by 2002:a24:a08a:: with SMTP id o132mr4383938ite.1.1542246709913;  Wed, 14 Nov 2018 17:51:49 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com>
In-Reply-To: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com>
From: Christopher Wood <christopherwood07@gmail.com>
Date: Wed, 14 Nov 2018 17:51:37 -0800
Message-ID: <CAO8oSXn4FiDF9FFPH4aHN80zH8+sQFswZzvCszvwCBvqFH9MFw@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: dnssd@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/QLRWaB3wITDnQ9p6sSrEsDtyaIk>
Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 01:51:52 -0000

On Wed, Nov 14, 2018 at 5:37 PM David Schinazi <dschinazi.ietf@gmail.com> w=
rote:
>
> Hello everyone,
>
> It the room at IETF 103, there was a very productive discussion about DNS=
SD privacy:
> https://www.youtube.com/watch?v=3DhPuTD19R-uQ&t=3D28m43s
>
> During that discussion, the room reached consensus on the following items=
:
>
> 1) single-stage approach -- Up until now, we were considering two approac=
hes: single-stage (send encrypted and authenticated service identifier, rec=
eive encrypted and authenticated service response) and two-stage (send encr=
yption and authenticated identifier, receive encrypted and authenticated re=
sponse, derive secrets, send and receive subsequent queries encrypted using=
 derived secrets). There was consensus in the room to go with the single-st=
age approach.
>
> 2) Use of TLS -- The single-stage approach no longer requires a key excha=
nge mechanism such as TLS. There was consensus in the room that we do not n=
eed TLS as part of this protocol.
>
> 3) Evolution of documents -- It was proposed that we would take all input=
 and compound it into a single document and only advance that one. We will =
use draft-ietf-dnssd-privacy since that document has already been adopted b=
y the working group. Christian Huitema has offered for Bob Bradley to join =
as co-author if Bob would like.
>
> If you disagree with any of these points, please say so before 2018-12-02=
.
>
> Thanks,
> David
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd


From nobody Wed Nov 14 17:55:25 2018
Return-Path: <christopherwood07@gmail.com>
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 379BB130E13 for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 17:55:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.75
X-Spam-Level: 
X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5_7sXwed2A6H for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 17:55:23 -0800 (PST)
Received: from mail-it1-x12e.google.com (mail-it1-x12e.google.com [IPv6:2607:f8b0:4864:20::12e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8ACA130DF9 for <dnssd@ietf.org>; Wed, 14 Nov 2018 17:55:22 -0800 (PST)
Received: by mail-it1-x12e.google.com with SMTP id t190-v6so27115435itb.2 for <dnssd@ietf.org>; Wed, 14 Nov 2018 17:55:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:references:from:date:message-id:subject:to:cc :content-transfer-encoding; bh=7z+lUIK5Ro2owOQdmLVm2L8qLQy8BwUB4xqp171K8ew=; b=uhNqC9XKmMElw7v1hO3uIdYBansLTH4QGjHqczwIxpDx/2MlqQuNC5CGoiI9UXTmUS yV4I//AkBIkK3suqlBmFrxCryzZHsfxjy9z2ZUHMRrHTld+B0p+A7W7GlGu/NHVphKSi okl6kEWs37a1ZuW/qHlpSJo6cr1m0VULdk+U5wizqtVy6HQxZf2u71jFBPpzYg9DeiXg QFiTo0QIHN1mBzfRoBg4TqGhUJTfSE+fuWhIOsO9u9iD4i/KWLMaRbjunEfRO3IHnGsL AMTlB/uSME3Y05b07xPM6DK7Ti8GBaGhrUDitiij17ttq679FAKykp6CyHhi5vcBjMsV FSOQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:from:date:message-id :subject:to:cc:content-transfer-encoding; bh=7z+lUIK5Ro2owOQdmLVm2L8qLQy8BwUB4xqp171K8ew=; b=ulwfD1AKzy/Q3shT/0Qnm6SAPivCBGXQUXwk87SDR2RdDenwq+qUt9gEgGRhfTVbXS QADF1NBskOjhaOQh5vHAQW3hTMmdBNjEOeUd0afmEoW3m3mQNMfmxXu0w9Rdi8rLHFkk gRMgtacuV2W/8/6sLw4nXZZzHu02hOKFMJOWlDlFfnVqTnUbtWLddH0IJt3mC9rxeu2B wf120RLmEf0I6aXm9F3zsju5s1UBT8kQT/KaxjFPN76Q+wq9cVEyCZrQscTofLWxKBer fIWndGA3PY6ZewAmNyu5WRU0FXgj0i9VJ7TGqo6Of0i7gEIiYSLG+E00YN2sCfGDB8mL FWdg==
X-Gm-Message-State: AGRZ1gK1Dqsw+gA7KeUUEcyJI8oSsN3gt41I/vpUb4i3IutanG7nmQsQ 8p40KZ4B/2PI3R2LxPPwTmwR/WR2htbYtXx6r6M=
X-Google-Smtp-Source: AJdET5dnSEzxxzwXEen75Df8gdJJ9EXNChmVA4OGSlHdQmoeKlMm0mq5+9U5TNq/mjGkdY7Abt+HPHKps/lp4cGOZzw=
X-Received: by 2002:a02:91c9:: with SMTP id s9-v6mr4266270jag.104.1542246922111;  Wed, 14 Nov 2018 17:55:22 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com> <CAO8oSXn4FiDF9FFPH4aHN80zH8+sQFswZzvCszvwCBvqFH9MFw@mail.gmail.com>
From: Christopher Wood <christopherwood07@gmail.com>
Date: Wed, 14 Nov 2018 17:55:10 -0800
Message-ID: <CAO8oSX=_2fY79KhNL6+8oAPe10SEHAbW0h8N77G7iChfn55M1g@mail.gmail.com>
To: David Schinazi <dschinazi.ietf@gmail.com>
Cc: dnssd@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/71FI_QakfZUlejj13Mk7yXP9cNw>
Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 01:55:24 -0000

(Oops. Actual text below.)

> On Wed, Nov 14, 2018 at 5:37 PM David Schinazi <dschinazi.ietf@gmail.com>=
 wrote:
> >
> > Hello everyone,
> >
> > It the room at IETF 103, there was a very productive discussion about D=
NSSD privacy:
> > https://www.youtube.com/watch?v=3DhPuTD19R-uQ&t=3D28m43s
> >
> > During that discussion, the room reached consensus on the following ite=
ms:
> >
> > 1) single-stage approach -- Up until now, we were considering two appro=
aches: single-stage (send encrypted and authenticated service identifier, r=
eceive encrypted and authenticated service response) and two-stage (send en=
cryption and authenticated identifier, receive encrypted and authenticated =
response, derive secrets, send and receive subsequent queries encrypted usi=
ng derived secrets). There was consensus in the room to go with the single-=
stage approach.
> >
> > 2) Use of TLS -- The single-stage approach no longer requires a key exc=
hange mechanism such as TLS. There was consensus in the room that we do not=
 need TLS as part of this protocol.

One issue Christian and I discussed after the meeting concluded is the
possibility of dictionary attacks on the service identifier. With the
predictable nonce obfuscation proposal, which would necessarily
include the service identifier in the first query, leaking the client
public key to an adversary allows offline dictionary attacks on the
service. Whether or not this is a problem depends on the threat model.

Note that it's likely possible to bootstrap the two-stage approach
using the single-stage approach. But that would bring back in the
question of whether or not to use TLS.

Best,
Chris


From nobody Wed Nov 14 18:35:08 2018
Return-Path: <huitema@huitema.net>
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 7B969130E0C for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 18:35:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hWgS1pur8iHK for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 18:35:04 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DACF1298C5 for <dnssd@ietf.org>; Wed, 14 Nov 2018 18:35:04 -0800 (PST)
Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx105.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gN7Uh-0003jy-It for dnssd@ietf.org; Thu, 15 Nov 2018 03:35:01 +0100
Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1gN7Ud-00047F-8V for dnssd@ietf.org; Wed, 14 Nov 2018 21:34:55 -0500
Received: (qmail 11709 invoked from network); 15 Nov 2018 02:34:52 -0000
Received: from unknown (HELO [172.17.0.218]) (Authenticated-user:_huitema@huitema.net@[67.137.70.133]) (envelope-sender <huitema@huitema.net>) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for <christopherwood07@gmail.com>; 15 Nov 2018 02:34:52 -0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (16A404)
In-Reply-To: <CAO8oSX=_2fY79KhNL6+8oAPe10SEHAbW0h8N77G7iChfn55M1g@mail.gmail.com>
Date: Wed, 14 Nov 2018 18:34:51 -0800
Cc: David Schinazi <dschinazi.ietf@gmail.com>, dnssd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <4DC44E01-4D1F-4DE6-A3CB-B28B2B1E9C41@huitema.net>
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com> <CAO8oSXn4FiDF9FFPH4aHN80zH8+sQFswZzvCszvwCBvqFH9MFw@mail.gmail.com> <CAO8oSX=_2fY79KhNL6+8oAPe10SEHAbW0h8N77G7iChfn55M1g@mail.gmail.com>
To: Christopher Wood <christopherwood07@gmail.com>
X-Originating-IP: 168.144.250.232
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.19)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5phHyTnt5E6hbT+Z1NuPirl602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxNr6k8H4Nu3YFoMAWNcFDdlDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5jmcs6wj/46gnUNWAdTw+hKXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdseygOIcx4SICe6nNcjjd/M50Y6QGVSvC9ATxEYI3bPwB8Um0szy6EOVK h0FYxgqqaaxqJvBXd7I82n0qpCzrPWiSwKPXNKNk2RVY2K5nyLgw1Z+7sPmjIM3bM0ihYRE0YjPM ySEj7fwLz33nMnt8v2VAAWCpsuwwFLcJK7RNhb8o82CP6KnOBvL4JpDTCrFGRy3x++ihDWxOBRiB 8THM2szFhr/5lzDngyPb7RDLpa4CiCHqAeeZGuerhbgzLuS7t5s+tU38SL4vC8Dk71a0SIWgzM60 voqUUzJmvILAkkfgIL6w7C9khN/qY0tZyjtbwm1Xgjmuntq3xZgBxhdNFJUcZu3d9ZNXJQW8HUxK X5uYJmvDK3PKrieG7T6bf9hS7hR0q7xASYaBUaOtmtSkj3iuxJhh7EHDojb6D9Mx+gs1+GHf4ys4 4rg2B8/9FmK9a1O9x7lsssuZ/53sObhu0YJN
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/pB3tWEnMpUtHCHiHy_xUSfHakIE>
Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 02:35:06 -0000

=20

> On Nov 14, 2018, at 5:55 PM, Christopher Wood <christopherwood07@gmail.com=
> wrote:
>=20
> One issue Christian and I discussed after the meeting concluded is the
> possibility of dictionary attacks on the service identifier. With the
> predictable nonce obfuscation proposal, which would necessarily
> include the service identifier in the first query, leaking the client
> public key to an adversary allows offline dictionary attacks on the
> service. Whether or not this is a problem depends on the threat model.

I agree this id an attack, but it is a secondary exploit of leaking the key.=
 My take is that leaking the key is a catastrophic failure, which enables tr=
acking the key's owner movements. Leaking the service ID on top of the user i=
dentity is not good, but service connections can also be identified by vario=
us fingerprinting methods. If you are paranoid, use a two stage method. But i=
n most cases, the trade off between risk and performance will favors the one=
 stage approach.


>=20
> Note that it's likely possible to bootstrap the two-stage approach
> using the single-stage approach. But that would bring back in the
> question of whether or not to use TLS.

I would personally rather use TLS than invent something, but Bob's draft is p=
robably fine too.

-- Christian Huitema=20=


From nobody Wed Nov 14 21:36:24 2018
Return-Path: <bradley@apple.com>
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 13A06127148 for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 21:36:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.47
X-Spam-Level: 
X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kmst861Cpk-c for <dnssd@ietfa.amsl.com>; Wed, 14 Nov 2018 21:36:20 -0800 (PST)
Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9482312426A for <dnssd@ietf.org>; Wed, 14 Nov 2018 21:36:20 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.22/8.16.0.22) with SMTP id wAF5WQFS055536 for <dnssd@ietf.org>; Wed, 14 Nov 2018 21:36:19 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : subject : date : references : to : in-reply-to : message-id; s=20180706; bh=j3Yehub0Hdv+JzKEfRoZ3jFMxmhapIz+vmNx6PSiegI=; b=U0MC1txRC6NPvo+I+vrgxVQvoxwgW40dVYwUh2iCdBnfRR7t7OOJJPTKJ5PnINW0mm1d a4ybsOvEbT85xySHsoz+QYUQHIJoThcnSLr3mrc8i8rOf6pZEm35PSINKhyT4KR9auuC StTO0Cff8Fgto3x9y2imc5S9lkJjzwOnC7502l1HP07aaueXQnnCy4iqPWLy+H7LfsFG BFOymUeOjvFIIZG8ZVk8/gtyUyUjsn4JEn25O1GRzOY/u42UdJdVlPo+hMY1hkVs+lIo 3A0MOZaS5b76h4BqPKkkvjtY11Ft6ED+vocF/WwemhCfSZ42bkbLEbfmG2+1Ks6VqPbq FA== 
Received: from ma1-mtap-s03.corp.apple.com (ma1-mtap-s03.corp.apple.com [17.40.76.7]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2nr7bsyrr3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <dnssd@ietf.org>; Wed, 14 Nov 2018 21:36:19 -0800
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_VYceCtChgJjJTQMzioferg)"
Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by ma1-mtap-s03.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PI700K7JZKIG670@ma1-mtap-s03.corp.apple.com> for dnssd@ietf.org; Wed, 14 Nov 2018 21:36:19 -0800 (PST)
Received: from process_viserion-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PI700G00ZAEHX00@nwk-mmpp-sz11.apple.com> for dnssd@ietf.org; Wed, 14 Nov 2018 21:36:18 -0800 (PST)
X-Va-A: 
X-Va-T-CD: 30a9c062f6936833101a7e3ef1ad5808
X-Va-E-CD: a4bee68cb9a28f988d727c8ecff39609
X-Va-R-CD: edf26e1a2599e7fb606d76b44a391aa1
X-Va-CD: 0
X-Va-ID: 5372510d-2d2c-4ad7-9fb8-39f84632fcb0
X-V-A: 
X-V-T-CD: 67f481029bce65efa0808f4eee5f1f07
X-V-E-CD: a4bee68cb9a28f988d727c8ecff39609
X-V-R-CD: edf26e1a2599e7fb606d76b44a391aa1
X-V-CD: 0
X-V-ID: ee7c94fb-b375-4d6b-86c5-e9c57beb9a1e
Received: from process_milters-daemon.nwk-mmpp-sz11.apple.com by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PI700J00ZHZJL00@nwk-mmpp-sz11.apple.com> for dnssd@ietf.org; Wed, 14 Nov 2018 21:36:18 -0800 (PST)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-15_03:,, signatures=0
Received: from [17.234.61.203] by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PI700IPRZKHPJ30@nwk-mmpp-sz11.apple.com> for dnssd@ietf.org; Wed, 14 Nov 2018 21:36:18 -0800 (PST)
Sender: bradley@apple.com
From: Bob Bradley <bradley@apple.com>
Date: Wed, 14 Nov 2018 21:36:15 -0800
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com>
To: DNSSD <dnssd@ietf.org>
In-reply-to: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com>
Message-id: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-15_03:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/cLne04U3cRddqLqeTcQKu6sE-QE>
Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 05:36:23 -0000

--Boundary_(ID_VYceCtChgJjJTQMzioferg)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

I'm a little unclear what is being considered single-stage vs two-stage. How is single-stage able to send encrypted without knowing the destination? Is it encrypting a query with an asymmetric private key and multicasting? Or does single-stage refer to the predictable nonce approach? I was considering predictable nonce's two-stage because it has to first discover known peer service instances (stage 1) then perform encrypted queries/responses (stage 2).

Regarding the discussion:

1. Server mode. My proposal doesn't have a good way to support it. Normal server mode wasn't an important use case for me, but sleep proxy support would be nice. I just don't know how to do it yet, at least not without giving the sleep proxy your keys.

2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy is each device advertising a service instance for each pairing. The network I'm on now has 300+ devices and if each one has 50 friends, that's 15000 service instances on the network, which seems very high.

I tried to reduce this by each device only advertising itself via multicast and then everything else is unicast. The first part of key exchange was also rolled into the advertisement packet to allow a single query packet and single response packet while still maintaining forward secrecy and per-pairing confidentiality.

3. CPU cost. This seems to be a comparison between more packets, but lower per-packet cost (in the per-pairing service instance model where predictable nonce hashes are precomputed) vs fewer packets, but more expensive per-packet signature verification. The two main use cases I was considering were home networks (where neither traffic nor CPU is likely to be an issue due to the small number of devices) and busy enterprise networks (office, dorm, coffee shop), which I assumed would be more powerful devices (laptops, phones, servers) where reducing traffic would be more important than the CPU usage for checking multicast probes.

4. One privacy concern regarding predictable nonces is that it would allow spoofing. Anyone with your public key could generate your predictable nonce. It could also enable friend relationships to be recovered. Maybe not a huge concern, but something to consider. Even the signature approach has a replay vulnerability, but it's time bounded.

> On Nov 14, 2018, at 5:37 PM, David Schinazi <dschinazi.ietf@gmail.com> wrote:
> 
> Hello everyone,
> 
> It the room at IETF 103, there was a very productive discussion about DNSSD privacy:
> https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s <https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s>
> 
> During that discussion, the room reached consensus on the following items:
> 
> 1) single-stage approach -- Up until now, we were considering two approaches: single-stage (send encrypted and authenticated service identifier, receive encrypted and authenticated service response) and two-stage (send encryption and authenticated identifier, receive encrypted and authenticated response, derive secrets, send and receive subsequent queries encrypted using derived secrets). There was consensus in the room to go with the single-stage approach.
> 
> 2) Use of TLS -- The single-stage approach no longer requires a key exchange mechanism such as TLS. There was consensus in the room that we do not need TLS as part of this protocol.
> 
> 3) Evolution of documents -- It was proposed that we would take all input and compound it into a single document and only advance that one. We will use draft-ietf-dnssd-privacy since that document has already been adopted by the working group. Christian Huitema has offered for Bob Bradley to join as co-author if Bob would like.
> 
> If you disagree with any of these points, please say so before 2018-12-02.
> 
> Thanks,
> David
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd


--Boundary_(ID_VYceCtChgJjJTQMzioferg)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">I'm =
a little unclear what is being considered single-stage vs two-stage. How =
is single-stage able to send encrypted without knowing the destination? =
Is it encrypting a query with an asymmetric private key and =
multicasting? Or does single-stage refer to the predictable nonce =
approach? I was considering&nbsp;predictable nonce's two-stage because =
it has to first discover known peer service instances (stage 1) then =
perform encrypted queries/responses (stage 2).<div class=3D""><br =
class=3D""></div><div class=3D"">Regarding the discussion:</div><div =
class=3D""><br class=3D""></div><div class=3D"">1. Server mode. My =
proposal doesn't have a good way to support it. Normal server mode =
wasn't an important use case for me, but sleep proxy support would be =
nice. I just don't know how to do it yet, at least not without giving =
the sleep proxy your keys.</div><div class=3D""><br class=3D""></div><div =
class=3D"">2. Multicast traffic. One problem I saw =
with&nbsp;draft-ietf-dnssd-privacy is each device advertising a service =
instance for each pairing. The network I'm on now has 300+ devices and =
if each one has 50 friends, that's 15000 service instances on the =
network, which seems very high.</div><div class=3D""><br =
class=3D""></div><div class=3D"">I tried to reduce this by each device =
only advertising itself via multicast and then everything else is =
unicast. The first part of key exchange was also rolled into the =
advertisement packet to allow a single query packet and single response =
packet while still maintaining forward secrecy and per-pairing =
confidentiality.</div><div class=3D""><br class=3D""></div><div =
class=3D"">3. CPU cost. This seems to be a comparison between more =
packets, but lower per-packet cost (in the per-pairing service instance =
model where predictable nonce hashes are precomputed) vs fewer packets, =
but more expensive per-packet signature verification. The two main use =
cases I was considering were home networks (where neither traffic nor =
CPU is likely to be an issue due to the small number of devices) and =
busy enterprise networks (office, dorm, coffee shop), which I assumed =
would be more powerful devices (laptops, phones, servers) where reducing =
traffic would be more important than the CPU usage for checking =
multicast probes.</div><div class=3D""><br class=3D""></div><div =
class=3D"">4. One privacy concern regarding predictable nonces is that =
it would allow spoofing. Anyone with your public key could generate your =
predictable nonce. It could also enable friend relationships to be =
recovered. Maybe not a huge concern, but something to consider. Even the =
signature approach has a replay vulnerability, but it's time =
bounded.</div><div class=3D""><div><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Nov 14, 2018, at 5:37 PM, =
David Schinazi &lt;<a href=3D"mailto:dschinazi.ietf@gmail.com" =
class=3D"">dschinazi.ietf@gmail.com</a>&gt; wrote:</div><br =
class=3D"Apple-interchange-newline"><div class=3D""><div dir=3D"ltr" =
class=3D""><div dir=3D"ltr" class=3D""><div dir=3D"ltr" class=3D""><div =
dir=3D"ltr" class=3D""><div dir=3D"ltr" class=3D"">Hello everyone,<div =
class=3D""><br class=3D""></div><div class=3D"">It the room at IETF 103, =
there was a very productive discussion about DNSSD privacy:</div><div =
class=3D""><a =
href=3D"https://www.youtube.com/watch?v=3DhPuTD19R-uQ&amp;t=3D28m43s" =
class=3D"">https://www.youtube.com/watch?v=3DhPuTD19R-uQ&amp;t=3D28m43s</a=
><br class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D"">During that discussion, the room reached consensus on the =
following items:</div><div class=3D""><br class=3D""></div><div =
class=3D"">1) single-stage approach -- Up until now, we were considering =
two approaches: single-stage (send encrypted and authenticated service =
identifier, receive encrypted and authenticated service response) and =
two-stage (send encryption and authenticated identifier, receive =
encrypted and authenticated response, derive secrets, send and receive =
subsequent queries encrypted using derived secrets). There was consensus =
in the room to go with the single-stage approach.</div><div class=3D""><br=
 class=3D""></div><div class=3D"">2) Use of TLS -- The single-stage =
approach no longer requires a key exchange mechanism such as TLS. There =
was consensus in the room that we do not need TLS as part of this =
protocol.</div><div class=3D""><br class=3D""></div><div class=3D"">3) =
Evolution of documents -- It was proposed that we would take all input =
and compound it into a single document and only advance that one. We =
will use&nbsp;draft-ietf-dnssd-privacy since that document has already =
been adopted by the working group. Christian Huitema has offered for Bob =
Bradley to join as co-author if Bob would like.</div><div class=3D""><br =
class=3D""></div><div class=3D"">If you disagree with any of these =
points, please say so before 2018-12-02.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Thanks,</div><div =
class=3D"">David</div></div></div></div></div></div>
_______________________________________________<br class=3D"">dnssd =
mailing list<br class=3D""><a href=3D"mailto:dnssd@ietf.org" =
class=3D"">dnssd@ietf.org</a><br =
class=3D"">https://www.ietf.org/mailman/listinfo/dnssd<br =
class=3D""></div></blockquote></div><br class=3D""></div></body></html>=

--Boundary_(ID_VYceCtChgJjJTQMzioferg)--


From nobody Thu Nov 15 07:23:58 2018
Return-Path: <mellon@fugue.com>
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 D5A00130DCF for <dnssd@ietfa.amsl.com>; Thu, 15 Nov 2018 07:23:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQqsDQrhAZcP for <dnssd@ietfa.amsl.com>; Thu, 15 Nov 2018 07:23:55 -0800 (PST)
Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) (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 B75A5130DCE for <dnssd@ietf.org>; Thu, 15 Nov 2018 07:23:54 -0800 (PST)
Received: by mail-qk1-x72b.google.com with SMTP id n12so32306551qkh.11 for <dnssd@ietf.org>; Thu, 15 Nov 2018 07:23:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fuAIRAjehBHtZVuESiLyGD5MNK+751Bty0BaBEGDZ8Q=; b=Ff7c+AuQyBV7iBYBlNp4YdI4aaJ2Nw7pkk9zdPoTXyQM3bm5jb9QyPYiK1igdn5I0B A0Pm1/eX/wKFtKMm9iJv1JTn5qmDH0D+BycNkFS3x7ZQzl2yyvz+V3oVbW6aBFgcKof4 yPOpvcSprWLtXr3p9+p+K9HZKZAPCaLtn6nzOM+sm7pSB77qNA2uvOKRsMPOmHdYKGqo NawTKzGQhBUVZVAp6vLB8QhkB84P++/EEBLEqebzK0ZGsu5JOOp587NBaTbU6Psara/e j/pn19Jk7WsBFAs0B2BPWtpiq93JOoWwlWjajsC52pzQXj7D4j8azn50UCa18LkqW5K+ srEA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fuAIRAjehBHtZVuESiLyGD5MNK+751Bty0BaBEGDZ8Q=; b=h9C0JpVn8+f5ZdH4j7PV8jDHuT6OKmxONkDVrMGacmGGJJkuwMc/xD4nQURKNob+fH sD/EkNij9nNT8lwvppN47nxmhfZvB0MvnPOP38e992GoF4TrhwrlvUYtpEKAGMy8tCK2 MM0nTx0V/wjRinu3XE8OCKlnqhqApNYW6jluqPo1LR4XAslKQzLX9suw2dRXB092Ma/X byvXgF3H7LHj6bX4LO69VOSAvI+egVF7X0W33NmZStQMcs+wEKDUXznKg9MwN9WTn+Y+ Xo7AINImF0THX1BhksQMCQJ54mkYbZqy23c+xuduyAf4NOEfJt8nVhLXE6QO+VXqNSWi pKlg==
X-Gm-Message-State: AGRZ1gKIuJdelWx/Km4IdMOX4j8fjkW5kXxXOa0hgdW7+K8xVC34/MhG ZPkWYaZbyRoYX3B/6hLYoog2oR14nzZomD2pgc5Rqg==
X-Google-Smtp-Source: AJdET5eoOMOgqYOvi0DYyoJ+wNIhxAsbIMsj8xV51VZpSbPF2ex3oGhr4KdbuMYn57xRp4EYzRT7RUOQ//ZP3lxo0yY=
X-Received: by 2002:a0c:c966:: with SMTP id v35mr6625744qvj.45.1542295433498;  Thu, 15 Nov 2018 07:23:53 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com> <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com>
In-Reply-To: <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 15 Nov 2018 10:23:17 -0500
Message-ID: <CAPt1N1nzbyMVDofO-FWmL3hxjZykE=5BWaL_+DkCCdcH4oPOEQ@mail.gmail.com>
To: bradley@apple.com
Cc: dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000073f5a5057ab5a345"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/1-kVfJ6Dw2zEuamFxwhSzLwDpyo>
Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 15:23:57 -0000

--00000000000073f5a5057ab5a345
Content-Type: text/plain; charset="UTF-8"

Hm.  To your point #4, I guess the question is, how easy is it for the
public key to leak?   If you ever share your public key with anyone, they
can definitely spoof you, but what do they get out of that?

On Thu, Nov 15, 2018 at 12:36 AM Bob Bradley <bradley@apple.com> wrote:

> I'm a little unclear what is being considered single-stage vs two-stage.
> How is single-stage able to send encrypted without knowing the destination?
> Is it encrypting a query with an asymmetric private key and multicasting?
> Or does single-stage refer to the predictable nonce approach? I was
> considering predictable nonce's two-stage because it has to first discover
> known peer service instances (stage 1) then perform encrypted
> queries/responses (stage 2).
>
> Regarding the discussion:
>
> 1. Server mode. My proposal doesn't have a good way to support it. Normal
> server mode wasn't an important use case for me, but sleep proxy support
> would be nice. I just don't know how to do it yet, at least not without
> giving the sleep proxy your keys.
>
> 2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy is
> each device advertising a service instance for each pairing. The network
> I'm on now has 300+ devices and if each one has 50 friends, that's 15000
> service instances on the network, which seems very high.
>
> I tried to reduce this by each device only advertising itself via
> multicast and then everything else is unicast. The first part of key
> exchange was also rolled into the advertisement packet to allow a single
> query packet and single response packet while still maintaining forward
> secrecy and per-pairing confidentiality.
>
> 3. CPU cost. This seems to be a comparison between more packets, but lower
> per-packet cost (in the per-pairing service instance model where
> predictable nonce hashes are precomputed) vs fewer packets, but more
> expensive per-packet signature verification. The two main use cases I was
> considering were home networks (where neither traffic nor CPU is likely to
> be an issue due to the small number of devices) and busy enterprise
> networks (office, dorm, coffee shop), which I assumed would be more
> powerful devices (laptops, phones, servers) where reducing traffic would be
> more important than the CPU usage for checking multicast probes.
>
> 4. One privacy concern regarding predictable nonces is that it would allow
> spoofing. Anyone with your public key could generate your predictable
> nonce. It could also enable friend relationships to be recovered. Maybe not
> a huge concern, but something to consider. Even the signature approach has
> a replay vulnerability, but it's time bounded.
>
> On Nov 14, 2018, at 5:37 PM, David Schinazi <dschinazi.ietf@gmail.com>
> wrote:
>
> Hello everyone,
>
> It the room at IETF 103, there was a very productive discussion about
> DNSSD privacy:
> https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s
>
> During that discussion, the room reached consensus on the following items:
>
> 1) single-stage approach -- Up until now, we were considering two
> approaches: single-stage (send encrypted and authenticated service
> identifier, receive encrypted and authenticated service response) and
> two-stage (send encryption and authenticated identifier, receive encrypted
> and authenticated response, derive secrets, send and receive subsequent
> queries encrypted using derived secrets). There was consensus in the room
> to go with the single-stage approach.
>
> 2) Use of TLS -- The single-stage approach no longer requires a key
> exchange mechanism such as TLS. There was consensus in the room that we do
> not need TLS as part of this protocol.
>
> 3) Evolution of documents -- It was proposed that we would take all input
> and compound it into a single document and only advance that one. We will
> use draft-ietf-dnssd-privacy since that document has already been adopted
> by the working group. Christian Huitema has offered for Bob Bradley to join
> as co-author if Bob would like.
>
> If you disagree with any of these points, please say so before 2018-12-02.
>
> Thanks,
> David
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd
>

--00000000000073f5a5057ab5a345
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Hm.=C2=A0 To your point #4, I guess the question is, how e=
asy is it for the public key to leak?=C2=A0 =C2=A0If you ever share your pu=
blic key with anyone, they can definitely spoof you, but what do they get o=
ut of that?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, No=
v 15, 2018 at 12:36 AM Bob Bradley &lt;<a href=3D"mailto:bradley@apple.com"=
>bradley@apple.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div style=3D"word-wrap:break-word;line-break:after-white-space">I&#39;m a l=
ittle unclear what is being considered single-stage vs two-stage. How is si=
ngle-stage able to send encrypted without knowing the destination? Is it en=
crypting a query with an asymmetric private key and multicasting? Or does s=
ingle-stage refer to the predictable nonce approach? I was considering=C2=
=A0predictable nonce&#39;s two-stage because it has to first discover known=
 peer service instances (stage 1) then perform encrypted queries/responses =
(stage 2).<div><br></div><div>Regarding the discussion:</div><div><br></div=
><div>1. Server mode. My proposal doesn&#39;t have a good way to support it=
. Normal server mode wasn&#39;t an important use case for me, but sleep pro=
xy support would be nice. I just don&#39;t know how to do it yet, at least =
not without giving the sleep proxy your keys.</div><div><br></div><div>2. M=
ulticast traffic. One problem I saw with=C2=A0draft-ietf-dnssd-privacy is e=
ach device advertising a service instance for each pairing. The network I&#=
39;m on now has 300+ devices and if each one has 50 friends, that&#39;s 150=
00 service instances on the network, which seems very high.</div><div><br><=
/div><div>I tried to reduce this by each device only advertising itself via=
 multicast and then everything else is unicast. The first part of key excha=
nge was also rolled into the advertisement packet to allow a single query p=
acket and single response packet while still maintaining forward secrecy an=
d per-pairing confidentiality.</div><div><br></div><div>3. CPU cost. This s=
eems to be a comparison between more packets, but lower per-packet cost (in=
 the per-pairing service instance model where predictable nonce hashes are =
precomputed) vs fewer packets, but more expensive per-packet signature veri=
fication. The two main use cases I was considering were home networks (wher=
e neither traffic nor CPU is likely to be an issue due to the small number =
of devices) and busy enterprise networks (office, dorm, coffee shop), which=
 I assumed would be more powerful devices (laptops, phones, servers) where =
reducing traffic would be more important than the CPU usage for checking mu=
lticast probes.</div><div><br></div><div>4. One privacy concern regarding p=
redictable nonces is that it would allow spoofing. Anyone with your public =
key could generate your predictable nonce. It could also enable friend rela=
tionships to be recovered. Maybe not a huge concern, but something to consi=
der. Even the signature approach has a replay vulnerability, but it&#39;s t=
ime bounded.</div><div><div><br><blockquote type=3D"cite"><div>On Nov 14, 2=
018, at 5:37 PM, David Schinazi &lt;<a href=3D"mailto:dschinazi.ietf@gmail.=
com" target=3D"_blank">dschinazi.ietf@gmail.com</a>&gt; wrote:</div><br cla=
ss=3D"m_-8504910381326129512Apple-interchange-newline"><div><div dir=3D"ltr=
"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr">Hello=
 everyone,<div><br></div><div>It the room at IETF 103, there was a very pro=
ductive discussion about DNSSD privacy:</div><div><a href=3D"https://www.yo=
utube.com/watch?v=3DhPuTD19R-uQ&amp;t=3D28m43s" target=3D"_blank">https://w=
ww.youtube.com/watch?v=3DhPuTD19R-uQ&amp;t=3D28m43s</a><br></div><div><br><=
/div><div>During that discussion, the room reached consensus on the followi=
ng items:</div><div><br></div><div>1) single-stage approach -- Up until now=
, we were considering two approaches: single-stage (send encrypted and auth=
enticated service identifier, receive encrypted and authenticated service r=
esponse) and two-stage (send encryption and authenticated identifier, recei=
ve encrypted and authenticated response, derive secrets, send and receive s=
ubsequent queries encrypted using derived secrets). There was consensus in =
the room to go with the single-stage approach.</div><div><br></div><div>2) =
Use of TLS -- The single-stage approach no longer requires a key exchange m=
echanism such as TLS. There was consensus in the room that we do not need T=
LS as part of this protocol.</div><div><br></div><div>3) Evolution of docum=
ents -- It was proposed that we would take all input and compound it into a=
 single document and only advance that one. We will use=C2=A0draft-ietf-dns=
sd-privacy since that document has already been adopted by the working grou=
p. Christian Huitema has offered for Bob Bradley to join as co-author if Bo=
b would like.</div><div><br></div><div>If you disagree with any of these po=
ints, please say so before 2018-12-02.</div><div><br></div><div>Thanks,</di=
v><div>David</div></div></div></div></div></div>
_______________________________________________<br>dnssd mailing list<br><a=
 href=3D"mailto:dnssd@ietf.org" target=3D"_blank">dnssd@ietf.org</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/dnssd" target=3D"_blank">http=
s://www.ietf.org/mailman/listinfo/dnssd</a><br></div></blockquote></div><br=
></div></div>_______________________________________________<br>
dnssd mailing list<br>
<a href=3D"mailto:dnssd@ietf.org" target=3D"_blank">dnssd@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dnssd" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/dnssd</a><br>
</blockquote></div>

--00000000000073f5a5057ab5a345--


From nobody Thu Nov 15 08:30:46 2018
Return-Path: <huitema@huitema.net>
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 AD5741292AD for <dnssd@ietfa.amsl.com>; Thu, 15 Nov 2018 08:30:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level: 
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lcgQGYS_0L6R for <dnssd@ietfa.amsl.com>; Thu, 15 Nov 2018 08:30:43 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC762130DE1 for <dnssd@ietf.org>; Thu, 15 Nov 2018 08:30:42 -0800 (PST)
Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx62.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gNKXQ-00047g-6V for dnssd@ietf.org; Thu, 15 Nov 2018 17:30:40 +0100
Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from <huitema@huitema.net>) id 1gNKXK-0004qG-M4 for dnssd@ietf.org; Thu, 15 Nov 2018 11:30:38 -0500
Received: (qmail 7405 invoked from network); 15 Nov 2018 16:30:33 -0000
Received: from unknown (HELO [IPv6:2607:fb90:836c:aa05:e03f:4829:fc25:4d0]) (Authenticated-user:_huitema@huitema.net@[172.58.43.61]) (envelope-sender <huitema@huitema.net>) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for <bradley@apple.com>; 15 Nov 2018 16:30:33 -0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (16A404)
In-Reply-To: <CAPt1N1nzbyMVDofO-FWmL3hxjZykE=5BWaL_+DkCCdcH4oPOEQ@mail.gmail.com>
Date: Thu, 15 Nov 2018 08:30:31 -0800
Cc: bradley@apple.com, dnssd <dnssd@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CEECCE89-A731-4F43-A6EA-B324B7CA77DC@huitema.net>
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com> <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <CAPt1N1nzbyMVDofO-FWmL3hxjZykE=5BWaL_+DkCCdcH4oPOEQ@mail.gmail.com>
To: Ted Lemon <mellon@fugue.com>
X-Originating-IP: 168.144.250.231
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 168.144.250.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: ham
X-Spampanel-Outgoing-Evidence: Combined (0.10)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5hsOtvXGg7KNKGnzr8fzmH9602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxB4rpaK5krXqQ/gh9fXK331Dj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5NAmFR3BiNNySzE1qhn3ItE5EpHPznVavQp4h 1cyzxbRC4xvs/7iGgDKhZ45D5vihvZAdx4vjUFLh0kXGIOazxFpgLxqZUFZdwbOLffZB9SIbeA2G NaAif0QyGEAJd8kel+zffa+S3paXsykGResyE7dAzbZabvf4+eAvvSn0D5YzxzA4C4+ILjmdkQoL 6F7cCSavQBrPoagEXfZ210Cx8bwqyT5p50x81ZKcmzCu2U1l0pLLr6Q2GfeLeJGF+80DrsibCyBr x+YtCB8oetqRijWKtLT9WR57oxUvRixjadcobnduoQv5Sp6y3SmK1n5SK/lIPtlUiBhTzlv5XU8Y E2iH1Wgh6RAenBR+licROGbTzrWUA+sbAUoZv9wXXmR3isORcpryIrvqgzC+pmbq4eUgo/ZWy3pj 0uZYebrt+pFk354Leo8WHhg9Xcph2esmZk4AVtnYApSiFQp1w3dnUoiPn/2xNqt6sQVacVXeY6AU 1zqm/evfkH8cHl25+qKdCD+gbtQwKEiK+sEGzrnReB2vWOKTBJk2Pbgs7SLYxsDFpBQv1zK8QU9Y HobaXmOqCkEQ8oYFKbt8UNi0w8ScjnG5BnVj6tDKYf18xfK0O5ginCj9cFe8Z26SFoAvsguRw6nI oDr0sXUZ7YZoZ/GZ+n9RWyexZMmEn1763rtN9kT6vvsamCqhsCKWQTQWW5aiOYN2LGYOY+RZZ70I EJvMPP9qwM7RXpJS8RjTdyh2j5BSM6Vge5/tyLofFHTUZzjpzRBCCyVCnQKBwcrUTMoPTDRj9D8H LKHAKpPGP8EPnuBvlPE9yn4+7R7hw716lUpV
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/Qb0v59_dY4_Mh9BXvLn6Czm_A98>
Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 16:30:45 -0000

> On Nov 15, 2018, at 7:23 AM, Ted Lemon <mellon@fugue.com> wrote:
>=20
> Hm.  To your point #4, I guess the question is, how easy is it for the pub=
lic key to leak?   If you ever share your public key with anyone, they can d=
efinitely spoof you, but what do they get out of that?

I am concerned that we are debating hypothetical designs here, pieces of the=
 original design with pieces of Bob's design. Everybody will have different i=
deas about the mix, and different worries. My goal is to work with Bob and D=
aniel and propose an actual design for evaluation.

Spoofing is indeed a concern, and so are replay attacks. The join design wil=
l have to address that.

-- Christian Huitema=20=


From nobody Thu Nov 15 08:32:15 2018
Return-Path: <bradley@apple.com>
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 828361292AD for <dnssd@ietfa.amsl.com>; Thu, 15 Nov 2018 08:32:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.47
X-Spam-Level: 
X-Spam-Status: No, score=-2.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Df2bNlLFiyTv for <dnssd@ietfa.amsl.com>; Thu, 15 Nov 2018 08:32:09 -0800 (PST)
Received: from ma1-aaemail-dr-lapp03.apple.com (ma1-aaemail-dr-lapp03.apple.com [17.171.2.72]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACEE6130DE1 for <dnssd@ietf.org>; Thu, 15 Nov 2018 08:32:09 -0800 (PST)
Received: from pps.filterd (ma1-aaemail-dr-lapp03.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp03.apple.com (8.16.0.22/8.16.0.22) with SMTP id wAFGVrUa018901; Thu, 15 Nov 2018 08:32:07 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=mime-version : content-type : sender : from : message-id : subject : date : in-reply-to : cc : to : references; s=20180706; bh=iUHiGnMgSeRD+shHOt0H8/z5Hl5T4UjCY8anIfosmWw=; b=mqtEXJ0W48XUrkF4ypxL2maW5Uo2TVw1A4BAsNwrufzyqZKmgeJ8bXkndj18rsVsKvZ1 F31F3GOUVWhzjEwFqNPxzHHDNb8D9Vob982AnAwTXiSSkUS/juj42Un/lHEODymc7GMk ErdfZ7uANZe0NQbAwrAXUtT5rsF3MUo1LAK+rGIqcD0VneR645ZYPIpqmDZQmytNIuot 7tjaItLyZbeUQXsard1jzimvxJqHnJlylEzXXlI90HXnogM0vqyxCza+0sHbFPannYmW kVPso1lnejkTNDsNA0hwYSghXwLz8rsC3Td/8LOlTPd7N9hneYkfxFLwpuwJ5+F9uLDz tQ== 
Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp03.apple.com with ESMTP id 2nr7bsfvr8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 15 Nov 2018 08:32:07 -0800
MIME-version: 1.0
Content-type: multipart/alternative; boundary="Boundary_(ID_aEP2HilGPZ0g0Gw2uL++4g)"
Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPS id <0PI800CMKTXHGL00@ma1-mtap-s01.corp.apple.com>; Thu, 15 Nov 2018 08:32:06 -0800 (PST)
Received: from process_viserion-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PI800C00TG7ID00@nwk-mmpp-sz13.apple.com>; Thu, 15 Nov 2018 08:32:06 -0800 (PST)
X-Va-A: 
X-Va-T-CD: a17ff691283ebf009da5140641b3832f
X-Va-E-CD: a4bee68cb9a28f988d727c8ecff39609
X-Va-R-CD: edf26e1a2599e7fb606d76b44a391aa1
X-Va-CD: 0
X-Va-ID: 8245b10d-ffab-442c-b037-fe65f57c5c72
X-V-A: 
X-V-T-CD: 926c12acc1b9dc6b65aaa75f7f2e2b1b
X-V-E-CD: a4bee68cb9a28f988d727c8ecff39609
X-V-R-CD: edf26e1a2599e7fb606d76b44a391aa1
X-V-CD: 0
X-V-ID: c65094bf-a104-468b-98e3-cdff5b6147e5
Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) id <0PI800K00TWXSV00@nwk-mmpp-sz13.apple.com>; Thu, 15 Nov 2018 08:32:06 -0800 (PST)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2018-11-15_12:,, signatures=0
Received: from [17.234.78.114] by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.3.20180614 64bit (built Jun 14 2018)) with ESMTPSA id <0PI8002AZTXHZQ10@nwk-mmpp-sz13.apple.com>; Thu, 15 Nov 2018 08:32:05 -0800 (PST)
Sender: bradley@apple.com
From: Bob Bradley <bradley@apple.com>
Message-id: <4880CD23-08E4-4907-B272-6F376AF6C4F7@apple.com>
Date: Thu, 15 Nov 2018 08:32:05 -0800
In-reply-to: <CAPt1N1nzbyMVDofO-FWmL3hxjZykE=5BWaL_+DkCCdcH4oPOEQ@mail.gmail.com>
Cc: dnssd <dnssd@ietf.org>
To: Ted Lemon <mellon@fugue.com>
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com> <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <CAPt1N1nzbyMVDofO-FWmL3hxjZykE=5BWaL_+DkCCdcH4oPOEQ@mail.gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-15_12:, , signatures=0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/eW1p6tFNL-PziiCVpEXQutmYmIk>
Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 16:32:13 -0000

--Boundary_(ID_aEP2HilGPZ0g0Gw2uL++4g)
Content-type: text/plain; CHARSET=US-ASCII
Content-transfer-encoding: 7BIT

I wasn't as concerned with public keys leaking. The case I was thinking of is people I've shared my key with being able to determine who else I've shared with. If they haven't mutually shared keys, they can only determine if someone you've shared with is present. For mutually shared keys, they can identify specific people you've shared with: "Wow, I didn't know Alice and I both shared with Eve". For location-based devices, such as a printer or coffee shop, it can reveal where you've been.

> On Nov 15, 2018, at 7:23 AM, Ted Lemon <mellon@fugue.com> wrote:
> 
> Hm.  To your point #4, I guess the question is, how easy is it for the public key to leak?   If you ever share your public key with anyone, they can definitely spoof you, but what do they get out of that?
> 
> On Thu, Nov 15, 2018 at 12:36 AM Bob Bradley <bradley@apple.com <mailto:bradley@apple.com>> wrote:
> I'm a little unclear what is being considered single-stage vs two-stage. How is single-stage able to send encrypted without knowing the destination? Is it encrypting a query with an asymmetric private key and multicasting? Or does single-stage refer to the predictable nonce approach? I was considering predictable nonce's two-stage because it has to first discover known peer service instances (stage 1) then perform encrypted queries/responses (stage 2).
> 
> Regarding the discussion:
> 
> 1. Server mode. My proposal doesn't have a good way to support it. Normal server mode wasn't an important use case for me, but sleep proxy support would be nice. I just don't know how to do it yet, at least not without giving the sleep proxy your keys.
> 
> 2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy is each device advertising a service instance for each pairing. The network I'm on now has 300+ devices and if each one has 50 friends, that's 15000 service instances on the network, which seems very high.
> 
> I tried to reduce this by each device only advertising itself via multicast and then everything else is unicast. The first part of key exchange was also rolled into the advertisement packet to allow a single query packet and single response packet while still maintaining forward secrecy and per-pairing confidentiality.
> 
> 3. CPU cost. This seems to be a comparison between more packets, but lower per-packet cost (in the per-pairing service instance model where predictable nonce hashes are precomputed) vs fewer packets, but more expensive per-packet signature verification. The two main use cases I was considering were home networks (where neither traffic nor CPU is likely to be an issue due to the small number of devices) and busy enterprise networks (office, dorm, coffee shop), which I assumed would be more powerful devices (laptops, phones, servers) where reducing traffic would be more important than the CPU usage for checking multicast probes.
> 
> 4. One privacy concern regarding predictable nonces is that it would allow spoofing. Anyone with your public key could generate your predictable nonce. It could also enable friend relationships to be recovered. Maybe not a huge concern, but something to consider. Even the signature approach has a replay vulnerability, but it's time bounded.
> 
>> On Nov 14, 2018, at 5:37 PM, David Schinazi <dschinazi.ietf@gmail.com <mailto:dschinazi.ietf@gmail.com>> wrote:
>> 
>> Hello everyone,
>> 
>> It the room at IETF 103, there was a very productive discussion about DNSSD privacy:
>> https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s <https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s>
>> 
>> During that discussion, the room reached consensus on the following items:
>> 
>> 1) single-stage approach -- Up until now, we were considering two approaches: single-stage (send encrypted and authenticated service identifier, receive encrypted and authenticated service response) and two-stage (send encryption and authenticated identifier, receive encrypted and authenticated response, derive secrets, send and receive subsequent queries encrypted using derived secrets). There was consensus in the room to go with the single-stage approach.
>> 
>> 2) Use of TLS -- The single-stage approach no longer requires a key exchange mechanism such as TLS. There was consensus in the room that we do not need TLS as part of this protocol.
>> 
>> 3) Evolution of documents -- It was proposed that we would take all input and compound it into a single document and only advance that one. We will use draft-ietf-dnssd-privacy since that document has already been adopted by the working group. Christian Huitema has offered for Bob Bradley to join as co-author if Bob would like.
>> 
>> If you disagree with any of these points, please say so before 2018-12-02.
>> 
>> Thanks,
>> David
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org <mailto:dnssd@ietf.org>
>> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org <mailto:dnssd@ietf.org>
> https://www.ietf.org/mailman/listinfo/dnssd <https://www.ietf.org/mailman/listinfo/dnssd>


--Boundary_(ID_aEP2HilGPZ0g0Gw2uL++4g)
Content-type: text/html; CHARSET=US-ASCII
Content-transfer-encoding: quoted-printable

<html><head><meta http-equiv=3D"Content-Type" content=3D"text/html; =
charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; line-break: after-white-space;" class=3D"">I =
wasn't as concerned with public keys leaking. The case I was thinking of =
is people I've shared my key with being able to determine who else I've =
shared with. If they haven't mutually shared keys, they can only =
determine if someone you've shared with is present. For mutually shared =
keys, they can identify specific people you've shared with: "Wow, I =
didn't know Alice and I both shared with Eve". For location-based =
devices, such as a printer or coffee shop, it can reveal where you've =
been.<br class=3D""><div><br class=3D""><blockquote type=3D"cite" =
class=3D""><div class=3D"">On Nov 15, 2018, at 7:23 AM, Ted Lemon &lt;<a =
href=3D"mailto:mellon@fugue.com" class=3D"">mellon@fugue.com</a>&gt; =
wrote:</div><br class=3D"Apple-interchange-newline"><div class=3D""><div =
dir=3D"ltr" class=3D"">Hm.&nbsp; To your point #4, I guess the question =
is, how easy is it for the public key to leak?&nbsp; &nbsp;If you ever =
share your public key with anyone, they can definitely spoof you, but =
what do they get out of that?</div><br class=3D""><div =
class=3D"gmail_quote"><div dir=3D"ltr" class=3D"">On Thu, Nov 15, 2018 =
at 12:36 AM Bob Bradley &lt;<a href=3D"mailto:bradley@apple.com" =
class=3D"">bradley@apple.com</a>&gt; wrote:<br =
class=3D""></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 =
.8ex;border-left:1px #ccc solid;padding-left:1ex"><div =
style=3D"word-wrap:break-word;line-break:after-white-space" class=3D"">I'm=
 a little unclear what is being considered single-stage vs two-stage. =
How is single-stage able to send encrypted without knowing the =
destination? Is it encrypting a query with an asymmetric private key and =
multicasting? Or does single-stage refer to the predictable nonce =
approach? I was considering&nbsp;predictable nonce's two-stage because =
it has to first discover known peer service instances (stage 1) then =
perform encrypted queries/responses (stage 2).<div class=3D""><br =
class=3D""></div><div class=3D"">Regarding the discussion:</div><div =
class=3D""><br class=3D""></div><div class=3D"">1. Server mode. My =
proposal doesn't have a good way to support it. Normal server mode =
wasn't an important use case for me, but sleep proxy support would be =
nice. I just don't know how to do it yet, at least not without giving =
the sleep proxy your keys.</div><div class=3D""><br class=3D""></div><div =
class=3D"">2. Multicast traffic. One problem I saw =
with&nbsp;draft-ietf-dnssd-privacy is each device advertising a service =
instance for each pairing. The network I'm on now has 300+ devices and =
if each one has 50 friends, that's 15000 service instances on the =
network, which seems very high.</div><div class=3D""><br =
class=3D""></div><div class=3D"">I tried to reduce this by each device =
only advertising itself via multicast and then everything else is =
unicast. The first part of key exchange was also rolled into the =
advertisement packet to allow a single query packet and single response =
packet while still maintaining forward secrecy and per-pairing =
confidentiality.</div><div class=3D""><br class=3D""></div><div =
class=3D"">3. CPU cost. This seems to be a comparison between more =
packets, but lower per-packet cost (in the per-pairing service instance =
model where predictable nonce hashes are precomputed) vs fewer packets, =
but more expensive per-packet signature verification. The two main use =
cases I was considering were home networks (where neither traffic nor =
CPU is likely to be an issue due to the small number of devices) and =
busy enterprise networks (office, dorm, coffee shop), which I assumed =
would be more powerful devices (laptops, phones, servers) where reducing =
traffic would be more important than the CPU usage for checking =
multicast probes.</div><div class=3D""><br class=3D""></div><div =
class=3D"">4. One privacy concern regarding predictable nonces is that =
it would allow spoofing. Anyone with your public key could generate your =
predictable nonce. It could also enable friend relationships to be =
recovered. Maybe not a huge concern, but something to consider. Even the =
signature approach has a replay vulnerability, but it's time =
bounded.</div><div class=3D""><div class=3D""><br class=3D""><blockquote =
type=3D"cite" class=3D""><div class=3D"">On Nov 14, 2018, at 5:37 PM, =
David Schinazi &lt;<a href=3D"mailto:dschinazi.ietf@gmail.com" =
target=3D"_blank" class=3D"">dschinazi.ietf@gmail.com</a>&gt; =
wrote:</div><br =
class=3D"m_-8504910381326129512Apple-interchange-newline"><div =
class=3D""><div dir=3D"ltr" class=3D""><div dir=3D"ltr" class=3D""><div =
dir=3D"ltr" class=3D""><div dir=3D"ltr" class=3D""><div dir=3D"ltr" =
class=3D"">Hello everyone,<div class=3D""><br class=3D""></div><div =
class=3D"">It the room at IETF 103, there was a very productive =
discussion about DNSSD privacy:</div><div class=3D""><a =
href=3D"https://www.youtube.com/watch?v=3DhPuTD19R-uQ&amp;t=3D28m43s" =
target=3D"_blank" =
class=3D"">https://www.youtube.com/watch?v=3DhPuTD19R-uQ&amp;t=3D28m43s</a=
><br class=3D""></div><div class=3D""><br class=3D""></div><div =
class=3D"">During that discussion, the room reached consensus on the =
following items:</div><div class=3D""><br class=3D""></div><div =
class=3D"">1) single-stage approach -- Up until now, we were considering =
two approaches: single-stage (send encrypted and authenticated service =
identifier, receive encrypted and authenticated service response) and =
two-stage (send encryption and authenticated identifier, receive =
encrypted and authenticated response, derive secrets, send and receive =
subsequent queries encrypted using derived secrets). There was consensus =
in the room to go with the single-stage approach.</div><div class=3D""><br=
 class=3D""></div><div class=3D"">2) Use of TLS -- The single-stage =
approach no longer requires a key exchange mechanism such as TLS. There =
was consensus in the room that we do not need TLS as part of this =
protocol.</div><div class=3D""><br class=3D""></div><div class=3D"">3) =
Evolution of documents -- It was proposed that we would take all input =
and compound it into a single document and only advance that one. We =
will use&nbsp;draft-ietf-dnssd-privacy since that document has already =
been adopted by the working group. Christian Huitema has offered for Bob =
Bradley to join as co-author if Bob would like.</div><div class=3D""><br =
class=3D""></div><div class=3D"">If you disagree with any of these =
points, please say so before 2018-12-02.</div><div class=3D""><br =
class=3D""></div><div class=3D"">Thanks,</div><div =
class=3D"">David</div></div></div></div></div></div>
_______________________________________________<br class=3D"">dnssd =
mailing list<br class=3D""><a href=3D"mailto:dnssd@ietf.org" =
target=3D"_blank" class=3D"">dnssd@ietf.org</a><br class=3D""><a =
href=3D"https://www.ietf.org/mailman/listinfo/dnssd" target=3D"_blank" =
class=3D"">https://www.ietf.org/mailman/listinfo/dnssd</a><br =
class=3D""></div></blockquote></div><br =
class=3D""></div></div>_______________________________________________<br =
class=3D"">
dnssd mailing list<br class=3D"">
<a href=3D"mailto:dnssd@ietf.org" target=3D"_blank" =
class=3D"">dnssd@ietf.org</a><br class=3D"">
<a href=3D"https://www.ietf.org/mailman/listinfo/dnssd" rel=3D"noreferrer"=
 target=3D"_blank" =
class=3D"">https://www.ietf.org/mailman/listinfo/dnssd</a><br class=3D"">
</blockquote></div>
</div></blockquote></div><br class=3D""></body></html>=

--Boundary_(ID_aEP2HilGPZ0g0Gw2uL++4g)--


From nobody Thu Nov 15 08:38:41 2018
Return-Path: <mellon@fugue.com>
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 2A074130E68 for <dnssd@ietfa.amsl.com>; Thu, 15 Nov 2018 08:38:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYWV_cj4XFqz for <dnssd@ietfa.amsl.com>; Thu, 15 Nov 2018 08:38:30 -0800 (PST)
Received: from mail-qk1-x733.google.com (mail-qk1-x733.google.com [IPv6:2607:f8b0:4864:20::733]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4EDBA130E58 for <dnssd@ietf.org>; Thu, 15 Nov 2018 08:38:30 -0800 (PST)
Received: by mail-qk1-x733.google.com with SMTP id m5so32747553qka.9 for <dnssd@ietf.org>; Thu, 15 Nov 2018 08:38:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aNOGUTyW3KrUkMfi0wDkjNKi1ax0uUqFvs1c1nfVjj4=; b=HCTW0dYqBY1j5gZfbctKkcwCnVbYug/1G4Ui7nnK3/jDKvGwpMtGDVbGH0HO3JMGrv rdtI1ztR9bQxTmRdm1HNWhmj5EXJPSq5Byy1BgiOA4NnqGjewSFBscsTF4/Wnj+IfEfl raE7zVz8CURil/FPXigwK7s2h+kmo2gtUYmLvvZajq8IaJURV9iPC+ZzmNnJImUreaMX RkAR7ZOWvOdqGduZBQvy9x6o5e1bNQvXFVBwyzGThE8aYyOzShJ6/QqNnwmwe6Z6ynbq 5CrI7RnWQa90ZTb6LBG6AurHv2O4rMmWO2B02mbk9jhEHNcF2bRzF/SEduWQ4f0lOyJc HlhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aNOGUTyW3KrUkMfi0wDkjNKi1ax0uUqFvs1c1nfVjj4=; b=gZ41qlaDWaGFbGjrpG/KgqEH5h1LtXuJXUTUpcJN93AyLlfldoPQICL6pQ2N73/0sE IYRwWqVmDgPODuUGDGXXOauQtZb2wqXJbKqqwc8Usop14DxnTE8bghHpNwxUEcN2PjOl XjbcrDnzdHDUYKttk5TBit8eS5CoRo35PKiRjecUN+YUWsYT3Kj9r38UOoSJd2w80Jo/ +rgP5/WPdWWbfeLm6UHfLRUAQ3sLOlP4Lx+uMCEmsYFgGXeIFJDeQSYSawjfJI634FOF b89/FDvpadpOQ/Si82VV5EyA+5PonsabW09zaAMBFvaKeUYk+0iFGXtCbrOAK4/HlTz5 T+Dw==
X-Gm-Message-State: AGRZ1gK27goCNi61wxIiJVJe3EnksRXJXgFrxoCtEYTOkeSiu2yYRn7D vwnmzmZQnPhMa7p5Z85RzYi2FxYbRwhuV0s7bTknVg==
X-Google-Smtp-Source: AJdET5dCura5kbS26wYClHU613GhwHeUEV45FZB7Hn6oCpsS16VFTxRUIa2qTzn8EMFexzxv/XMDyq2jgtOUU7x1yYU=
X-Received: by 2002:a0c:c966:: with SMTP id v35mr6947728qvj.45.1542299909135;  Thu, 15 Nov 2018 08:38:29 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com> <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <CAPt1N1nzbyMVDofO-FWmL3hxjZykE=5BWaL_+DkCCdcH4oPOEQ@mail.gmail.com> <4880CD23-08E4-4907-B272-6F376AF6C4F7@apple.com>
In-Reply-To: <4880CD23-08E4-4907-B272-6F376AF6C4F7@apple.com>
From: Ted Lemon <mellon@fugue.com>
Date: Thu, 15 Nov 2018 11:37:52 -0500
Message-ID: <CAPt1N1nq_o4sp8fsy3+j8hRkKdqLfbs_6ZK_F=RFYQi+usv=mQ@mail.gmail.com>
To: bradley@apple.com
Cc: dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000038b9e4057ab6ae4c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/c624n4-XdQ62_Jh1Dh4uYZaGfGY>
Subject: Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Nov 2018 16:38:41 -0000

--00000000000038b9e4057ab6ae4c
Content-Type: text/plain; charset="UTF-8"

Oh, right, if you share your public key with a printer, and it's the same
key you use with everyone else, then now in principle the printer can troll
for devices with which you've shared your key.

On Thu, Nov 15, 2018 at 11:32 AM Bob Bradley <bradley@apple.com> wrote:

> I wasn't as concerned with public keys leaking. The case I was thinking of
> is people I've shared my key with being able to determine who else I've
> shared with. If they haven't mutually shared keys, they can only determine
> if someone you've shared with is present. For mutually shared keys, they
> can identify specific people you've shared with: "Wow, I didn't know Alice
> and I both shared with Eve". For location-based devices, such as a printer
> or coffee shop, it can reveal where you've been.
>
> On Nov 15, 2018, at 7:23 AM, Ted Lemon <mellon@fugue.com> wrote:
>
> Hm.  To your point #4, I guess the question is, how easy is it for the
> public key to leak?   If you ever share your public key with anyone, they
> can definitely spoof you, but what do they get out of that?
>
> On Thu, Nov 15, 2018 at 12:36 AM Bob Bradley <bradley@apple.com> wrote:
>
>> I'm a little unclear what is being considered single-stage vs two-stage.
>> How is single-stage able to send encrypted without knowing the destination?
>> Is it encrypting a query with an asymmetric private key and multicasting?
>> Or does single-stage refer to the predictable nonce approach? I was
>> considering predictable nonce's two-stage because it has to first discover
>> known peer service instances (stage 1) then perform encrypted
>> queries/responses (stage 2).
>>
>> Regarding the discussion:
>>
>> 1. Server mode. My proposal doesn't have a good way to support it. Normal
>> server mode wasn't an important use case for me, but sleep proxy support
>> would be nice. I just don't know how to do it yet, at least not without
>> giving the sleep proxy your keys.
>>
>> 2. Multicast traffic. One problem I saw with draft-ietf-dnssd-privacy is
>> each device advertising a service instance for each pairing. The network
>> I'm on now has 300+ devices and if each one has 50 friends, that's 15000
>> service instances on the network, which seems very high.
>>
>> I tried to reduce this by each device only advertising itself via
>> multicast and then everything else is unicast. The first part of key
>> exchange was also rolled into the advertisement packet to allow a single
>> query packet and single response packet while still maintaining forward
>> secrecy and per-pairing confidentiality.
>>
>> 3. CPU cost. This seems to be a comparison between more packets, but
>> lower per-packet cost (in the per-pairing service instance model where
>> predictable nonce hashes are precomputed) vs fewer packets, but more
>> expensive per-packet signature verification. The two main use cases I was
>> considering were home networks (where neither traffic nor CPU is likely to
>> be an issue due to the small number of devices) and busy enterprise
>> networks (office, dorm, coffee shop), which I assumed would be more
>> powerful devices (laptops, phones, servers) where reducing traffic would be
>> more important than the CPU usage for checking multicast probes.
>>
>> 4. One privacy concern regarding predictable nonces is that it would
>> allow spoofing. Anyone with your public key could generate your predictable
>> nonce. It could also enable friend relationships to be recovered. Maybe not
>> a huge concern, but something to consider. Even the signature approach has
>> a replay vulnerability, but it's time bounded.
>>
>> On Nov 14, 2018, at 5:37 PM, David Schinazi <dschinazi.ietf@gmail.com>
>> wrote:
>>
>> Hello everyone,
>>
>> It the room at IETF 103, there was a very productive discussion about
>> DNSSD privacy:
>> https://www.youtube.com/watch?v=hPuTD19R-uQ&t=28m43s
>>
>> During that discussion, the room reached consensus on the following items:
>>
>> 1) single-stage approach -- Up until now, we were considering two
>> approaches: single-stage (send encrypted and authenticated service
>> identifier, receive encrypted and authenticated service response) and
>> two-stage (send encryption and authenticated identifier, receive encrypted
>> and authenticated response, derive secrets, send and receive subsequent
>> queries encrypted using derived secrets). There was consensus in the room
>> to go with the single-stage approach.
>>
>> 2) Use of TLS -- The single-stage approach no longer requires a key
>> exchange mechanism such as TLS. There was consensus in the room that we do
>> not need TLS as part of this protocol.
>>
>> 3) Evolution of documents -- It was proposed that we would take all input
>> and compound it into a single document and only advance that one. We will
>> use draft-ietf-dnssd-privacy since that document has already been adopted
>> by the working group. Christian Huitema has offered for Bob Bradley to join
>> as co-author if Bob would like.
>>
>> If you disagree with any of these points, please say so before 2018-12-02.
>>
>> Thanks,
>> David
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
>>
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
>>
>
>

--00000000000038b9e4057ab6ae4c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Oh, right, if you share your public key with a printer, an=
d it&#39;s the same key you use with everyone else, then now in principle t=
he printer can troll for devices with which you&#39;ve shared your key.</di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Nov 15, 2018 at 1=
1:32 AM Bob Bradley &lt;<a href=3D"mailto:bradley@apple.com">bradley@apple.=
com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"marg=
in:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style=3D"wo=
rd-wrap:break-word;line-break:after-white-space">I wasn&#39;t as concerned =
with public keys leaking. The case I was thinking of is people I&#39;ve sha=
red my key with being able to determine who else I&#39;ve shared with. If t=
hey haven&#39;t mutually shared keys, they can only determine if someone yo=
u&#39;ve shared with is present. For mutually shared keys, they can identif=
y specific people you&#39;ve shared with: &quot;Wow, I didn&#39;t know Alic=
e and I both shared with Eve&quot;. For location-based devices, such as a p=
rinter or coffee shop, it can reveal where you&#39;ve been.<br><div><br><bl=
ockquote type=3D"cite"><div>On Nov 15, 2018, at 7:23 AM, Ted Lemon &lt;<a h=
ref=3D"mailto:mellon@fugue.com" target=3D"_blank">mellon@fugue.com</a>&gt; =
wrote:</div><br class=3D"m_589220979565978788Apple-interchange-newline"><di=
v><div dir=3D"ltr">Hm.=C2=A0 To your point #4, I guess the question is, how=
 easy is it for the public key to leak?=C2=A0 =C2=A0If you ever share your =
public key with anyone, they can definitely spoof you, but what do they get=
 out of that?</div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, =
Nov 15, 2018 at 12:36 AM Bob Bradley &lt;<a href=3D"mailto:bradley@apple.co=
m" target=3D"_blank">bradley@apple.com</a>&gt; wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid=
;padding-left:1ex"><div style=3D"word-wrap:break-word;line-break:after-whit=
e-space">I&#39;m a little unclear what is being considered single-stage vs =
two-stage. How is single-stage able to send encrypted without knowing the d=
estination? Is it encrypting a query with an asymmetric private key and mul=
ticasting? Or does single-stage refer to the predictable nonce approach? I =
was considering=C2=A0predictable nonce&#39;s two-stage because it has to fi=
rst discover known peer service instances (stage 1) then perform encrypted =
queries/responses (stage 2).<div><br></div><div>Regarding the discussion:</=
div><div><br></div><div>1. Server mode. My proposal doesn&#39;t have a good=
 way to support it. Normal server mode wasn&#39;t an important use case for=
 me, but sleep proxy support would be nice. I just don&#39;t know how to do=
 it yet, at least not without giving the sleep proxy your keys.</div><div><=
br></div><div>2. Multicast traffic. One problem I saw with=C2=A0draft-ietf-=
dnssd-privacy is each device advertising a service instance for each pairin=
g. The network I&#39;m on now has 300+ devices and if each one has 50 frien=
ds, that&#39;s 15000 service instances on the network, which seems very hig=
h.</div><div><br></div><div>I tried to reduce this by each device only adve=
rtising itself via multicast and then everything else is unicast. The first=
 part of key exchange was also rolled into the advertisement packet to allo=
w a single query packet and single response packet while still maintaining =
forward secrecy and per-pairing confidentiality.</div><div><br></div><div>3=
. CPU cost. This seems to be a comparison between more packets, but lower p=
er-packet cost (in the per-pairing service instance model where predictable=
 nonce hashes are precomputed) vs fewer packets, but more expensive per-pac=
ket signature verification. The two main use cases I was considering were h=
ome networks (where neither traffic nor CPU is likely to be an issue due to=
 the small number of devices) and busy enterprise networks (office, dorm, c=
offee shop), which I assumed would be more powerful devices (laptops, phone=
s, servers) where reducing traffic would be more important than the CPU usa=
ge for checking multicast probes.</div><div><br></div><div>4. One privacy c=
oncern regarding predictable nonces is that it would allow spoofing. Anyone=
 with your public key could generate your predictable nonce. It could also =
enable friend relationships to be recovered. Maybe not a huge concern, but =
something to consider. Even the signature approach has a replay vulnerabili=
ty, but it&#39;s time bounded.</div><div><div><br><blockquote type=3D"cite"=
><div>On Nov 14, 2018, at 5:37 PM, David Schinazi &lt;<a href=3D"mailto:dsc=
hinazi.ietf@gmail.com" target=3D"_blank">dschinazi.ietf@gmail.com</a>&gt; w=
rote:</div><br class=3D"m_589220979565978788m_-8504910381326129512Apple-int=
erchange-newline"><div><div dir=3D"ltr"><div dir=3D"ltr"><div dir=3D"ltr"><=
div dir=3D"ltr"><div dir=3D"ltr">Hello everyone,<div><br></div><div>It the =
room at IETF 103, there was a very productive discussion about DNSSD privac=
y:</div><div><a href=3D"https://www.youtube.com/watch?v=3DhPuTD19R-uQ&amp;t=
=3D28m43s" target=3D"_blank">https://www.youtube.com/watch?v=3DhPuTD19R-uQ&=
amp;t=3D28m43s</a><br></div><div><br></div><div>During that discussion, the=
 room reached consensus on the following items:</div><div><br></div><div>1)=
 single-stage approach -- Up until now, we were considering two approaches:=
 single-stage (send encrypted and authenticated service identifier, receive=
 encrypted and authenticated service response) and two-stage (send encrypti=
on and authenticated identifier, receive encrypted and authenticated respon=
se, derive secrets, send and receive subsequent queries encrypted using der=
ived secrets). There was consensus in the room to go with the single-stage =
approach.</div><div><br></div><div>2) Use of TLS -- The single-stage approa=
ch no longer requires a key exchange mechanism such as TLS. There was conse=
nsus in the room that we do not need TLS as part of this protocol.</div><di=
v><br></div><div>3) Evolution of documents -- It was proposed that we would=
 take all input and compound it into a single document and only advance tha=
t one. We will use=C2=A0draft-ietf-dnssd-privacy since that document has al=
ready been adopted by the working group. Christian Huitema has offered for =
Bob Bradley to join as co-author if Bob would like.</div><div><br></div><di=
v>If you disagree with any of these points, please say so before 2018-12-02=
.</div><div><br></div><div>Thanks,</div><div>David</div></div></div></div><=
/div></div>
_______________________________________________<br>dnssd mailing list<br><a=
 href=3D"mailto:dnssd@ietf.org" target=3D"_blank">dnssd@ietf.org</a><br><a =
href=3D"https://www.ietf.org/mailman/listinfo/dnssd" target=3D"_blank">http=
s://www.ietf.org/mailman/listinfo/dnssd</a><br></div></blockquote></div><br=
></div></div>_______________________________________________<br>
dnssd mailing list<br>
<a href=3D"mailto:dnssd@ietf.org" target=3D"_blank">dnssd@ietf.org</a><br>
<a href=3D"https://www.ietf.org/mailman/listinfo/dnssd" rel=3D"noreferrer" =
target=3D"_blank">https://www.ietf.org/mailman/listinfo/dnssd</a><br>
</blockquote></div>
</div></blockquote></div><br></div></blockquote></div>

--00000000000038b9e4057ab6ae4c--


From nobody Mon Nov 19 01:08:24 2018
Return-Path: <prvs=8545e1d01=daniel.kaiser@uni.lu>
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 8F8CF12F1A5 for <dnssd@ietfa.amsl.com>; Mon, 19 Nov 2018 01:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level: 
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=uni.lu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uBmzZdHlg4QG for <dnssd@ietfa.amsl.com>; Mon, 19 Nov 2018 01:08:20 -0800 (PST)
Received: from smtp2.uni.lu (smtp2.uni.lu [IPv6:2001:a18:a:c5::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E719A12DDA3 for <dnssd@ietf.org>; Mon, 19 Nov 2018 01:08:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uni.lu; i=@uni.lu; q=dns/txt; s=DKIM; t=1542618500; x=1574154500; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=5zBKaSnXRXeFIW7ZOZgOWDu610LNE+55vkMiGLVvokc=; b=XG2dlioe8kECXUJZ3UD2yeU6XBvq6GGyw+4JlnhBz9QyTbeLfMSxqNAe uBw4P97UQo0R/JTdSH9O5slC0EkoZLb9Hqyqn8uT3kc2Q8YOBAdl2eoZY NDwXzpvsgzXHC+KJHSt1evUINqgcFCBS6d4jrZpPPQ1lK6nh/RAPBvxDL 580PSY+nC92V4wMNVcU4IbbmwLVWYYAj+SQ4kLhVVBySl+C1dps8SZ+eU IlU5H3XmxYkopCC42I8ud7nQw6TlTAz0i7xdLkGdfSPcx5mNu6/QanJk+ wVJVNu5TNuGTC2oyIXtQw9NIw6N7OuhdgbXD6k7HKdIBvM8B24aksUPC0 g==;
Authentication-Results: smtp2.uni.lu; spf=Fail smtp.mailfrom=daniel.kaiser@uni.lu; dkim=none (message not signed) header.i=none; dmarc=fail (p=none dis=none) d=uni.lu
X-IronPort-AV: E=Sophos; i="5.56,251,1539640800"; d="scan'208,217"; a="14081179"
References: <154239037781.554.2357809477417784979.idtracker@ietfa.amsl.com>
To: <dnssd@ietf.org>
From: Daniel KAISER <daniel.kaiser@uni.lu>
X-Forwarded-Message-Id: <154239037781.554.2357809477417784979.idtracker@ietfa.amsl.com>
Message-ID: <caf4708e-327a-72ff-e4d6-144d084d5483@uni.lu>
Date: Mon, 19 Nov 2018 10:08:15 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0
MIME-Version: 1.0
In-Reply-To: <154239037781.554.2357809477417784979.idtracker@ietfa.amsl.com>
Content-Type: multipart/alternative; boundary="------------1CFFE3CB8903786C042EED02"
Content-Language: en-US
X-Originating-IP: [10.240.10.17]
X-ClientProxiedBy: Tild2017.uni.lux (2001:a18:a:90::74) To lydia2017.uni.lux (2001:a18:a:90::83)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/PtEhcxOWGK05Ysn9nWmwxKFFdKQ>
Subject: [dnssd] Fwd: New Version Notification for draft-kaiser-dnssd-bloomfilter-hints-00.txt
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2018 09:08:23 -0000

--------------1CFFE3CB8903786C042EED02
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit

I just submitted an updated version of the Bloomfilter hinting method I 
described on the mailing list (11/07) as an Internet draft.
If you are interested, I would elaborate and publish a new version.

Kind regards,
Daniel


-------- Forwarded Message --------
Subject: 	New Version Notification for 
draft-kaiser-dnssd-bloomfilter-hints-00.txt
Date: 	Fri, 16 Nov 2018 09:46:17 -0800
From: 	internet-drafts@ietf.org
To: 	Daniel Kaiser <daniel.kaiser@uni.lu>




A new version of I-D, draft-kaiser-dnssd-bloomfilter-hints-00.txt
has been successfully submitted by Daniel Kaiser and posted to the
IETF repository.

Name: draft-kaiser-dnssd-bloomfilter-hints
Revision: 00
Title: Efficient Hinting for Privacy Preserving DNS-SD using Bloomfilters
Document date: 2018-11-16
Group: Individual Submission
Pages: 7
URL: 
https://www.ietf.org/internet-drafts/draft-kaiser-dnssd-bloomfilter-hints-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-kaiser-dnssd-bloomfilter-hints/
Htmlized: 
https://tools.ietf.org/html/draft-kaiser-dnssd-bloomfilter-hints-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-kaiser-dnssd-bloomfilter-hints


Abstract:
While DNS-SD over mDNS significantly improves the convenience of
network configuration, parts of the published information may
seriously breach the users' privacy. Currently discussed privacy
extensions either are not efficient in terms of multicast messages
sent, reduce privacy and complicate key revocation by introducing an
1:m pairing system, or use trial encryptions which are inefficient in
terms of necessary computational power.

The method proposed in this document leverages Bloomfilters to
significantly reduce the number of multicast (public) messages for a
DNS-SD privacy extension based on an 1:1 pairing mechanism. This
allows keeping the advantages of both an 1:1 pairing system and a
hinting system that does not require trial encryptions, while
mitigating the main disadvantage: multicast messages sent.



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

The IETF Secretariat


--------------1CFFE3CB8903786C042EED02
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: 7bit

<html>
  <head>

    <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    I just submitted an updated version of the Bloomfilter hinting
    method I described on the mailing list (11/07) as an Internet draft.<br>
    If you are interested, I would elaborate and publish a new version.<br>
    <br>
    Kind regards,<br>
    Daniel<br>
    <div class="moz-forward-container"><br>
      <br>
      -------- Forwarded Message --------
      <table class="moz-email-headers-table" cellspacing="0"
        cellpadding="0" border="0">
        <tbody>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">Subject:
            </th>
            <td>New Version Notification for
              draft-kaiser-dnssd-bloomfilter-hints-00.txt</td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">Date: </th>
            <td>Fri, 16 Nov 2018 09:46:17 -0800</td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">From: </th>
            <td><a class="moz-txt-link-abbreviated" href="mailto:internet-drafts@ietf.org">internet-drafts@ietf.org</a></td>
          </tr>
          <tr>
            <th valign="BASELINE" nowrap="nowrap" align="RIGHT">To: </th>
            <td>Daniel Kaiser <a class="moz-txt-link-rfc2396E" href="mailto:daniel.kaiser@uni.lu">&lt;daniel.kaiser@uni.lu&gt;</a></td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      <br>
      A new version of I-D, draft-kaiser-dnssd-bloomfilter-hints-00.txt<br>
      has been successfully submitted by Daniel Kaiser and posted to the<br>
      IETF repository.<br>
      <br>
      Name: draft-kaiser-dnssd-bloomfilter-hints<br>
      Revision: 00<br>
      Title: Efficient Hinting for Privacy Preserving DNS-SD using
      Bloomfilters<br>
      Document date: 2018-11-16<br>
      Group: Individual Submission<br>
      Pages: 7<br>
      URL:
<a class="moz-txt-link-freetext" href="https://www.ietf.org/internet-drafts/draft-kaiser-dnssd-bloomfilter-hints-00.txt">https://www.ietf.org/internet-drafts/draft-kaiser-dnssd-bloomfilter-hints-00.txt</a><br>
      Status:
      <a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/draft-kaiser-dnssd-bloomfilter-hints/">https://datatracker.ietf.org/doc/draft-kaiser-dnssd-bloomfilter-hints/</a><br>
      Htmlized:
      <a class="moz-txt-link-freetext" href="https://tools.ietf.org/html/draft-kaiser-dnssd-bloomfilter-hints-00">https://tools.ietf.org/html/draft-kaiser-dnssd-bloomfilter-hints-00</a><br>
      Htmlized:
<a class="moz-txt-link-freetext" href="https://datatracker.ietf.org/doc/html/draft-kaiser-dnssd-bloomfilter-hints">https://datatracker.ietf.org/doc/html/draft-kaiser-dnssd-bloomfilter-hints</a><br>
      <br>
      <br>
      Abstract:<br>
      While DNS-SD over mDNS significantly improves the convenience of<br>
      network configuration, parts of the published information may<br>
      seriously breach the users' privacy. Currently discussed privacy<br>
      extensions either are not efficient in terms of multicast messages<br>
      sent, reduce privacy and complicate key revocation by introducing
      an<br>
      1:m pairing system, or use trial encryptions which are inefficient
      in<br>
      terms of necessary computational power.<br>
      <br>
      The method proposed in this document leverages Bloomfilters to<br>
      significantly reduce the number of multicast (public) messages for
      a<br>
      DNS-SD privacy extension based on an 1:1 pairing mechanism. This<br>
      allows keeping the advantages of both an 1:1 pairing system and a<br>
      hinting system that does not require trial encryptions, while<br>
      mitigating the main disadvantage: multicast messages sent.<br>
      <br>
      <br>
      <br>
      Please note that it may take a couple of minutes from the time of
      submission<br>
      until the htmlized version and diff are available at
      tools.ietf.org.<br>
      <br>
      The IETF Secretariat<br>
      <br>
    </div>
  </body>
</html>

--------------1CFFE3CB8903786C042EED02--


From nobody Mon Nov 19 08:29:39 2018
Return-Path: <lear@cisco.com>
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 31B04128CF2; Sun, 18 Nov 2018 23:24:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level: 
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c0XNCqApfKpA; Sun, 18 Nov 2018 23:24:52 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A857A128CB7; Sun, 18 Nov 2018 23:24:50 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7782; q=dns/txt; s=iport; t=1542612291; x=1543821891; h=from:subject:to:cc:message-id:date:mime-version; bh=YYoxp5olme3K7siPXKcrnphj1YgllEj1Pg9APJPmCcw=; b=ZBDUgcXgKp9dm2h/4nSYP9HSL79V8xCf4ij8weva+EOEcBaQ1pCGtl0X Ld5Vtpjm6K4PVenhic9vDKqd7myp/Ekra7eewXG8OA0wWNLhFa/r+JPTA WwQf4Sd0vUU+3D66k8toFA0g24iKWYMMLWe18TZtgA31EBEoV9p6NyqjS k=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos;i="5.56,251,1539648000";  d="asc'?scan'208,217";a="8087374"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Nov 2018 07:24:48 +0000
Received: from [10.61.174.86] ([10.61.174.86]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id wAJ7OlJQ027437; Mon, 19 Nov 2018 07:24:47 GMT
From: Eliot Lear <lear@cisco.com>
Openpgp: preference=signencrypt
Autocrypt: addr=lear@cisco.com; prefer-encrypt=mutual; keydata= xsBNBFMe1UQBCADdYOS5APDpIpF2ohAxB+nxg1GpAYr8iKwGIb86Wp9NkK5+QwbW9H035clT lpVLciExtN8E3MCTPOIm7aITPlruixAVwlBY3g7U9eRppSw9O2H/7bie2GOnYxqmsw4v1yNZ 9NcMLlD8raY0UcQ5r698c8JD4xUTLqybZXaK2sPeJkxzT+IwupRSQ+vXEvFFGhERQ88zo5Ca Sa1Gw/Rv54oH0Dq2XYkO41rhxQ60BKZLZuQK1d9+1y3I+An3AJeD3AA31fJZD3H8YRKOBgqe ILPILbw1mM7gCtCjfvFCt6AFCwEsjITGx55ceoQ+t5B5XGYJEppMWsIFrwZsfbL+gP31ABEB AAHNJUVsaW90IExlYXIgPGxlYXJAb2Zjb3Vyc2VpbXJpZ2h0LmNvbT7CwJEEEwECADsCGwMC HgECF4ACGQEWIQSY0L2QRh2wkqeyYR2HtmtG2dJ6MwUCWxJwMwULCQgHAgYVCAkKCwIEFgID AQAKCRCHtmtG2dJ6MyMyCACXvtFjAYGMtOkD9MD4nI3ifFpkrj8xTMbXjrv5hdqmzRmQ0wqA 1U/OlZux+P/NaVMiZNZc8zw0nsx/INAqDOVd4/tLWF+ywTkeRFR0VnaUxLwCReZAZOaRS+md +52u/6ddoFja2RnjZ43qbbuvVUARQVIyMJz+GbR6mEZQHR0psD7dDYZDyrpivCxm8zHQwmB6 AZUlO7OJgljDvVPVDCabg/ZnJw1qS0OzSiNb0MySk1D5A7FdwDgeKxuMYUOOoVVTTMWNWcME UkRX9LxElswEt0PQWiz/j3FYXTxiFfl/1vKcHx4pM+E5C5mhTbrdFUFLJC3Y5fLID7stK/Ch aEaBzsBNBFMe1UQBCAC0WV7Ydbv95xYGPhthTdChBIpPtl7JPCV/c6/3iEmvjpfGuFNaK4Ma cj9le20EA5A1BH7PgLGoHOiPM65NysRpZ96RRVX3TNfLmhGMFr5hPOGNdq+xcGHVutmwPV9U 7bKeUNRiPFx3YdEkExddqV2E8FltT0x2FSKe2xszPPHB6gVtMckX5buI9p1K3fbVhXdvEkcY Y/jB0JEJGyhS5aEbct5cHUvDAkT81/YFK5Jfg8RRwu1q1t1YuIJSOWAZQ9J9oUsg6D9RpClU +tIFBoe3iTp1AUfJcypucGKgLYKtpu/aygcpQONHYkYW5003mPsrajFhReVF5veycMbHs4u5 ABEBAAHCwF8EGAECAAkFAlMe1UQCGwwACgkQh7ZrRtnSejOSuQgA27p2rYB7Kh20dym6V8c6 2pWpBHHTgxr/32zevxHSiXl6xvUCg5T8WUwfUk8OvgDcBErK/blDAMXQzSg3sp450JhR8RnX HXF5Zz2T04X7HnlIVJGwf2CjnwyEAJCqMzaCmI+g3Imvg/8L4nyBFvhlFHDv+kIvMiujyycj PAu7xxKplBs1/IEwmDoAMjneFmawvfeQnwdMhSKK8PjKSuzGU5uUmxj3GBfRqvTM0qpmhMPF OmDhJSmH55HLAky2MlmqJYXJPt/9EfSEhFiua1M6gLiuNEuPkp+8jcnHQqKr0IeHt8UqcwLt 2mGfIyl0FVdF9hvWPjNRzGbgqoT1Di03RQ==
To: iot-dir <iot-dir@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>, dnssd@ietf.org, Anima WG <anima@ietf.org>, 6tiisch@ietf.org, emu@ietf.org, dnssd@ietf.org
Cc: Christian Huitema <huitema@huitema.net>, Dave Thaler <dthaler@microsoft.com>, "Harkins, Daniel" <daniel.harkins@hpe.com>, "Jerome Henry (jerhenry)" <jerhenry@cisco.com>, Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Message-ID: <f500043e-91eb-5596-5b86-76f3f765bda0@cisco.com>
Date: Mon, 19 Nov 2018 08:24:46 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="u4zaMVbiLn4PvFfBFwrAMZzXdubFa2n3O"
X-Outbound-SMTP-Client: 10.61.174.86, [10.61.174.86]
X-Outbound-Node: aer-core-1.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/0tgYhwAsddqZkCbsgWpP82TW0gg>
X-Mailman-Approved-At: Mon, 19 Nov 2018 08:29:37 -0800
Subject: [dnssd] IoT Onboarding discussion summary from Bangkok
X-BeenThere: dnssd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." <dnssd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnssd>, <mailto:dnssd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnssd/>
List-Post: <mailto:dnssd@ietf.org>
List-Help: <mailto:dnssd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnssd>, <mailto:dnssd-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2018 07:24:54 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--u4zaMVbiLn4PvFfBFwrAMZzXdubFa2n3O
Content-Type: multipart/mixed; boundary="FKhIz4IiE3WOn9VfSKvDkKekFdCh8bjcX";
 protected-headers="v1"
From: Eliot Lear <lear@cisco.com>
To: iot-dir <iot-dir@ietf.org>, "opsawg@ietf.org" <opsawg@ietf.org>,
 dnssd@ietf.org, Anima WG <anima@ietf.org>, 6tiisch@ietf.org, emu@ietf.org,
 dnssd@ietf.org
Cc: Christian Huitema <huitema@huitema.net>,
 Dave Thaler <dthaler@microsoft.com>, "Harkins, Daniel"
 <daniel.harkins@hpe.com>, "Jerome Henry (jerhenry)" <jerhenry@cisco.com>,
 Hannes Tschofenig <Hannes.Tschofenig@gmx.net>
Message-ID: <f500043e-91eb-5596-5b86-76f3f765bda0@cisco.com>
Subject: IoT Onboarding discussion summary from Bangkok

--FKhIz4IiE3WOn9VfSKvDkKekFdCh8bjcX
Content-Type: multipart/alternative;
 boundary="------------799D27EF4EBC593D452E994C"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------799D27EF4EBC593D452E994C
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Dear Colleagues,

[Sorry for the wide distribution- on the other hand, please forward to
other interested parties ;-)]

Thanks to the 30 or so people who attended the side meeting on IoT
onboarding.=C2=A0 We had a pretty good discussion around the fact that th=
ere
is some fragmentation in the space that is confusing IoT developers.=C2=A0=

Some of this is due to the varying nature of devices and the varying
nature of deployments.=C2=A0 We focused a bit on 802.11, but not
exclusively.=C2=A0 We also discussed the relationship between "network
onboarding" and "application onboarding".

=46rom our discussions we agreed that it would be good to catalog all the=

various mechanisms that are available today, to attempt to identify
common architectural components, and to sort out the technical
requirements that these solutions need to address.=C2=A0 The intent was n=
ot
to limit this to either the IETF or IP (at least for now) but to capture
the whole field.=C2=A0 Also, non-standard mechanisms are welcome as well.=
=C2=A0
Later perhaps we can come up with at least a document to navigate when a
particular mechanism might be appropriate.

To this end, Suresh has been kind enough to create a mailing list =E2=80=93=

iot-onboarding@ietf.org =E2=80=93 for this purpose.=C2=A0 You can join th=
e mailing
list by going to https://www.ietf.org/mailman/listinfo/iot-onboarding.

In addition, I've created a github project that literally just catalogs
the stuff in the README.=C2=A0 ALL contributions are welcome.=C2=A0 Examp=
les of
mechanisms that we would like to document are DPP, ANIMA/BRSKI (in all
of its varieties), how BT and Zigbee function in this regard, OCF, etc.=C2=
=A0
The repository location can be found at
https://github.com/iot-onboarding/catalog.

We also agreed to checkpoint in December, before everyone disappears for
the holidays.=C2=A0 More information on this will be forthcoming.

To those who attended, did I miss anything?

Eliot


--------------799D27EF4EBC593D452E994C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<html>
  <head>

    <meta http-equiv=3D"content-type" content=3D"text/html; charset=3Dutf=
-8">
  </head>
  <body text=3D"#000000" bgcolor=3D"#FFFFFF">
    <p>Dear Colleagues,</p>
    <p>[Sorry for the wide distribution- on the other hand, please
      forward to other interested parties ;-)]<br>
    </p>
    <p>Thanks to the 30 or so people who attended the side meeting on
      IoT onboarding.=C2=A0 We had a pretty good discussion around the fa=
ct
      that there is some fragmentation in the space that is confusing
      IoT developers.=C2=A0 Some of this is due to the varying nature of
      devices and the varying nature of deployments.=C2=A0 We focused a b=
it
      on 802.11, but not exclusively.=C2=A0 We also discussed the
      relationship between "network onboarding" and "application
      onboarding".<br>
    </p>
    <p>From our discussions we agreed that it would be good to catalog
      all the various mechanisms that are available today, to attempt to
      identify common architectural components, and to sort out the
      technical requirements that these solutions need to address.=C2=A0 =
The
      intent was not to limit this to either the IETF or IP (at least
      for now) but to capture the whole field.=C2=A0 Also, non-standard
      mechanisms are welcome as well.=C2=A0 Later perhaps we can come up =
with
      at least a document to navigate when a particular mechanism might
      be appropriate.<br>
    </p>
    <p>To this end, Suresh has been kind enough to create a mailing list
      =E2=80=93 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto:iot-=
onboarding@ietf.org">iot-onboarding@ietf.org</a> =E2=80=93 for this purpo=
se.=C2=A0 You can join the
      mailing list by going to <span style=3D"caret-color: rgb(0, 0, 0);
        color: rgb(0, 0, 0); font-family: Helvetica; font-size: 14px;
        font-style: normal; font-variant-caps: normal; font-weight:
        normal; letter-spacing: normal; orphans: auto; text-align:
        start; text-indent: 0px; text-transform: none; white-space:
        normal; widows: auto; word-spacing: 0px;
        -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;
        text-decoration: none; display: inline !important; float: none;">=
<span
          class=3D"Apple-converted-space"></span></span><span
        style=3D"font-family: Helvetica; font-size: 14px; font-style:
        normal; font-variant-caps: normal; font-weight: normal;
        letter-spacing: normal; orphans: auto; text-align: start;
        text-indent: 0px; text-transform: none; white-space: normal;
        widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto;
        -webkit-text-stroke-width: 0px;"><a class=3D"moz-txt-link-freetex=
t" href=3D"https://www.ietf.org/mailman/listinfo/iot-onboarding">https://=
www.ietf.org/mailman/listinfo/iot-onboarding</a></span>.</p>
    <p>In addition, I've created a github project that literally just
      catalogs the stuff in the README.=C2=A0 ALL contributions are welco=
me.=C2=A0
      Examples of mechanisms that we would like to document are DPP,
      ANIMA/BRSKI (in all of its varieties), how BT and Zigbee function
      in this regard, OCF, etc.=C2=A0 The repository location can be foun=
d at
      <a class=3D"moz-txt-link-freetext" href=3D"https://github.com/iot-o=
nboarding/catalog">https://github.com/iot-onboarding/catalog</a>.</p>
    <p>We also agreed to checkpoint in December, before everyone
      disappears for the holidays.=C2=A0 More information on this will be=

      forthcoming.</p>
    <p>To those who attended, did I miss anything?</p>
    <p>Eliot<br>
    </p>
  </body>
</html>

--------------799D27EF4EBC593D452E994C--

--FKhIz4IiE3WOn9VfSKvDkKekFdCh8bjcX--

--u4zaMVbiLn4PvFfBFwrAMZzXdubFa2n3O
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlvyZT4ACgkQh7ZrRtnS
ejM8dgf+PInScJFF8yh8MFQLzOB2R+83vK75AzQj5bY8EGym0Z3NxZbhEfbugMdm
UCtpoXUPYYjjvenp+1NGpC0OuVLJ1EyVP7NW8zUhSPlt3gTOe/C2yLQBigwK5/2H
5PGVyUSPhMN+k053XW/rOOFbCY9VEDOOpy+iboIhj4rJVlh1Lx2uUyCXhR+dQhfv
1nKgYjR+WdTqLcorzOoKh3Rg6KLlEWWeH0GIF86jm8xfPDgyOzkflVuM6Wvvr0XQ
b2jQVvTUjvrwso9004RZE4UuUCeYqbRF26tXQl+waTkaxUKuO/cyKfWVUZ63KsCZ
jWKyxZTi9RR5NYvmeV7f/ab7IjrXWQ==
=U8oM
-----END PGP SIGNATURE-----

--u4zaMVbiLn4PvFfBFwrAMZzXdubFa2n3O--

