Re: [dnssd] Confirming consensus from DNSSD Privacy discussion in Bangkok

Christian Huitema <huitema@huitema.net> Thu, 28 February 2019 23:04 UTC

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 EA2A7130F1C for <dnssd@ietfa.amsl.com>; Thu, 28 Feb 2019 15:04:09 -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, RCVD_IN_MSPIKE_H2=-0.001, 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 IRLU2jVA50wd for <dnssd@ietfa.amsl.com>; Thu, 28 Feb 2019 15:04:07 -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 18B81130E96 for <dnssd@ietf.org>; Thu, 28 Feb 2019 15:04:07 -0800 (PST)
Received: from xsmtp04.mail2web.com ([168.144.250.231]) by mx147.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from <huitema@huitema.net>) id 1gzUif-0006Lw-NB for dnssd@ietf.org; Fri, 01 Mar 2019 00:04:04 +0100
Received: from [10.5.2.16] (helo=xmail06.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 1gzUiX-0005Zj-5w for dnssd@ietf.org; Thu, 28 Feb 2019 18:03:57 -0500
Received: (qmail 14946 invoked from network); 28 Feb 2019 23:03:49 -0000
Received: from unknown (HELO [192.168.1.101]) (Authenticated-user:_huitema@huitema.net@[172.56.42.202]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <mt@lowentropy.net>; 28 Feb 2019 23:03:49 -0000
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
From: Christian Huitema <huitema@huitema.net>
X-Mailer: iPhone Mail (16D57)
In-Reply-To: <30e6aaa1-4e45-46d2-b2a2-89ece41ce414@www.fastmail.com>
Date: Thu, 28 Feb 2019 15:03:47 -0800
Cc: dnssd@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <406056C2-CED1-4877-AD44-CF630937F787@huitema.net>
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com> <e9b4900d-94e3-c79a-2a72-e2f996663b9d@huitema.net> <CAPDSy+4d27SQCStGzPpzzv=pjGiCM+0df988BesRGHdV_vvteA@mail.gmail.com> <CAO8oSXnXre29hjbNCZ1N7b8VBRMubS1yO5_XXr7VY2yxzNAWGw@mail.gmail.com> <1fc0ba86-2619-6efb-5e89-aa0a025c998e@huitema.net> <CAO8oSX=rWYxkKq0H5dEJDKq_Hs3tH2gqSxQ-Cr_SaHDPkrvvCA@mail.gmail.com> <CAO8oSXkfszNXUT6gr1G2OEWgJXe-cX_S4yAJmLm5sUqN0SQ54w@mail.gmail.com> <CAPDSy+7UvYdNOeYZg-R2b+eXuvGNMguXDWtkKgotVpLP5YPk4g@mail.gmail.com> <3d4d353e-5cb5-e35f-fc31-db819b4b2506@huitema.net> <CAO8oSX=9Fi60GigVWgCRkLXxwgF8aD1BveVNicz6_m5S-MQnYg@mail.gmail.com> <867b0844-ddf2-a7d1-4b3c-166fb4770e2d@huitema.net> <CAO8oSXmKwA6yE3A_OczjCBSvLwm1jqT3dEDNGzAB88ZM785+CQ@mail.gmail.com> <eb11a426-fcf5-7e62-6b40-82f5218e1d47@huitema.net> <CAO8oSXkMc1RL7YBfmNx4teShO9BCT_FAvcXc5hatahDd-17uhg@mail.gmail.com> <a6357d59-fb6f-3129-2e7f-a77cfff9c145@huitema.net> <5847.1551364133@localhost> <d3c669f9-ba13-af6f-4249-931721 c57b96@huitema.net> <30e6aaa1-4e45-46d2-b2a2-89ece41ce414@www.fastmail.com>
To: Martin Thomson <mt@lowentropy.net>
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.35)
X-Recommended-Action: accept
X-Filter-ID: EX5BVjFpneJeBchSMxfU5sIMv7Zf5qcoWOOOH0DD+fR602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvOzXMPpKBnlzcICbdbWbUSKtVjyn5UrUp4n4yKOOaq9AxYcdtF9Fsy1e8rNirX3rQglDj fzzJ6O8jiVhZi+WiYeCsScX6I9Dl5i6VrUM1b/j5kB7L9qFZEB58fINh4BP9MqXe0Of4jddu9xC8 8+iQ5nb6BRFVjXUbiREH8mlR1JtPfYZ1V10x8j0kNETJD+nyXtcV2Hz37FuQUlYMDMlHwjIJ0464 etNXHOU+5Kb0QuG3bATPP9eeLWC5kDweN7crsXBXvrLBlKCVRjjdPbjQ4HmidG0pg2HLuLsP3mPp isElTs5Ex5aNZlcgVQFtAhrEij3dKxLhoxcmaInYbR5vlqETd+klAX+KFYkIxu6zxdn+1QmdZsu6 kxo/qWEj6Z1d7VIcMSgqtcKbU9La+AHiCFB9vuYMeDoXsMJDD9CZFW2DHXeua4usuyudZl7ZJWmg 5a0jiD6XqsJZtjQxlyCdsezYBFjKYeYprI6D9W+xTY9pPwUimsNGvJJilSn4u6QSZCRqzLn7viWp y4ASDnGTWMMs95DGoDQyh90npG6wuAU16Y3oZJdQ0WXQEIKhyt8GANo5bn0tFTz4SVUdCy2MVE6+ P+NMWgh0hdHFCOgNkMJ392PNDpgLsd6Ddd/s7VM53g/1RxwT9/iBE7K7b9LlmTrAMgFPp7+h3kLe NmBV53UGh11yCpOXhJ0kOoLblmK8rWozXRXcmpE9wVzMNpY5b/RRXxKF5tPxTxfD0dMN+t5ZP6zO upSxHMPsAHfGhZAC/HtFe6KPzyYGlUQCNd2pMbL7G3ch6MdB0XuALpEgtIRS0LLV0L53ylJMDui2 2KlE/N40eTXlWiUAYdLmsJdAoPJHNvQfAjIDptXbNSradnS0Zqm0mOdPl1LeUTNmkYtBTuxv0/1e /nzlq13wYTxncOSJHdsd+cwIgRT6euCWiMrA+4FHNKsiy9wMVtQ6ai8zTQ==
X-Report-Abuse-To: spam@quarantine9.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/yYe0XGGvmuPWDggdTJgKr-heReY>
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, 28 Feb 2019 23:04:10 -0000

PSK would indeed work, but it is subject to very bad failure modes. If the PSK is compromised, the attackers can not only track clients and servers, but also impersonate servers.

What would be workable is to treat the PSK ID as a discovery ticket, carrying the client discovery key share. The PSK would be derived from the discovery secret. We would probably need to add a proof in the PSK ID, so broadcast receivers could quickly decide that this is "not for me".

In this design, the service name would not be transmitted at all. No SNI, no ESNI. The handshake key and session key would depend on the PSK, which provides all kinds of guarantees. If forward secrecy is required, use PSK + ECDH.

Structuring the PSK-ID seems ugly, but we do that with STEK based tickets all the time.

That may well be a simpler design than trying to reuse ESNI. It also solves a small hole in the ESNI-based proposal: the session key depends on the ESNI nonce, but the handshake key does not.

-- Christian Huitema 

> On Feb 28, 2019, at 2:34 PM, Martin Thomson <mt@lowentropy.net> wrote:
> 
> I probably don't have all the context, but when I start hearing about keeping public keys secret, I always think "why not a PSK?"  Is there a reason that wouldn't work here also?  A PSK ensures that only those who have the key can see that the query is for an entity with the PSK.  You could use DH as well to make the details of the query confidential from those as well.  You don't get authentication unless you also have an asymmetric key, but that's easily doable (with TLS anyway).
> 
>> On Fri, Mar 1, 2019, at 05:05, Christian Huitema wrote:
>> 
>>> On 2/28/2019 6:28 AM, Michael Richardson wrote:
>>> Christian Huitema <huitema@huitema.net> wrote:
>>>>> Okay, so, as I suspected, this is vulnerable to dictionary attacks if
>>>>> the public key is leaked. Am I misunderstanding? If so, can you
>>>>> explain why this is not the case?
>>> 
>>>> If the public key is leaked, anyone with the leaked key can impersonate
>>>> an authorized client, establish a connection, etc. The secrecy of the
>>>> public key is what keeps this together. In all these schemes, there has
>>>> to be a secret that acts as the seed for the privates exchanges, and in
>>>> the scheme I propose that secret is the public discovery key of the server.
>>> 
>>> Since we have extensive public training that the "public key" is safe to
>>> disclose, this may be confusing for many, as this is no longer the case for this.
>>> 
>>> May I suggest different terminology? As the two halves of asymmetric keying
>>> systems are mathematically equivalent, so maybe we could call it the
>>> client-dual-key or something like that.
>> 
>> It is a server key, not a client key, but I see the issue. I was
>> thinking of using "discovery key". Would that work?
>> 
>> -- Christian Huitema
>> 
>> 
>> 
>> _______________________________________________
>> dnssd mailing list
>> dnssd@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnssd
>> 
>> Attachments:
>> * signature.asc
> 
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd