From nobody Sat Jun 17 12:48:59 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 661121293E0; Sat, 17 Jun 2017 12:48:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dnssd@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149772893037.14384.15310739786731524782@ietfa.amsl.com> Date: Sat, 17 Jun 2017 12:48:50 -0700 Archived-At: Subject: [dnssd] I-D Action: draft-ietf-dnssd-push-11.txt X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 Jun 2017 19:48:50 -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 of the IETF. Title : DNS Push Notifications Authors : Tom Pusateri Stuart Cheshire Filename : draft-ietf-dnssd-push-11.txt Pages : 40 Date : 2017-06-17 Abstract: The Domain Name System (DNS) was designed to return matching records efficiently for queries for data that is relatively static. When those records change frequently, DNS is still efficient at returning the updated results when polled. 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-11 https://datatracker.ietf.org/doc/html/draft-ietf-dnssd-push-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnssd-push-11 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 Mon Jun 19 07:16:11 2017 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D551314CE for ; Mon, 19 Jun 2017 07:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jc82HLsBJRp2 for ; Mon, 19 Jun 2017 07:16:08 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD2FA1314BA for ; Mon, 19 Jun 2017 07:16:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1497881765; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding; bh=ykhD/+RLuF7nUii0ingyemb5SzSfmlaQ3wE2UO1/ZHo=; b=AyAMtS0b/zjg3lm3/tahlqs18bfzWLK4PlypjGWpBBhWW0w8vQJOYUWBeaxENhsQogz4sD5Z9Pn8zTe5TM8a08B6ghCkQV9kJx7O3ZDa8lyfxKebI0c6Cpy7E6IfAPDeVWVx8uxx9kyBLb9QijeKSwlnPvHa2499moFSbGI6mds= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0246.outbound.protection.outlook.com [213.199.154.246]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-15-QUKChG2qNTWqvzZ-q7k9ew-1; Mon, 19 Jun 2017 15:16:03 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB276.eurprd07.prod.outlook.com (10.242.18.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Mon, 19 Jun 2017 14:16:02 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::a0d2:23ea:f4eb:e7bd]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::a0d2:23ea:f4eb:e7bd%14]) with mapi id 15.01.1199.007; Mon, 19 Jun 2017 14:16:02 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: IETF99 meeting - request for agenda items Thread-Index: AQHS6QaUZV0qojlykUiYZH/6ekXdtw== Date: Mon, 19 Jun 2017 14:16:01 +0000 Message-ID: <343386BB-2AE9-421D-8036-36D44CAA0E6F@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:6cd5:a29d:c68c:4bf9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB276; 20:U72JU42BG3dVbIm0sWoyDVR3k42HHab8ECFsYrkVFOpdHXkJGOeAWyLsySGKMeEYl77iVzdZH8ZQjIf7Pfcr0XcrrTLoCcHoFOePmd6OyGTApWlndiAj2R0vx79n41Oq089vU3oQXjqhe/2MDs7Vtf7iqvGTETvp+Tdh4eC981c= x-ms-office365-filtering-correlation-id: 545680bf-01c8-4d6c-ccb9-08d4b71db71b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500041)(300135000095)(300000501041)(300135300095)(22001)(300000502041)(300135100095)(2017030254075)(300000503041)(300135400095)(201703131423075)(201703031133081)(300000504041)(300135200095)(300000505041)(300135600095)(300000506037)(300135500095); SRVR:AM3PR07MB276; x-ms-traffictypediagnostic: AM3PR07MB276: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB276; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB276; x-forefront-prvs: 0343AC1D30 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(39400400002)(39410400002)(39450400003)(39840400002)(189998001)(5640700003)(6116002)(102836003)(2351001)(6506006)(6436002)(36756003)(50986999)(53936002)(2900100001)(305945005)(38730400002)(5660300001)(99286003)(110136004)(6512007)(8936002)(1730700003)(8676002)(14454004)(81166006)(50226002)(82746002)(5250100002)(86362001)(2501003)(72206003)(478600001)(25786009)(7736002)(57306001)(3280700002)(2906002)(33656002)(6916009)(42882006)(6486002)(83716003)(74482002)(3660700001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB276; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <56F4AB4E971ED74DA539065741FF5058@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2017 14:16:01.9600 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB276 X-MC-Unique: QUKChG2qNTWqvzZ-q7k9ew-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [dnssd] IETF99 meeting - request for agenda items X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 14:16:10 -0000 Hi, We currently have a two-hour slot for dnssd in Prague at 9:30am on Friday 2= 1st July. Note that this slot *might* change to earlier in the week. If you have material you would like considered for the agenda, please let R= alph and I know. We will also be approaching authors of existing drafts dir= ectly. Best wishes, Tim=20 From nobody Mon Jun 19 07:22:20 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DCF521314CA; Mon, 19 Jun 2017 07:22:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.55.0 Auto-Submitted: auto-generated Precedence: bulk Cc: The IESG , dnssd-chairs@ietf.org, dnssd@ietf.org, draft-ietf-dnssd-mdns-dns-interop@ietf.org, suzworldwide@gmail.com, Suzanne Woolf , rfc-editor@rfc-editor.org, terry.manderson@icann.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <149788213789.10806.147145300945697348.idtracker@ietfa.amsl.com> Date: Mon, 19 Jun 2017 07:22:17 -0700 Archived-At: Subject: [dnssd] Document Action: 'On Interoperation of Labels Among Conventional DNS and Other Resolution Systems' to Informational RFC (draft-ietf-dnssd-mdns-dns-interop-04.txt) X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 14:22:18 -0000 The IESG has approved the following document: - 'On Interoperation of Labels Among Conventional DNS and Other Resolution Systems' (draft-ietf-dnssd-mdns-dns-interop-04.txt) as Informational RFC This document is the product of the Extensions for Scalable DNS Service Discovery Working Group. The IESG contact persons are Suresh Krishnan and Terry Manderson. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dnssd-mdns-dns-interop/ Technical Summary Despite its name, DNS-Based Service Discovery can use naming systems other than the Domain Name System when looking for services. Moreover, when it uses the DNS, DNS-Based Service Discovery uses the full capability of DNS, rather than using a subset of available octets. In order for DNS-SD to be used effectively in environments where multiple different name systems and conventions for their operation are in use, it is important to attend to differences in the underlying technology and operational environment. This memo presents an outline of the requirements for selection of labels for conventional DNS and other resolution systems when they are expected to interoperate in this manner. Working Group Summary Early in the life of the draft there was extensive discussion (with a very few people supplying most of the bits) on clarifying the scope of the draft and sometimes-diverging terminology, since DNS operators and implementers think of interoperability issues between name resolution protocols differently than operators and implementers of mDNS or other such protocols. Those confusions appear to have been resolved in the final draft. The primary difference between the individual -00 version and the current one is extensive explanatory text on the nature of the problem being addressed and some of those divergent uses of terminology. Document Quality This document is intended as advice to implementers, to promote interoperability among multiple protocols. Review in DNSOP was requested, as it discusses operational conventions about the public DNS. Personnel Shepherd: Suzanne Woolf AD: Terry Manderson From nobody Mon Jun 19 07:24:47 2017 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EFF41314E5 for ; Mon, 19 Jun 2017 07:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3AN_pF3pIfJ for ; Mon, 19 Jun 2017 07:24:43 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [146.101.78.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FAA81314E6 for ; Mon, 19 Jun 2017 07:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1497882279; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding; bh=KuJukOdiiIwz1eiznmueCRAj5Yuj0IkkxqGIOWaq7os=; b=GWQPp5gwNTDGV1XTEkrMMVjjInWRMFWTqCG+CGLpGaiLzZOuv4GDjnGelJlKEWUtIwWHrJGlLh7fFyhPvP1wSRMEfDrNT2m8fOvs1/jQMfkME27xSLo/57d3cmHzpKt9UVK7zjeQT5xvSYFEbvKhWxxNidlnLCMiU5sRpJMO6Sk= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0211.outbound.protection.outlook.com [213.199.154.211]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-17-UDm9ywvsMfuVlntpWDlK8g-1; Mon, 19 Jun 2017 15:24:37 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB1169.eurprd07.prod.outlook.com (10.163.188.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.6; Mon, 19 Jun 2017 14:24:36 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::a0d2:23ea:f4eb:e7bd]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::a0d2:23ea:f4eb:e7bd%14]) with mapi id 15.01.1199.007; Mon, 19 Jun 2017 14:24:36 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: WGLC on draft-ietf-dnssd-privacy-01 Thread-Index: AQHS6QfH4LMQ51ou6kuSHjpewEh1LA== Date: Mon, 19 Jun 2017 14:24:36 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:6cd5:a29d:c68c:4bf9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB1169; 20:oSnMfAtiLUTM6NzPqXwCMOYNV6K0Hd7ONDTI26WUPfWCQim8lEdhyDF6iDi3PpBBQpDTffcDmKz/3s+37l6omZm6MRLzviqHBg5+aHJ/Ry14hoNoXxfnnpqekKhUsWy2UUYxhj5rt9vhImaqwfAnvRUHwlmuAW6nNiZWpoFcKCw= x-ms-office365-filtering-correlation-id: c2bc1115-9ef4-46c5-bedc-08d4b71ee999 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500041)(300135000095)(300000501041)(300135300095)(22001)(300000502041)(300135100095)(2017030254075)(300000503041)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504041)(300135200095)(300000505041)(300135600095)(300000506037)(300135500095); SRVR:AM3PR07MB1169; x-ms-traffictypediagnostic: AM3PR07MB1169: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB1169; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB1169; x-forefront-prvs: 0343AC1D30 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39450400003)(39400400002)(39840400002)(39410400002)(42882006)(2501003)(6436002)(8676002)(25786009)(81166006)(1730700003)(53936002)(99286003)(6306002)(6512007)(5640700003)(7736002)(38730400002)(110136004)(6486002)(6506006)(50986999)(189998001)(2900100001)(57306001)(33656002)(2351001)(102836003)(74482002)(230783001)(478600001)(72206003)(6116002)(966005)(2906002)(14454004)(50226002)(305945005)(8936002)(36756003)(3280700002)(5660300001)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB1169; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <39EF3A2D08C3CA4DA9816D9A6B9651CD@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jun 2017 14:24:36.1057 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB1169 X-MC-Unique: UDm9ywvsMfuVlntpWDlK8g-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [dnssd] WGLC on draft-ietf-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jun 2017 14:24:46 -0000 Dear dnssd WG participants, We are initiating a WG Last Call today on draft-ietf-dnssd-privacy-01, as c= an be found at https://tools.ietf.org/html/draft-ietf-dnssd-privacy-01 The call will close on Friday 7th July, giving us a week to review the outc= ome ahead of the Prague meeting. Please send any comments, including indications of support for progression = of the document as is, to the dnssd@ietf.org list. We intend to open a WGLC on the related pairing draft soon (draft-ietf-dnss= d-pairing-01), but we believe an update will be published first.=20 Abstract DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, a serious privacy problem arises. We propose to solve this problem by a two-stage approach. In the first stage, hosts discover Private Discovery Service Instances via DNS-SD using special formats to protect their privacy. These service instances correspond to Private Discovery Servers running on peers. In the second stage, hosts directly query these Private Discovery Servers via DNS-SD over TLS. A pairwise shared secret necessary to establish these connections is only known to hosts authorized by a pairing system. Thanks, Ralph and Tim dnssd WG co-chairs From nobody Fri Jun 23 17:15:17 2017 Return-Path: X-Original-To: dnssd@ietf.org Delivered-To: dnssd@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A883E12EB47; Fri, 23 Jun 2017 17:07:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: dnssd@ietf.org, terry.manderson@icann.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283268.7840.12473020388003889120.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:12 -0700 Archived-At: Subject: [dnssd] dnssd - Requested session has been scheduled for IETF 99 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jun 2017 00:07:15 -0000 Dear Tim Chown, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dnssd Session 1 (2:00:00) Wednesday, Afternoon Session II 1520-1650 Room Name: Athens/Barcelona size: 100 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Extensions for Scalable DNS Service Discovery Area Name: Internet Area Session Requester: Tim Chown Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: intarea 6lo dprive homenet dnsop 6man saag Second Priority: dhc v6ops People who must be present: Ralph Droms Tim Chown Terry Manderson Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sun Jun 25 14:08:17 2017 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30ABC1243FE for ; Sun, 25 Jun 2017 14:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 bMVxsV9cJWJv for ; Sun, 25 Jun 2017 14:08:12 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 418E01200CF for ; Sun, 25 Jun 2017 14:08:12 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id E611E31D29; Sun, 25 Jun 2017 23:08:06 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id 14169190C3E; Sun, 25 Jun 2017 23:07:10 +0200 (CEST) Date: Sun, 25 Jun 2017 23:07:10 +0200 From: Stephane Bortzmeyer To: Tim Chown Cc: "dnssd@ietf.org" Message-ID: <20170625210709.GA829@sources.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.8 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jun 2017 21:08:15 -0000 On Mon, Jun 19, 2017 at 02:24:36PM +0000, Tim Chown wrote a message of 38 lines which said: > We are initiating a WG Last Call today on > draft-ietf-dnssd-privacy-01, as can be found at > https://tools.ietf.org/html/draft-ietf-dnssd-privacy-01 Read it and it seems OK to me. But I see one technical weakness, and two things that I find puzzling. In section 3.2.2, if I understand correctly the proposal for a predictable nonce, it seems to me it has a weakness: end-users machines do not always have proper clock synchronisation (see also 5.5 which mentions it, for an unrelated issue). True, taking only the first 24 bits of the time will help (some machines with different clocks will nevertheless end in the same time interval), but it is not sufficient if bad luck makes two machines fall in different intervals. In section 2.4 "There is however an argument that devices providing services can be discovered by observing the local traffic" Another weakness of this argument is not mentioned: mDNS is multicasted so anyone can listen, eve on a switched network. Local traffic isn't. In section 3.4, "Host names are typically not visible by the users, and randomizing host names will probably not cause much usability issues." Is it always true? It seems to me several discovery protocols (over Bluetooth for instance) display the host name to the end user. From nobody Mon Jun 26 03:04:25 2017 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F0E129AC6 for ; Mon, 26 Jun 2017 03:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szhONqhs4t-T for ; Mon, 26 Jun 2017 03:04:11 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FB29129ABD for ; Mon, 26 Jun 2017 03:04:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1498471448; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding:in-reply-to:references; bh=hmMd5cbG1BdZrMNr/7mSl2a4dcuXXe2f0gS32pGoQ5k=; b=W+FLn1n6iD17dCynbsCbVK/sBlQz2aB2KPAJV5LzyIEXt3H5nFopWjFvFyRsVFJsv1ZRTpNRCxpaBv63jmlqPgRzKqma1yzhfglEwpEZdx8QjQcFNjBue2NqYKG/78EFUE3UZ7Sb3qJlNZfbwRzXVAaAorSLtfEO6vGhHtnJVnQ= Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01lp0208.outbound.protection.outlook.com [213.199.154.208]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-26-WirW7zlwMBKBd9t7GKJhiw-1; Mon, 26 Jun 2017 11:04:05 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB0536.eurprd07.prod.outlook.com (10.141.47.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Mon, 26 Jun 2017 10:04:04 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e900:f005:6fa:29aa]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e900:f005:6fa:29aa%14]) with mapi id 15.01.1220.010; Mon, 26 Jun 2017 10:04:04 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: dnssd - Requested session has been scheduled for IETF 99 Thread-Index: AQHS7H33WGH9ZsGzl0axqhNHBMXVqqI27heA Date: Mon, 26 Jun 2017 10:04:03 +0000 Message-ID: References: <149826283268.7840.12473020388003889120.idtracker@ietfa.amsl.com> In-Reply-To: <149826283268.7840.12473020388003889120.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:ed00:af5b:4b69:c909] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0536; 20:gjGP3m9acfPfJUgj4ovAYCitzV+TQK4MWqQqtpFSpA+WKGsAIAtWY5d3VRQpgWIPRBBepfhwYDl/Zr1lJq7rRLyEYB9358UGaqSzOmGUs2rq+aTAunyFeJktKtXUz4L838pYTZuOlmUcZ92VcRnAhSxx6sjn6DmB67OiaEXso5A= x-ms-office365-filtering-correlation-id: 6319e8ec-5b35-4411-0c1d-08d4bc7aacf9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(201703131423075)(201703031133081)(300000504095)(300135200095)(300000505095)(300135600095); SRVR:AM3PR07MB0536; x-ms-traffictypediagnostic: AM3PR07MB0536: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228)(148574349560750)(92977632026198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0536; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0536; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39840400002)(39450400003)(24454002)(6246003)(6436002)(8676002)(8936002)(1730700003)(36756003)(82746002)(6512007)(2351001)(189998001)(74482002)(57306001)(6506006)(53936002)(229853002)(38730400002)(110136004)(42882006)(2950100002)(6916009)(6486002)(7736002)(50226002)(5660300001)(99286003)(2900100001)(81166006)(305945005)(83716003)(2501003)(102836003)(6116002)(86362001)(14454004)(50986999)(72206003)(25786009)(76176999)(33656002)(2906002)(3660700001)(53546010)(478600001)(3280700002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0536; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: <5C3519A5B8497B4DA10C5234CF48EDAB@eurprd07.prod.outlook.com> MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Jun 2017 10:04:03.9336 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0536 X-MC-Unique: WirW7zlwMBKBd9t7GKJhiw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [dnssd] dnssd - Requested session has been scheduled for IETF 99 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 10:04:17 -0000 Hi, The dnssd WG session has been moved from Friday to Wednesday afternoon. We have 90 minutes to discuss ongoing work (the DNS privacy and pairing wor= k; please do comment on the WGLC of the privacy draft) plus new items from = Ted and Stuart. If there are other requests for agenda time, please let the chairs know. Best wishes,=20 Tim=20 > On 24 Jun 2017, at 01:07, IETF Secretariat wrote: >=20 > Dear Tim Chown, >=20 > The session(s) that you have requested have been scheduled. > Below is the scheduled session information followed by > the original request.=20 >=20 > dnssd Session 1 (2:00:00) > Wednesday, Afternoon Session II 1520-1650 > Room Name: Athens/Barcelona size: 100 > --------------------------------------------- >=20 >=20 >=20 > Request Information: >=20 >=20 > --------------------------------------------------------- > Working Group Name: Extensions for Scalable DNS Service Discovery=20 > Area Name: Internet Area > Session Requester: Tim Chown >=20 > Number of Sessions: 1 > Length of Session(s): 2 Hours > Number of Attendees: 60 > Conflicts to Avoid:=20 > First Priority: intarea 6lo dprive homenet dnsop 6man saag > Second Priority: dhc v6ops >=20 >=20 >=20 > People who must be present: > Ralph Droms > Tim Chown > Terry Manderson >=20 > Resources Requested: >=20 > Special Requests: >=20 > --------------------------------------------------------- >=20 From nobody Mon Jun 26 07:18:30 2017 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 088FE12EA55 for ; Mon, 26 Jun 2017 07:18:29 -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 O3vB_zW0xe0x for ; Mon, 26 Jun 2017 07:18:27 -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 DF6F0129B91 for ; Mon, 26 Jun 2017 07:18:26 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dPUqO-0006Zv-49 for dnssd@ietf.org; Mon, 26 Jun 2017 16:18:25 +0200 Received: from [10.5.2.15] (helo=xmail05.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dPUqI-0000at-Tp for dnssd@ietf.org; Mon, 26 Jun 2017 10:18:22 -0400 Received: (qmail 16461 invoked from network); 26 Jun 2017 14:18:16 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.244]) (envelope-sender ) by xmail05.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Jun 2017 14:18:16 -0000 To: dnssd@ietf.org References: <20170625210709.GA829@sources.org> From: Christian Huitema Message-ID: <28c0ad99-2905-64b6-52c2-a357e7fa6d12@huitema.net> Date: Mon, 26 Jun 2017 07:18:19 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170625210709.GA829@sources.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.33) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYoNzrMVvavOgy+9M5kGys4ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23m1GrkYo/0Y92Y6E22NNnpuoI9GlgXFbGvhvB 71hlmrqRz3KkGpwt7JVVRkGXTRxiYOEkjsX7F8KmpUaZQHV+ScWIfGf9Fu8q9UhMPe0GR5O2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpKs+iZ7+uSas6Kaz0EAgJQD6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyZtV8+oD7aoVwvnjslfJzo/eNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj234Kahp30YSTh5OL3yMqjF0jNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxiSsoNTiR/GmpPv4QzJ0uLs078I0y+3uS4dN KiUgYTBUyJWZ26+gPs1bzv8LK3hJrYAbiteDwjw8P7mx/NBHSRWxZaHLvUGmD7PXY2RS8idsz7fr MHsNPRylYAkPvY1HttQOF909qtkcRbvucYBIc/SWdEVhFWVNeXUVBER+dDF8MLn6MURQGfriekzS 9Ga3AA== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 14:18:29 -0000 On 6/25/2017 2:07 PM, Stephane Bortzmeyer wrote: > On Mon, Jun 19, 2017 at 02:24:36PM +0000, > Tim Chown wrote=20 > a message of 38 lines which said: > >> We are initiating a WG Last Call today on >> draft-ietf-dnssd-privacy-01, as can be found at >> https://tools.ietf.org/html/draft-ietf-dnssd-privacy-01 > Read it and it seems OK to me. But I see one technical weakness, and > two things that I find puzzling. Thanks for the review. > In section 3.2.2, if I understand correctly the proposal for a > predictable nonce, it seems to me it has a weakness: end-users > machines do not always have proper clock synchronisation (see also 5.5 > which mentions it, for an unrelated issue). True, taking only the > first 24 bits of the time will help (some machines with different > clocks will nevertheless end in the same time interval), but it is not > sufficient if bad luck makes two machines fall in different intervals. True. The solution requires that the participating devices have "good enough" clocks -- to the minute, in practice. It is clearly a trade off between usability and performance, and also resistance to DOS. The initial design had unconstrained nonce instead. The problem with unconstrained nonce is that they cannot be pre-computed by the peer, which open the possibility of a DOS attack: creates many nonces, and force the peer to compute as many hashes. Besides, nonces have a weakness too -- end-user machines do not always have proper sources of randomness. So in practice we require end users machines to have some sense of time. Maybe we should be more upfront about that. > In section 2.4 "There is however an argument that devices providing > services can be discovered by observing the local traffic" Another > weakness of this argument is not mentioned: mDNS is multicasted so > anyone can listen, eve on a switched network. Local traffic isn't. Good point. Will fix that text. > In section 3.4, "Host names are typically not visible by the users, > and randomizing host names will probably not cause much usability > issues." Is it always true? It seems to me several discovery protocols > (over Bluetooth for instance) display the host name to the end user. In DNS-SD, host names are not meant to be visible. The UI examples all use the instance name. We did consider something like an aliasing system for host names. Once devices have recognized each other, they could "decrypt" the host name, so applications could use it directly. Any suggestion? -- Christian Huitema From nobody Mon Jun 26 08:15:54 2017 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9653012EACF for ; Mon, 26 Jun 2017 08:15:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] 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 hCre97p68qTk for ; Mon, 26 Jun 2017 08:15:49 -0700 (PDT) Received: from pyrimidin.rz.uni-konstanz.de (pyrimidin.rz.uni-konstanz.de [134.34.240.46]) (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 0973E1270A7 for ; Mon, 26 Jun 2017 08:15:48 -0700 (PDT) Received: from nkongsamba.rz.uni-konstanz.de (HELO smtp.uni-konstanz.de) ([134.34.240.62]) by unitis.rz.uni-konstanz.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2017 15:15:47 +0000 Received: from [192.168.1.12] (HSI-KBW-5-158-128-23.hsi19.kabel-badenwuerttemberg.de [5.158.128.23]) (Authenticated sender: daniel.kaiser) by smtp.uni-konstanz.de (Postfix) with ESMTPSA id F3FBEDD; Mon, 26 Jun 2017 17:15:46 +0200 (CEST) To: Christian Huitema , bortzmeyer@nic.fr, Tim Chown , "dnssd@ietf.org" References: <20170625210709.GA829@sources.org> <28c0ad99-2905-64b6-52c2-a357e7fa6d12@huitema.net> From: Daniel Kaiser Message-ID: <6ecf0fcb-dfb6-eca8-df6d-f01e9b217ee4@uni-konstanz.de> Date: Mon, 26 Jun 2017 17:15:46 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <28c0ad99-2905-64b6-52c2-a357e7fa6d12@huitema.net> Content-Type: multipart/alternative; boundary="------------D9206C921A62BB28FBAC8337" Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 15:15:52 -0000 This is a multi-part message in MIME format. --------------D9206C921A62BB28FBAC8337 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Thank you very much for the review. Regarding the host names, I described a solution for privacy-preserving host name resolution via mDNS in my thesis. Summarizing, it works as follows (assuming Alice wants to resolve Bob's host name): • Bob offers a PTR and a SRV resource record for his _pds service instance, and an A resource record associated with his randomized mDNS name, e.g. “AB1234EF.local”. • Upon receiving Bob’s PTR resource record, Alice processes the hint contained in the service instance name and learns that it is Bob’s service instance. • Alice resolves this service instance retrieving the corresponding SRV resource record. She then resolves the randomized hostname, “AB1234EF.local”, obtaining Bob’s A resource record. • The daemon on Alice’s device updates the local DNS cache, and creates a CNAME record, establishing “AB1234EF.local” as a canonical name for “bob.privacy.local”. • Applications on Alice’s device can now simply use something like gethostbyname("bob.privacy.local") for resolving Bob’s private host name. This name (or just the "bob" part of it) could then also be displayed it in a UI... But as Christian Huitema said, the GUI typically only shows instance names, which is not influenced by our solution. Should we add such a way of pirvacy-preserving host name resolution to the draft? We are currently working on a 02 version. kind regards Daniel On 06/26/2017 04:18 PM, Christian Huitema wrote: > > On 6/25/2017 2:07 PM, Stephane Bortzmeyer wrote: >> On Mon, Jun 19, 2017 at 02:24:36PM +0000, >> Tim Chown wrote >> a message of 38 lines which said: >> >>> We are initiating a WG Last Call today on >>> draft-ietf-dnssd-privacy-01, as can be found at >>> https://tools.ietf.org/html/draft-ietf-dnssd-privacy-01 >> Read it and it seems OK to me. But I see one technical weakness, and >> two things that I find puzzling. > Thanks for the review. > >> In section 3.2.2, if I understand correctly the proposal for a >> predictable nonce, it seems to me it has a weakness: end-users >> machines do not always have proper clock synchronisation (see also 5.5 >> which mentions it, for an unrelated issue). True, taking only the >> first 24 bits of the time will help (some machines with different >> clocks will nevertheless end in the same time interval), but it is not >> sufficient if bad luck makes two machines fall in different intervals. > True. The solution requires that the participating devices have "good > enough" clocks -- to the minute, in practice. It is clearly a trade off > between usability and performance, and also resistance to DOS. The > initial design had unconstrained nonce instead. The problem with > unconstrained nonce is that they cannot be pre-computed by the peer, > which open the possibility of a DOS attack: creates many nonces, and > force the peer to compute as many hashes. Besides, nonces have a > weakness too -- end-user machines do not always have proper sources of > randomness. > > So in practice we require end users machines to have some sense of time. > Maybe we should be more upfront about that. > >> In section 2.4 "There is however an argument that devices providing >> services can be discovered by observing the local traffic" Another >> weakness of this argument is not mentioned: mDNS is multicasted so >> anyone can listen, eve on a switched network. Local traffic isn't. > Good point. Will fix that text. >> In section 3.4, "Host names are typically not visible by the users, >> and randomizing host names will probably not cause much usability >> issues." Is it always true? It seems to me several discovery protocols >> (over Bluetooth for instance) display the host name to the end user. > In DNS-SD, host names are not meant to be visible. The UI examples all > use the instance name. > > We did consider something like an aliasing system for host names. Once > devices have recognized each other, they could "decrypt" the host name, > so applications could use it directly. > > Any suggestion? > > -- Christian Huitema > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --------------D9206C921A62BB28FBAC8337 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Thank you very much for the review.

Regarding the host names, I described a solution for privacy-preserving host name resolution via mDNS in my thesis.
Summarizing, it works as follows (assuming Alice wants to resolve Bob's host name):

• Bob offers a PTR and a SRV resource record for his _pds service instance, and an A
resource record associated with his randomized mDNS name, e.g. “AB1234EF.local”.
• Upon receiving Bob’s PTR resource record, Alice processes the hint contained in the
service instance name and learns that it is Bob’s service instance.
• Alice resolves this service instance retrieving the corresponding SRV resource record.
She then resolves the randomized hostname, “AB1234EF.local”, obtaining Bob’s A
resource record.
• The daemon on Alice’s device updates the local DNS cache, and creates a CNAME
record, establishing “AB1234EF.local” as a canonical name for “bob.privacy.local”.
• Applications on Alice’s device can now simply use something like
gethostbyname("bob.privacy.local")  for resolving Bob’s private host name.

This name (or just the "bob" part of it) could then also be displayed it in a UI...
But as Christian Huitema said, the GUI typically only shows instance names,
which is not influenced by our solution.

Should we add such a way of pirvacy-preserving host name resolution to the draft?
We are currently working on a 02 version.

kind regards
Daniel



On 06/26/2017 04:18 PM, Christian Huitema wrote:

On 6/25/2017 2:07 PM, Stephane Bortzmeyer wrote:

On Mon, Jun 19, 2017 at 02:24:36PM +0000,
 Tim Chown <Tim.Chown@jisc.ac.uk> wrote 
 a message of 38 lines which said:


We are initiating a WG Last Call today on
draft-ietf-dnssd-privacy-01, as can be found at
https://tools.ietf.org/html/draft-ietf-dnssd-privacy-01

Read it and it seems OK to me. But I see one technical weakness, and
two things that I find puzzling.

Thanks for the review.


In section 3.2.2, if I understand correctly the proposal for a
predictable nonce, it seems to me it has a weakness: end-users
machines do not always have proper clock synchronisation (see also 5.5
which mentions it, for an unrelated issue). True, taking only the
first 24 bits of the time will help (some machines with different
clocks will nevertheless end in the same time interval), but it is not
sufficient if bad luck makes two machines fall in different intervals.

True. The solution requires that the participating devices have "good
enough" clocks -- to the minute, in practice. It is clearly a trade off
between usability and performance, and also resistance to DOS. The
initial design had unconstrained nonce instead. The problem with
unconstrained nonce is that they cannot be pre-computed by the peer,
which open the possibility of a DOS attack: creates many nonces, and
force the peer to compute as many hashes. Besides, nonces have a
weakness too -- end-user machines do not always have proper sources of
randomness.

So in practice we require end users machines to have some sense of time.
Maybe we should be more upfront about that.


In section 2.4 "There is however an argument that devices providing
services can be discovered by observing the local traffic" Another
weakness of this argument is not mentioned: mDNS is multicasted so
anyone can listen, eve on a switched network. Local traffic isn't.

Good point. Will fix that text.

In section 3.4, "Host names are typically not visible by the users,
and randomizing host names will probably not cause much usability
issues." Is it always true? It seems to me several discovery protocols
(over Bluetooth for instance) display the host name to the end user.

In DNS-SD, host names are not meant to be visible. The UI examples all
use the instance name.

We did consider something like an aliasing system for host names. Once
devices have recognized each other, they could "decrypt" the host name,
so applications could use it directly.

Any suggestion?

-- Christian Huitema

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

--------------D9206C921A62BB28FBAC8337-- From nobody Mon Jun 26 11:43:35 2017 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F0BA12EB44 for ; Mon, 26 Jun 2017 11:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6Ry5862U8jA for ; Mon, 26 Jun 2017 11:43:15 -0700 (PDT) Received: from mail.bortzmeyer.org (aetius.bortzmeyer.org [217.70.190.232]) (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 74F5912EB45 for ; Mon, 26 Jun 2017 11:43:10 -0700 (PDT) Received: by mail.bortzmeyer.org (Postfix, from userid 10) id 3B33131D2A; Mon, 26 Jun 2017 20:43:08 +0200 (CEST) Received: by mail.sources.org (Postfix, from userid 1000) id DA79C190C3E; Mon, 26 Jun 2017 20:41:07 +0200 (CEST) Date: Mon, 26 Jun 2017 20:41:07 +0200 From: Stephane Bortzmeyer To: Christian Huitema Cc: dnssd@ietf.org Message-ID: <20170626184107.GA8291@sources.org> References: <20170625210709.GA829@sources.org> <28c0ad99-2905-64b6-52c2-a357e7fa6d12@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <28c0ad99-2905-64b6-52c2-a357e7fa6d12@huitema.net> X-Transport: UUCP rules X-Operating-System: Debian GNU/Linux 8.8 X-Charlie: Je suis Charlie User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 18:43:24 -0000 On Mon, Jun 26, 2017 at 07:18:19AM -0700, Christian Huitema wrote a message of 58 lines which said: > The solution requires that the participating devices have "good > enough" clocks Which, IMHO, should be written in the RFC. > -- to the minute, in practice. It is not sufficient. The current text says "We will thus use this 24 bit number as nonce, represented as 3 octets." If two machines have almost perfectly synched clocks, one being at 20:35:44 today, and the other at 20:35:43, the values won't have the same first 24 bits (1011001010100010101010000000000 vs. 1011001010100010101001111111111). There is no obvious solution. We cannot have "fuzzy" comparisons with nonces. From nobody Mon Jun 26 13:47:54 2017 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673D812EB5E for ; Mon, 26 Jun 2017 13:47:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001] 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 eZ1q6OOYRqUT for ; Mon, 26 Jun 2017 13:47:50 -0700 (PDT) Received: from pyrimidin.rz.uni-konstanz.de (pyrimidin.rz.uni-konstanz.de [134.34.240.46]) (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 3853F12773A for ; Mon, 26 Jun 2017 13:47:49 -0700 (PDT) Received: from nkongsamba.rz.uni-konstanz.de (HELO smtp.uni-konstanz.de) ([134.34.240.62]) by unitis.rz.uni-konstanz.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Jun 2017 20:47:48 +0000 Received: from [192.168.1.12] (HSI-KBW-5-158-128-23.hsi19.kabel-badenwuerttemberg.de [5.158.128.23]) (Authenticated sender: daniel.kaiser) by smtp.uni-konstanz.de (Postfix) with ESMTPSA id 49FA9DD; Mon, 26 Jun 2017 22:47:48 +0200 (CEST) To: "dnssd@ietf.org" , bortzmeyer@nic.fr, Christian Huitema References: <20170625210709.GA829@sources.org> <28c0ad99-2905-64b6-52c2-a357e7fa6d12@huitema.net> <20170626184107.GA8291@sources.org> From: Daniel Kaiser Message-ID: <2362b938-c80a-d130-4174-1fa612a4fec4@uni-konstanz.de> Date: Mon, 26 Jun 2017 22:47:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20170626184107.GA8291@sources.org> Content-Type: multipart/alternative; boundary="------------BD5D64EBD4E3ADC613469437" Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 20:47:53 -0000 This is a multi-part message in MIME format. --------------BD5D64EBD4E3ADC613469437 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Yes. But still, it is obvious that these nonces represent adjacent time intervals. 10110010101000101010011 + 1 = 10110010101000101010100 When receiving a nonce that does not match a host's current timestamp, the host has to check whether the received nonce represents an adjacent time interval. If so, the host should accept the previous interval if the current interval is less than half over, and the next interval otherwise. We could also just accept the surrounding intervals; its a compromise between the replay window and the time skew tolerance. Nevertheless, we should definitely clarify this in the draft. Thank you :). In our specification, we forgot to mention the carry. kind regards Daniel On 06/26/2017 08:41 PM, Stephane Bortzmeyer wrote: > On Mon, Jun 26, 2017 at 07:18:19AM -0700, > Christian Huitema wrote > a message of 58 lines which said: > >> The solution requires that the participating devices have "good >> enough" clocks > Which, IMHO, should be written in the RFC. > >> -- to the minute, in practice. > It is not sufficient. The current text says "We will thus use this 24 > bit number as nonce, represented as 3 octets." If two machines have > almost perfectly synched clocks, one being at 20:35:44 today, and the > other at 20:35:43, the values won't have the same first 24 bits > (1011001010100010101010000000000 vs. 1011001010100010101001111111111). > > There is no obvious solution. We cannot have "fuzzy" comparisons with > nonces. > > _______________________________________________ > dnssd mailing list > dnssd@ietf.org > https://www.ietf.org/mailman/listinfo/dnssd --------------BD5D64EBD4E3ADC613469437 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Yes. But still, it is obvious that these nonces represent adjacent time intervals.

10110010101000101010011 + 1 = 10110010101000101010100

When receiving a nonce that does not match a host's current timestamp,
the host has to check whether the received nonce represents an adjacent time interval.
If so, the host  should accept the previous interval if the current interval is less than half over,
and the next interval otherwise.
We could also just accept the surrounding intervals; its a compromise between the replay window and the time skew tolerance.

Nevertheless, we should definitely clarify this in the draft. Thank you :).
In our specification, we forgot to mention the carry.

