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

[Christian Huitema <[e-mail]>]

On 2/27/2019 6:04 PM, Christopher Wood 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 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.

In the ESNI design, the digest is used to verify that the client is
using the published keys and algorithms. We are concerned that DNS
spoofing could enable a downgrade attack, e.g. using an old key now
deemed insecure, or using the same key but with downgraded parameters.
The digest protects the integrity of the transmission between DNS server
and client. Since we don't plan using the DNS, we do not really have
that concern.

In the discussions in Bangkok, we mentioned a "hint", so servers could
rapidly discard requests that are "not for me". In the old proposal, the
nonce was the truncated 64 bit Unix time -- setting the 5 least
significant bits to zero -- and the proof was a hash of the 7 bytes and
the shared secret -- in our case, that would be the public key of the
server. The nonce only changes every 30 seconds or so. Servers have to
compute that proof only once every 30 seconds, which limits the
potential for DOS attacks.

The clients compute the nonce before sending the message. The server
evaluate first whether the nonce has the right format, starts with the
truncated current time plus or minus some estimate of clock drift. If
that passes, the server compares to the pre-computed proof, or compute
it if the clock is in a new interval. If that passes, the server
processes with ESNI decryption, and verifies that the service name is
what it expects.

Of course, we could assume that the discovery key is passed to the peer
in exactly the same format as ESNI:

    struct {
        uint8 checksum[4];
        KeyShareEntry keys<4..2^16-1>;
        CipherSuite cipher_suites<2..2^16-2>;
        uint16 padded_length;
        uint64 not_before;
        uint64 not_after;
        Extension extensions<0..2^16-1>;
    } ESNIKeys;

Hashing that with the nonce will alleviate concerns about clients using
the wrong cipher suite, or the wrong padding length.

-- Christian Huitema