Subject: [dnssd] Fwd: New Version Notification for draft-huitema-dnssd-tls-privacy-00.txt

From: Christian Huitema <[email-masked]>
Date: Sun, 10 Mar 2019 21:01:09 -0700

This is my prototype design of private discovery using TLS/ESNI. I will
try having an actual prototype in place before Prague.

-- Christian Huitema

-------- Forwarded Message --------
Subject: 	New Version Notification for
draft-huitema-dnssd-tls-privacy-00.txt
Date: 	Sun, 10 Mar 2019 20:58:25 -0700
From: 	[email-masked]
To: 	Daniel Kaiser <[email-masked]>, Christian Huitema
<[email-masked]>

A new version of I-D, draft-huitema-dnssd-tls-privacy-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name: draft-huitema-dnssd-tls-privacy
Revision: 00
Title: Private Discovery with TLS-ESNI
Document date: 2019-03-10
Group: Individual Submission
Pages: 12
URL:
https://www.ietf.org/internet-drafts/draft-huitema-dnssd-tls-privacy-00.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-dnssd-tls-privacy/
Htmlized: https://tools.ietf.org/html/draft-huitema-dnssd-tls-privacy-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-huitema-dnssd-tls-privacy

Abstract:
DNS-SD (DNS Service Discovery) normally discloses information about
both the devices offering services and the devices requesting
services. This information includes host names, network parameters,
and possibly a further description of the corresponding service
instance. Especially when mobile devices engage in DNS Service
Discovery over Multicast DNS at a public hotspot, a serious privacy
problem arises.

We propose to solve this problem by developing a private discovery
profile for UDP based transports using TLS, such as DTLS and QUIC.
The profile is based on using the Encrypted SNI extension. We also
define a standalone private discovery service, that can be combined
with arbitrary applications in the same way as DNS-SD.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Bob Bradley <[email-masked]>
Date: Sun, 10 Mar 2019 21:55:47 -0700

It looks like this is intended to find a specific server on the network using that server's discovery key to encrypt the request. If the client doesn't know which servers might be on the network, would it need to send a multicast packet for each server it has a key for? For example, if I'm paired with 20 devices then when discovery starts, would I send 20 multicast packets?

Are there plans for a mechanism to announce the availability of a server? For example, if I start discovery (which sends an initial batch of multicast packets) and then a few seconds later a server becomes available, will server have a way to notify the client of its availability?

> On Mar 10, 2019, at 9:01 PM, Christian Huitema <[email-masked]> wrote:
> 
> This is my prototype design of private discovery using TLS/ESNI. I will try having an actual prototype in place before Prague.
> 
> -- Christian Huitema
> 
> 
> 
> Subject:	New Version Notification for draft-huitema-dnssd-tls-privacy-00.txt
> From:	[email-masked] <mailto:[email-masked]>
> To:	Daniel Kaiser <[email-masked]> <mailto:[email-masked]>, Christian Huitema <[email-masked]> <mailto:[email-masked]>
> 
> 
> URL: https://www.ietf.org/internet-drafts/draft-huitema-dnssd-tls-privacy-00.txt <https://www.ietf.org/internet-drafts/draft-huitema-dnssd-tls-privacy-00.txt>
> Status: https://datatracker.ietf.org/doc/draft-huitema-dnssd-tls-privacy/ <https://datatracker.ietf.org/doc/draft-huitema-dnssd-tls-privacy/>
> Htmlized: https://tools.ietf.org/html/draft-huitema-dnssd-tls-privacy-00 <https://tools.ietf.org/html/draft-huitema-dnssd-tls-privacy-00>
> Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-dnssd-tls-privacy <https://datatracker.ietf.org/doc/html/draft-huitema-dnssd-tls-privacy>
> 
> 
> Abstract:
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd

---

From: Christian Huitema <[email-masked]>
Date: Sun, 10 Mar 2019 22:53:38 -0700

On 3/10/2019 9:55 PM, Bob Bradley wrote:
> It looks like this is intended to find a specific server on the
> network using that server's discovery key to encrypt the request. If
> the client doesn't know which servers might be on the network, would
> it need to send a multicast packet for each server it has a key for?
> For example, if I'm paired with 20 devices then when discovery starts,
> would I send 20 multicast packets?

As designed, the answer is yes, the client would send 20 packets. I
understand very well that there is an alternative design in which the
server sends a packet announcing its arrival, and then every interested
client discovers the server and contacts it. I believe that the scaling
is actually equivalent:

1) In my design's worst case, the client sends N packets, and P servers
who are present perform O(N) trial decryptions. Total O(P.N2).

2) In the server announce design, P arriving servers send P packets upon
arrival on the network, and O(N) clients perform N trial decryptions.
Total O(P.N2) as well.

It is pretty hard to resolve that discussion without actual statistics,
application scenario, etc. For example, it is not clear at all that
"servers" will be listening all the time, versus listening only when the
corresponding app is in focus, e.g. when several users start the same
app and explain app instances to find each other.

