Re: [dnssd] Next steps for privacy discovery

Lanlan Pan <> Mon, 29 October 2018 01:48 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 33BAC126F72 for <>; Sun, 28 Oct 2018 18:48:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SAVHjzctLJtM for <>; Sun, 28 Oct 2018 18:48:21 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::52b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 443A5124C04 for <>; Sun, 28 Oct 2018 18:48:21 -0700 (PDT)
Received: by with SMTP id e2-v6so5896572edn.2 for <>; Sun, 28 Oct 2018 18:48:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/3D9lA4J25Em6WLJZOUK1jTAlc6b21A+D8e5Sriknrg=; b=YF1Qi3tD3KHjgSXiKPdl7GGB4UTpyvn7492q1aq9+T3O10vNVqhwfw0o9fMU1wHBS7 v4GvZ7ciiso2V7dq4RPCWnctjna5rL7h5Pf9ITCDHPCIBzYxj+83aagJsDTmX1rV+0zJ gDQ5nuFrl0oAGq/AMOjEWvMO8ItcGbiINFZOsJJRvBEaV8zPfd4s+o282/eRYX30ISoQ JF4uS8ZuJEzh6flN21BRf1zc+V4mjZkC0Umd08254Hg5AkiFkmMiyTWYxaHtTSUsvflh aCjxs0T6TocEtznz4BTaFsQSt8MZl5tJCd9wiy4N3TxFBpQzCstijqKN7INPcZ9DbIIt +gYg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/3D9lA4J25Em6WLJZOUK1jTAlc6b21A+D8e5Sriknrg=; b=n7rGI8d93tW/B17kqaX6vXsUNYKm5uPeQvunB1xpyxkg8sPRkslNfO4pZskSGKK6xr /U9PdNYyTt0SiYKUDh9WEQAGI3ZoTT2JysnuGbR3S4jVDu4YNveT05AzWb2YVE8Ovm5L q/G8WTOqJ2RaV5MwB/XaT0FfoGIQ114Odd6NnS+dXLoK9UAze/dRcAe3cUiDOEPyl3iA b2kcEkOtfBFroXYQWu90efIJ8DXVoG88HVAQkpcheRwZab8R0mwGYhNda306NdJnZgv0 V9MHH5EvizT6sU1QpSe/Pa+3Xriu4e23AMSuvQD4v+Bt93JjkvtiP6pLmYSta500eM7x yiEA==
X-Gm-Message-State: AGRZ1gI3uXkhRrpAsx4SvwLEpE3kzylPDKu0v08sOEpW30jsgtnn4L3a ccojc3iCkz3/+31FpK8xJP6X7pixUTRI7ULVhVPgjw==
X-Google-Smtp-Source: AJdET5epu7YkHLLUaGkLbNVBXll4nsYtaRtNuM+LQ1eST4BzsZ/4Vs6yzXl22ReKiZ7obcBWikl7reBqBikxuNhbslY=
X-Received: by 2002:a17:906:b799:: with SMTP id dt25-v6mr4389684ejb.217.1540777699665; Sun, 28 Oct 2018 18:48:19 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Lanlan Pan <>
Date: Sun, 28 Oct 2018 21:48:07 -0400
Message-ID: <>
To: Christian Huitema <>
Cc: dnssd <>
Content-Type: multipart/alternative; boundary="000000000000776be105795443a0"
Archived-At: <>
Subject: Re: [dnssd] Next steps for privacy discovery
X-Mailman-Version: 2.1.29
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, 29 Oct 2018 01:48:24 -0000

Christian Huitema <>于2018年10月26日周五 下午3:09写道:

> With some prodding from David and Barbara, I resubmitted the DNSSD
> Privacy and Pairing drafts before the Bangkok meeting. The changes are:
> * For both drafts, add reference to the privacy requirement draft and to
> the scaling draft,
> * For both drafts, add a short paragraph in the intro stating that
> things might change based on the scaling analysis,
> * For the privacy draft, remove the requirement analysis part and
> replace it by a reference to the requirement draft.
> David is prodding me to write a complete revision of the privacy draft,
> using the "shared public key" approach, which has very good scaling
> capabilities and reasonably robust resilience to attacks. It is a bit
> different from the draft that Bob Bradley sent, and I will comment on that
> later. I could not submitted a revised discovery proposal before the dead
> line, but here are the broad lines of what I would do:
> 1) Server has a public key, which is "somewhat secret" -- it is only
> provided to authorized clients and they are expected to keep it secret.
> 2) Single announcement per server of the form nonce|proof, where the
> nonce is a "predictable nonce" computed as a hash of quantized time and
> secret public key.
> 3) Clients do a search for the nonce, just like in the current spec, but
> there is only one nonce per server, so the client will get exactly one
> response.
> 4) If we kept the current "two phase" structure, use a TLS protocol
> extension to demonstrate knowledge of the server's public key in the
> client hello. I think we can build on the work done for SNI encryption,
> which would fit quite well.

I wonder if we could consider about use tls psk (pre-shared key) ?  server
can assign different key to different client.

> 5) We may consider having a different nonce for each available service,
> e.g. have the announcement computed as hash of quantized time, service
> type and secret public key. This would allow for a single phase solution.
> 6) We may also have the service name used as a proof, e.g. encoding of
> nonce and service name with the server's private key.
> 7) We need to say something about protecting the service connections
> from clients to server. DNSSD privacy would not be that much useful if
> the clear text data on the service connection revealed the identity of
> client or server. I think a combination of SNI encryption and TLS 1.3
> would work, but that may be extra work.
> 8) We also need to recommend randomized host names for the A/AAAA
> records of the servers, otherwise there is also a big leak.
> Some of the complexity in the DNSSD approach comes from a desire to fit
> into the existing DNSSD formats. This leads to some tricks like Base64
> encoding of nonce, time stamps and proofs so they fit in existing
> fields like service type or instance name. Bob's draft jettisons DNSSD
> compatibility and defines a new binary format. That is definitely
> cleaner, but there is a trade-off: a new protocol implies that we cannot
> reuse the DNSSD server infrastructure. It would be interesting to gauge
> the WG consensus on that tradeoff.
> The other big difference between Bob's draft and the evolving proposal
> is the use of trial decryption. In Bob's approach, clients send probes
> that the server tries to decrypt by using the public keys of various
> registered peers or friends. This has scaling issues similar to the
> pairwise keys that we relied on in our first drafts. After discussions,
> we grew very concerned with these scaling issues and the
> corresponding potential for DOS attacks. We instead evolved towards
> a system of "predictable nonces".
> The predictable nonces are a tradeoff between privacy and performance.
> Predictable nonces can be precomputed by the server, which reduces the
> processing cost and also limits the potential of DOS attacks. But then,
> all authorized clients of a server can generate the same predictable
> nonces, and thus all authorized clients can detect the presence
> of other authorized clients. This reduces privacy somewhat, although not
> necessarily by a whole lot. All authorized clients can discover the server,
> and thus retrieve its IP address. Network level analysis can then reveal
> which clients are also connecting to that server. This means that the
> information
> potentially leaked by the predictable nonce is also available at a lower
> layer. I think that the trade-off is thus between a minor privacy leak and
> a significant performance gain, but of course other WG members may have a
> different analysis. It would be interesting to gauge WG consensus on that
> subject.
> Looking forward to the debates in Bangkok!
> -- Christian Huitema
>  -- Christian Huitema
> _______________________________________________
> dnssd mailing list
致礼  Best Regards

潘蓝兰  Pan Lanlan