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

[Christopher Wood <[e-mail]>]

On Wed, Feb 27, 2019 at 5:58 PM Christian Huitema <[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]> <[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 as:
>
>       struct {
>           CipherSuite suite;
>           KeyShareEntry key_share;
>           opaque record_digest<0..2^16-1>;
>           opaque encrypted_sni<0..2^16-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.

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