>
> Are there plans for a mechanism to announce the availability of a
> server? For example, if I start discovery (which sends an initial
> batch of multicast packets) and then a few seconds later a server
> becomes available, will server have a way to notify the client of its
> availability?

Again, this depends a lot on application scenario. In a peer-to-peer
scenario, the roles of server and client are flexible. Peer A comes
first, finds nobody there, starts listening in server mode. Peer B
arrives a moment later, starts in client mode, engages in discovery,
succeeds.

-- Christian Huitema

---

From: Bob Bradley <[email-masked]>
Date: Mon, 11 Mar 2019 00:03:03 -0700

> On Mar 10, 2019, at 10:53 PM, Christian Huitema <[email-masked]> wrote:
> 

In (1), there are N multicast packets per client and P unicast responses from paired servers. In (2), there is 1 multicast request per client and P unicast from paired servers. Many devices act as both client and server. Multicast vs unicast can make a big difference in the number of packets processed by each device.

As an example, my device has 40 paired devices and the network has about 300 devices browsing for and offering services (by looking at mDNS). If we assume other devices have a similar number of paired devices then:

Approach 1: 12000 multicast requests (and trial decryptions) and 40 unicast responses.
Approach 2: 300 multicast requests (and trial decryptions) and 40 unicast responses.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 11 Mar 2019 00:14:07 -0700

> Approach 2: 300 multicast requests (and trial decryptions) and 40 unicast responses.

Using your numbers, there would be 12000 trial decryptions in approach 2
as well. Each client has to try 40 different server keys to see which
one would work.

But I am not convinced at all that this 40/300 split is something we
will see in privacy oriented applications. If we are looking at
application pairing rather than device pairing, then the server and
client role are very flexible, the ratio of client and server will be
close to parity, and the number of pairing per application could be very
small.

-- Christian Huitema

---

From: Bob Bradley <[email-masked]>
Date: Mon, 11 Mar 2019 08:33:43 -0700

> On Mar 11, 2019, at 12:14 AM, Christian Huitema <[email-masked]> wrote:
> Using your numbers, there would be 12000 trial decryptions in approach 2 as well. Each client has to try 40 different server keys to see which one would work.
> 
I think it would be 480000 trial decryptions for approach 1 (12000 packets * 40 keys) and 12000 trial decryptions for approach 2 (300 packets * 40 keys).
> But I am not convinced at all that this 40/300 split is something we will see in privacy oriented applications. If we are looking at application pairing rather than device pairing, then the server and client role are very flexible, the ratio of client and server will be close to parity, and the number of pairing per application could be very small.
> 
Yes, my case may be higher than most. I can imagine the number of pairings growing as private, end-to-end communication becomes more prevalent.

The main difference I see between approaches for the server discovery phase is which key is used. Approach 1 encrypts to the server's key. Approach 2 signs with its own key. This difference requires approach 1 to multiply the number of multicast request packets it sends by the number of server keys it has.

Something to consider with approach 1 is using the client's discovery key in the first multicast request packet.This would avoid needing to send multiple multicast packets to discover servers.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 11 Mar 2019 11:05:43 -0700

On 3/11/2019 8:33 AM, Bob Bradley wrote:

>
> The main difference I see between approaches for the server discovery
> phase is which key is used. Approach 1 encrypts to the server's key.
> Approach 2 signs with its own key. This difference requires approach 1
> to multiply the number of multicast request packets it sends by the
> number of server keys it has.
>
> Something to consider with approach 1 is using the client's discovery
> key in the first multicast request packet.This would avoid needing to
> send multiple multicast packets to discover servers.

I think the use of server keys is more natural. There are many
deployments in which the server does not identify the individual
clients. I also think that for peer-to-peer applications it does not
matter, because each peer can act as either server or client depending
on circumstances.

When I look at this thread, I think that the "excessive multicast"
issues that you mention could be solved with a server broadcast message,
"server X is now present on this network". It would be secured with the
server discovery key, so only authorized clients would understand it.
But i am concerned that this is a high cost and high risk message. High
cost, because all clients need to run the trial description against all
server keys that they know about, which has an O(N^2) feeling. Even if
we discard the cost, the high risk is the replay attack.

Suppose that an attacker has identified a server, and is capable of
recording the broadcast announces from that server. The attacker can
then replay the message, triggering paired clients to attempt
communicating with the server. The attacker does not need to break any
key, it just takes note of the addresses of the device responding to the
server. I think we need a protection against the two variants of that
attack: replay at a different time; and, replay at a different location.

Of these, protection against replay in time is the easier -- just add a
time stamp in the server's announce, an program the clients to discard
old messages. Protection against replay at a different location would
require adding a location information in the server's announce, and have
clients discard the message if the location is not what they expect.
Maybe the server could just copy their IPv6 address, and the client
would be able to verify that the prefix is local.

The same replay attack is also possible with the "client hello" proposal
discussed in the draft, but the messages are much less powerful -- they
are meant to trigger just one answer from one targeted server, not N
answers from all the clients that happen to be present.

-- Christian Huitema