Re: [dnssd] WGLC on draft-ietf-dnssd-privacy-01

Daniel Kaiser <daniel.kaiser@uni-konstanz.de> Mon, 26 June 2017 20:47 UTC

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 673D812EB5E for <dnssd@ietfa.amsl.com>; 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 <dnssd@ietfa.amsl.com>; 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 <dnssd@ietf.org>; 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" <dnssd@ietf.org>, bortzmeyer@nic.fr, Christian Huitema <huitema@huitema.net>
References: <CF1BAEAE-41C7-4E69-AD6F-9F31E7C7B2A3@jisc.ac.uk> <20170625210709.GA829@sources.org> <28c0ad99-2905-64b6-52c2-a357e7fa6d12@huitema.net> <20170626184107.GA8291@sources.org>
From: Daniel Kaiser <daniel.kaiser@uni-konstanz.de>
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: <https://mailarchive.ietf.org/arch/msg/dnssd/cx8tTgsMiMh5wNaYAX8yPSlJG2M>
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." <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, 26 Jun 2017 20:47:53 -0000

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