Re: [dnssd] Next steps for privacy discovery

Lanlan Pan <abbypan@gmail.com> Mon, 03 December 2018 04:27 UTC

Return-Path: <abbypan@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 29BA9130DF7 for <dnssd@ietfa.amsl.com>; Sun, 2 Dec 2018 20:27:23 -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 6oSCwetEcKVo for <dnssd@ietfa.amsl.com>; Sun, 2 Dec 2018 20:27:20 -0800 (PST)
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 631FC130DFF for <dnssd@ietf.org>; Sun, 2 Dec 2018 20:27:20 -0800 (PST)
Received: by mail-ed1-x52d.google.com with SMTP id f23so9559987edb.3 for <dnssd@ietf.org>; Sun, 02 Dec 2018 20:27:20 -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; bh=NyLZN03pO4ZpNaqCi7qmQi6TKRlmAb7mh0C6OqX/uPc=; b=uSrASibPEVxc4yaWPcXX8Zc7amscgCjfSIKqZCFN7YBYCT3PdE6RSL1NlNlpAnMvhk knmKLo4Di2pdf4H91rQ9ARnli2AwYn+1NWaKupYVmBcAec6PN46sv2OpTvcQYTK8smaI I45Mr9n6Uwx4NIA7rTFKWRmFJ7ApMyistZoK+Ot+yN/F5Zhmr3cCj0gY2JfbHbufiivK ic3pnra5LXEOoyasWCkRUPPx+qF9Pe3/Bv4GnT6oudo9wOF3FdN1T5QFuZ0fFpc52GHu D+QmwgTbPOd5JmT2OUs1YQYMf/gmx1Uo9sqbkdg8B+hC5BTzMmM7+SyJUWriovK+8q2Q HT0A==
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=NyLZN03pO4ZpNaqCi7qmQi6TKRlmAb7mh0C6OqX/uPc=; b=BTN6lLbA5uD3jasj1ssfrX0TufRWbDgL+w3J7HN6nFQFBZdu6IpLH9j6C+x9ExNIHu AYZcE19SDpnm6mpq2WM7XNyESnxL501Que2zqxHtc+kavQdtCI2V0/gwtYfw0Sn30cPZ Trc0NeOZovf0MkXo8vmEKHmIVwbxDsa1DWeU803h1/2mcUOYZoOuMtu1VartLX+wxy1K NnEBV3zIfR8fJkgbtCc8sO1GWBbHTaglpYz/Jgs9+7nAEntaivFoOujOIphu3x23RqGE xA+6Z/2SajtzOPA7YAMkNCLzFKjAxEmqiUxbETxeEGN9Vit1jDhCfpIwh9hW7kSEeDpi 0qJQ==
X-Gm-Message-State: AA+aEWbiz6Rpr85sDQCKj0LIJHAHaOW4jcDJQZMfCw0uXbrKGD+wNFCx XGp2VZhkUPlof3vLEmo0L1fP2fBMxm1e6FB6iox/6w==
X-Google-Smtp-Source: AFSGD/U7k3BrbbMV91/Qk59VUYMKGB0Q4xRG7m9sAgEc8wNv0bxMUEw2cgJo7RXSQqT1qwT6w55SyUvx4gyDx0BZKAk=
X-Received: by 2002:a17:906:b799:: with SMTP id dt25-v6mr11854337ejb.217.1543811238846; Sun, 02 Dec 2018 20:27:18 -0800 (PST)
MIME-Version: 1.0
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>
From: Lanlan Pan <abbypan@gmail.com>
Date: Mon, 3 Dec 2018 11:25:28 +0700
Message-ID: <CANLjSvVHwjnYXeNkb59r1h5VbrfTyfpXo2OFJjhqqmJ3iipg+Q@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: dnssd <dnssd@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000007de756057c16908c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/G3xXWn_P0mz2nw2TBKAYj_rCz3E>
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: Mon, 03 Dec 2018 04:27:23 -0000

Christian Huitema <huitema@huitema.net>于2018年10月30日周二 上午1:21写道:

>
>
> On 10/28/2018 6:48 PM, Lanlan Pan wrote:
>
> Christian Huitema <huitema@huitema.net>于2018年10月26日周五 下午3:09写道:
>
> ...
>
>
>>
>> 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.
>
>
> That's what we were specifying in the current privacy draft. There are two
> issues. The first one is that if you use TLS-PSK, the Client Hello must
> include a key identifier. If there is a different key for each client, the
> key identifier could become a client identifier. We solved that  by using a
> "predictable nonce" for key identifier.
>
Thanks christian, I get it.

> The second issue is of course that assigning different keys to different
> clients requires extra management at the server, something that is not
> needed in the "private public key" class of solutions.
>
Will the "private public key"  be refresh in period ? How can the clients
get the key ?

>
>
> -- Christian Huitema
>
-- 
致礼  Best Regards

潘蓝兰  Pan Lanlan