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

[Christopher Wood <[e-mail]>]

On Wed, Feb 27, 2019 at 4:31 PM Christopher Wood
<[e-mail]> wrote:
>
> On Wed, Feb 27, 2019 at 2:17 PM Christian Huitema <[e-mail]> wrote:
> >
> > OK. My next question is then how much commonality we want to have with TLS.
> >
> > All solutions in this space involve sending a broadcast query that asks
> > whether some peer is present. The query is secured using some secret
> > only known to the peers. From the previous discussions, we sort of
> > agreed that this secret should be a "discovery public key", with the
> > special twist that this public key should in fact be kept secret. The
> > exchange would typically be an ECDH exchange, something like that:
> >
> > * Client broadcast a query, containing its own ECDH half key, a nonce, a
> > proof, and possibly a hint.
> >
> > * The proof is secured by a "discovery secret", obtained by combining
> > the ECDH half key and the server's discovery key. The optional hint is a
> > cryptographic hash of the coarse time and the discovery secret
> >
> > * All servers get the message. If the hint is present they can verify
> > that the query targets them. If no hint is expected, or if the hint
> > matches, they compute the discovery secret and verify the nonce. If it
> > is not verified, they just drop the message.
> >
> > * The responding server confirms the connection, sends its own ECDH half
> > key, derives a handshake secret, etc.
> >
> > I notice that this is extremely similar to the TLS handshake, and
> > especially to the QUIC or DTLS handshakes when using ESNI encryption.
> > One simple way to deliver the functionality would be, just define a TLS
> > extension for the "discovery proof". And with that, we would have a
> > secure and private way to establish a DTLS session or a QUIC connection.
>
> 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.

Best,
Chris