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

Christopher Wood <christopherwood07@gmail.com> Thu, 28 February 2019 01:26 UTC

Return-Path: <christopherwood07@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 64EE7130EAB for <dnssd@ietfa.amsl.com>; Wed, 27 Feb 2019 17:26:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 fN097dodC7bz for <dnssd@ietfa.amsl.com>; Wed, 27 Feb 2019 17:26:06 -0800 (PST)
Received: from mail-yw1-xc2b.google.com (mail-yw1-xc2b.google.com [IPv6:2607:f8b0:4864:20::c2b]) (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 708621277D2 for <dnssd@ietf.org>; Wed, 27 Feb 2019 17:26:06 -0800 (PST)
Received: by mail-yw1-xc2b.google.com with SMTP id 189so9797790ywi.3 for <dnssd@ietf.org>; Wed, 27 Feb 2019 17:26:06 -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:content-transfer-encoding; bh=+hCcd/5K8QEEEc8HsBAKdelX3Ezu71J02BOctr6XBuQ=; b=LRU05fqaqzlV0lJviEjO1nubD+pRaVBhufUYspfNKqrb/NWKAzW+EvU+SZhKOGeAzO deTmhjF1p6Fg9PizpXKATtD1kUKTWzi2zS0xZq/jyy4pkvB7n/wJhgzRg58OtIdVHRUC fd7l+pZUJ42Cc71NVc8kbVLsuFDt8XzGzVEilxCIgk9QKQEqQOJSeDIKtVtdWOb4GQdl /UgJ5gvQey1pNttSnRMuw0wTMC9YZ+Ds+lc9riE4zdep2UYYW6YmVzRk7pnFwdNjlNGj AGSP3u1QDYgbmA8ym+tcluWRl4x5XJCWBQDemU6Ipc3p+LsGC4HFr2Zx6vG3cZ60SlmX XKqA==
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:content-transfer-encoding; bh=+hCcd/5K8QEEEc8HsBAKdelX3Ezu71J02BOctr6XBuQ=; b=FPafjofesWFO+5kHE1QdAyy5iK9WzsFoHXp1zcdUhO1qgiGj7rE8sDZ8WCee5geu5W O9EnHhrHcHNhj5wr5Dytc+iGtOnuk/l5LFrWxZvZStLZ67A83/S+5tPvKXEd+Zdq86Kd FUbp83lm2ROOGrhfQABFKeaAQCSY3U67mY/XP1jp/5IYjnu9WXpce5/CeT7wxlpvWADp DibHPfkSyqkBKwlboOg0m2rbGVlbwewotRIhwuWL8aQzN4E/dWL0N5/1RYWkmVX9wl5F A8faPeVNKcTcAL4gZIGm5CYf/A1ppljaqrvUBolrNTtu2A21ev0lZhcnk4WubckDps49 fHBA==
X-Gm-Message-State: AHQUAubwU9IyRLyV3oannDF40Omg+91XPWnZS/RCdEQ5ghyaRKqsR0gF 1c3Z2zi3fhza4tjiwveTPvVS7Nwj9J9lycQRiOY=
X-Google-Smtp-Source: AHgI3IZ+/rqEluNllFGCrMuwCfeCnKRULGFZviQFuMVwjPs5bNlg97Y3wm9wFza3gNswzsOGrSB2dtcEXz1Eh2XjGMw=
X-Received: by 2002:a25:73d3:: with SMTP id o202mr4575012ybc.310.1551317165300; Wed, 27 Feb 2019 17:26:05 -0800 (PST)
MIME-Version: 1.0
References: <CAPDSy+6YyW_G7uwfwGPv1KLtJqL96dZ87R-5pnmmffEEniTigg@mail.gmail.com> <47A82E32-32B9-476F-AB79-76C8D182624F@apple.com> <CAO8oSXkGAErtKQgMGGT+88PY4Y+wJ_6Rz493exaymZ_L8F4FNg@mail.gmail.com> <CAPDSy+68V=rx8cAbVq6rKxNbb9yHisCCPURwHoLKsA179NooLw@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> <89ab9dfc-99a5-9522-201b-3713abf43575@huitema.net>
In-Reply-To: <89ab9dfc-99a5-9522-201b-3713abf43575@huitema.net>
From: Christopher Wood <christopherwood07@gmail.com>
Date: Wed, 27 Feb 2019 17:25:54 -0800
Message-ID: <CAO8oSX=o=T31q1LVnFwZT34eYN4Sfs+HGqryKnFNJZHBNadxiw@mail.gmail.com>
To: Christian Huitema <huitema@huitema.net>
Cc: DNSSD <dnssd@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnssd/eSED4sVWDmCmMIdxxAlScfmZkg4>
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 01:26:08 -0000

On Wed, Feb 27, 2019 at 5:20 PM Christian Huitema <huitema@huitema.net> wrote:
>
>
> On 2/27/2019 4:45 PM, Christopher Wood wrote:
>
> I think this highlights an important difference between the two
> proposals on the table. Namely, whether or not service discovery
> happens in one or two RTTs or stages. The design you sketch above
> permits 1-RTT discovery at the cost of lesser security. (The service
> ID is not encrypted, thereby permitting dictionary attacks as we
> discussed.) Bob's proposal addresses this by first doing a mutually
> authenticated key exchange and then querying for the service in the
> second trip.
>
> While no one was opposed to the two stage approach during the last
> meeting, I'm not sure we should rule it out. It depends on the threat
> model.
>
> So, having said all that, perhaps someone can take a stab at
> documenting the threat model here? That might help us choose a
> solution given a shared understanding of the problem. I'm happy to
> give it a shot.
>
> Or perhaps we can short circuit that discussion entirely and simply
> get consensus around the crux of the issue: is the WG comfortable with
> the one stage approach and the possible attack(s), or do we think two
> stages should be used? I'm quite curious to hear what others think.
>
> The service ID is in fact encrypted, ESNI stands for "encrypted SNI".

Ah, well I was operating under the assumption that we were *not* using ESNI.

What is in the discovery proof, then?

> Clearly, this requires TLS 1.3, to guarantee that the server's parameters are encrypted -- we would not want the server's certificate in the clear. But we are looking at a direct connection over a local network, without expected interference from firewalls and other middle-boxes.
>
> If we align with TLS, we benefit from all the security analysis done for TLS, and all the design work done for ESNI. I am looking at doing a prototype using the Picoquic implementation of QUIC and the Picotls TLS stack, and I think I could have a demo in Prague -- looks like a great hackathon project. The work is fairly minimal:
>
> 1) At the client, provision the server discovery key out of band at authorized clients, instead of the DNS lookup of the ESNI key of the client facing server in the standard implementation;
>
> 2) At the server, accept the first packet in the exchange over a broadcast channel,
>
> 3) At the server, discard all ClientHello packets that do have an ESNI extension demonstrating knowledge of the service discovery key by the client,
>
> 4) At the client, latch on the IP address and port of the response.
>
> The ESNI proposal already has a bunch of provisions for securing the exchange, such as copying a nonce in the server response to demonstrate that the server correctly decrypted the ESNI.
>
> -- Christian Huitema
>
> _______________________________________________
> dnssd mailing list
> dnssd@ietf.org
> https://www.ietf.org/mailman/listinfo/dnssd