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

[Christian Huitema <[e-mail]>]

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". The digest is used by
servers to quickly identify the public key needed to encrypt the service
name, and we don't want that. KeyShareEntry is very much the same
element as the "ephemeral client key" in Bob's draft.

The encrypted structure contains:

      struct {
          ServerNameList sni;
          opaque zeros[ESNIKeys.padded_length - length(sni)];
      } PaddedServerNameList;

      struct {
          uint8 nonce[16];
          PaddedServerNameList realSNI;
      } ClientESNIInner;

Only the server can decrypt that, and echo the nonce in the encrypted
server extension. The Service Name Identification is not sent in the clear.

-- Christian Huitema