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

[Christian Huitema <[e-mail]>]

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