kind regards
Daniel

On 06/26/2017 08:41 PM, Stephane Bortzmeyer wrote:
On Mon, Jun 26, 2017 at 07:18:19AM -0700,
 Christian Huitema <huitema@huitema.net> wrote 
 a message of 58 lines which said:


The solution requires that the participating devices have "good
enough" clocks

Which, IMHO, should be written in the RFC.


-- to the minute, in practice.

It is not sufficient. The current text says "We will thus use this 24
bit number as nonce, represented as 3 octets." If two machines have
almost perfectly synched clocks, one being at 20:35:44 today, and the
other at 20:35:43, the values won't have the same first 24 bits
(1011001010100010101010000000000 vs. 1011001010100010101001111111111).

There is no obvious solution. We cannot have "fuzzy" comparisons with
nonces.

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

--------------BD5D64EBD4E3ADC613469437-- From nobody Mon Jun 26 16:07:31 2017 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0EFA129A9C for ; Mon, 26 Jun 2017 16:07:29 -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 Odx9fx-D0wNJ for ; Mon, 26 Jun 2017 16:07:27 -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 A6E85124D68 for ; Mon, 26 Jun 2017 16:07:27 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dPd6L-0001bx-DV for dnssd@ietf.org; Tue, 27 Jun 2017 01:07:25 +0200 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dPd6F-0001HZ-95 for dnssd@ietf.org; Mon, 26 Jun 2017 19:07:23 -0400 Received: (qmail 23848 invoked from network); 26 Jun 2017 23:07:18 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.244]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 26 Jun 2017 23:07:18 -0000 To: Stephane Bortzmeyer References: <20170625210709.GA829@sources.org> <28c0ad99-2905-64b6-52c2-a357e7fa6d12@huitema.net> <20170626184107.GA8291@sources.org> Cc: dnssd@ietf.org From: Christian Huitema Message-ID: Date: Mon, 26 Jun 2017 16:07:22 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20170626184107.GA8291@sources.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.22) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYWwktM+UPDyXniaU9ttNgkND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23BdAuMWhZ/OFvp7gvcRlmS4mMxyMLYYiVMNBk bvYtOqT84KDBVOBEb5OKowBRafOFYOEkjsX7F8KmpUaZQHV+SZbCEQkE+Ttak7yNVmHZUfi2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpPLwHqwRykc1ByOUA6hOga/6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyS3qs81QX8Xiqm7xFYXFK+feNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj234Kahp30YSTh5OL3yMqjF0jNdSMuNhZC3X/nGdDKYyg+1Fotn1TGspRGWfHjmaruO0b XpkevaElTi+sCWwmqxHi+BUHXGjp0J8FpT+J6AFTxiSsoNTiR/GmpPv4QzJ0uLs078I0y+3uS4dN KiUgYTBUlbxCUrr8bNBXfqd+W29lOIAbiteDwjw8P7mx/NBHSRWxZaHLvUGmD7PXY2RS8idsz7fr MHsNPRylYAkPvY1HttQOF909qtkcRbvucYBIc/SWdEVhFWVNeXUVBER+dDF8MLn6MURQGfriekzS 9Ga3AA== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [dnssd] WGLC on draft-ietf-dnssd-privacy-01 X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jun 2017 23:07:30 -0000 On 6/26/2017 11:41 AM, Stephane Bortzmeyer wrote: > On Mon, Jun 26, 2017 at 07:18:19AM -0700, > Christian Huitema wrote=20 > a message of 58 lines which said: > >> The solution requires that the participating devices have "good >> enough" clocks > Which, IMHO, should be written in the RFC. > >> -- to the minute, in practice. > It is not sufficient. The current text says "We will thus use this 24 > bit number as nonce, represented as 3 octets." If two machines have > almost perfectly synched clocks, one being at 20:35:44 today, and the > other at 20:35:43, the values won't have the same first 24 bits > (1011001010100010101010000000000 vs. 1011001010100010101001111111111). > > There is no obvious solution. We cannot have "fuzzy" comparisons with > nonces. In fact there is a solution, which I implemented in my tests. Given a clock precision X, the device knows that its real clock could be somewhere between T-X and T+X. There are a finite number of time stamps in that interval, and it should be ready to accept them all. Or query them all, if it is doing polling. -- Christian Huitema From nobody Wed Jun 28 03:33:19 2017 Return-Path: X-Original-To: dnssd@ietfa.amsl.com Delivered-To: dnssd@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E616512942F for ; Wed, 28 Jun 2017 03:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=jisc.ac.uk Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B86HjZFq2iK7 for ; Wed, 28 Jun 2017 03:33:15 -0700 (PDT) Received: from eu-smtp-delivery-189.mimecast.com (eu-smtp-delivery-189.mimecast.com [207.82.80.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CAE0127286 for ; Wed, 28 Jun 2017 03:33:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=jisc.ac.uk; s=mimecast20170213; t=1498645993; h=from:subject:date:message-id:to:mime-version:content-type:content-transfer-encoding; bh=yXx57W2yYhht5qfgth6xgOfMroDWrXnZXhbt1GizzfY=; b=LL4TiC61VuDyQQn55sDyINaBfs8S354OwcZhWkxIo/jlBsnz/rw5TCx/Zhm+C6qQbLx6eO215fTURSkr5HglyQQ0rBSfMYVHcduJpWGPWfPx86TQg/jo6W08A10kCMgMHLFkMotmdoEznILVm5vdpruUHbUkHau2Sm6b4/LMLsE= Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01lp0244.outbound.protection.outlook.com [213.199.154.244]) (Using TLS) by eu-smtp-1.mimecast.com with ESMTP id uk-mta-48-xBjsa9l6OauhUqW2il8JRw-1; Wed, 28 Jun 2017 11:33:09 +0100 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com (10.163.188.14) by AM3PR07MB369.eurprd07.prod.outlook.com (10.242.109.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1220.5; Wed, 28 Jun 2017 10:33:08 +0000 Received: from AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e900:f005:6fa:29aa]) by AM3PR07MB1140.eurprd07.prod.outlook.com ([fe80::e900:f005:6fa:29aa%14]) with mapi id 15.01.1220.013; Wed, 28 Jun 2017 10:33:08 +0000 From: Tim Chown To: "dnssd@ietf.org" Thread-Topic: I-D cut-off for Prague, 3rd July Thread-Index: AQHS7/nuokwMRpiFJkqClsZxQa5iXg== Date: Wed, 28 Jun 2017 10:33:08 +0000 Message-ID: <582092CA-4847-4036-845A-9887FE2644A9@jisc.ac.uk> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) x-originating-ip: [2001:a88:d510:1101:d57f:b005:1404:92b8] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB369; 20:brrPEDw6aqtj5PYyjUtoZ16rpTQ/sfp0GFZInyKYwVzGInnaVh4zVQlRiDt7TmlHL/7vEl4qb7HYSoSNqi6CZHlFenIVrgmDVQnNOe/BT/v5NTgjgmIE9NfeK9LmJLUguEWOkOZ7Cv7dAo0H1rDtgVanxR1boQXFObXwy+zGkto= x-ms-office365-filtering-correlation-id: ceb32a16-1133-48cd-73ee-08d4be111186 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(300000500095)(300135000095)(300000501095)(300135300095)(22001)(300000502095)(300135100095)(2017030254075)(300000503095)(300135400095)(201703131423075)(201703031133081)(201702281549075)(300000504095)(300135200095)(300000505095)(300135600095)(300000506089)(300135500095); SRVR:AM3PR07MB369; x-ms-traffictypediagnostic: AM3PR07MB369: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(236129657087228)(148574349560750); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB369; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB369; x-forefront-prvs: 03524FBD26 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39410400002)(39450400003)(39400400002)(39840400002)(8676002)(6486002)(5660300001)(50986999)(478600001)(72206003)(189998001)(6506006)(3660700001)(6436002)(5640700003)(74482002)(1730700003)(6512007)(2351001)(50226002)(53936002)(42882006)(33656002)(8936002)(36756003)(99286003)(81166006)(25786009)(558084003)(6916009)(38730400002)(3280700002)(110136004)(6116002)(102836003)(82746002)(86362001)(83716003)(7736002)(2501003)(2900100001)(2906002)(305945005)(5250100002)(57306001); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB369; H:AM3PR07MB1140.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-ID: MIME-Version: 1.0 X-OriginatorOrg: jisc.ac.uk X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Jun 2017 10:33:08.2109 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 48f9394d-8a14-4d27-82a6-f35f12361205 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB369 X-MC-Unique: xBjsa9l6OauhUqW2il8JRw-1 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [dnssd] I-D cut-off for Prague, 3rd July X-BeenThere: dnssd@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Discussion of extensions to DNS-based service discovery for routed networks." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2017 10:33:18 -0000 The deadline for submitting draft updates (or new -00 drafts) is 23:59 UTC next Monday, July 3rd. Tim=20