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

[Bob Bradley <[e-mail]>]

> On Feb 27, 2019, at 6:04 PM, Christopher Wood <[e-mail]> wrote:
> 
> On Wed, Feb 27, 2019 at 5:58 PM Christian Huitema <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
> On 2/27/2019 5:40 PM, Christopher Wood wrote:
>> On Wed, Feb 27, 2019 at 5:37 PM Christian Huitema <[e-mail]> <mailto:[e-mail]> wrote:
>>> On 2/27/2019 4:48 PM, David Schinazi wrote:
>>> 
>>> <chair hat off>
>>> Given that our main target is local networks, I personally believe spending an extra round trip to prevent dictionary attacks sounds worth it.
>>> 
>>> I am thinking of using the ESNI extension, or developing a very similar extension specifically for the purpose of private discovery. The ESNI extension format is defined in https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1 <https://datatracker.ietf.org/doc/draft-ietf-tls-esni/?include_text=1> as:
>>> 
>>>       struct {
>>>           CipherSuite suite;
>>>           KeyShareEntry key_share;
>>>           opaque record_digest<0..216-1>;
>>>           opaque encrypted_sni<0..216-1>;
>>>       } ClientEncryptedSNI;
>>> 
>>> The service name is encrypted, but we would have to do something to not reveal the hash of the key in the "record digest".
>> This seems to highlight my main reservation about the 1-RTT approach.
>> I think we ought not to complicate things and just pay the round trip.
> My priority there is not the 1 RTT design, but rather the integration with TLS. I don't like coming up with a new crypto protocol, even when using well known patterns.
> 
> 
> That’s a fair concern. Note that I’m not advocating for something that’s not TLS. I’m simply advocating for something that’s not one stage.

I may be missing something, but the TLS/ESNI approach seems to assume you already know the peer you want to communicate with and their IP address to make a TLS connection. For local network communication, you would need some earlier message exchange, such as normal mDNS to discovery that info.

The main reason for the first message (multicast probe) in my proposal was to enable the initial discovery of peers (before any specific queries). Since that message needed to be sent anyway, before any unicast messages could be sent, it included an ephemeral key to also act as the first round of key exchange (1 multicast out, N unicast in).

Since I also wanted to keep the query itself confidential between the two peers (friend A can't decrypt my queries to friend B), the sender couldn't encrypt with its public key unless it include a separate, encrypted query for every peer in its database (likely prohibitive). Given those requirements, the initial multicast probe reduces the number of messages rather than adding additional round trips.
> As for the complication, the only requirement is to omit the record_digest, or redefine it to include a nonce. Apart from that the prototype can just reuse the existing code.
> 
> 
> The record digest is required to prevent downgrade attacks in the normal ESNI case. Depending on how the keys are installed, it may be fine to omit here. 
> 
> Can you please be specific for how you expect this optional nonce to work? It would help this discussion, I think.
> 
> Thanks,
> Chris
> 
> 
>