[dnssd] dnssd privacy draft

[Martin Thomson <[e-mail]>]

Interesting work.

I think that a lot of this comes down to the design of the pairing protocol.

The requirement to use base64 isn't going to work very well with DNS.
Or do you expect this to work anyway?  I guess that it could if you
use the URL and filename safe variant without padding, but I wouldn't
have been that bold.

Using base32 reduces the number of pairings you can advertise at once
to 5; which isn't great, but I guess that you can use the mitigation
you already have.  But it begs the question: does this really need to
be in the name?  Did you consider retrieving the proofs using TXT
records that are provisioned against the nonce?

Do you need to include the time in the nonce?  We decided against
leaking clock information in TLS 1.3 for a range of reasons, primarily
privacy.  I believe that lots of entropy would be OK.  It's not like
we need to be very careful with space, and 96 bits seems like plenty.
Also, you don't have to base64 the psk_identity, it's just octets,
which allows you to reclaim some of that space.

Did you consider using SNI to carry the name?  Or did you plan to
forbid SNI?  You probably don't need to correlate the DNSSD parts with
the TLS parts for passive observers.

Regarding this: "Implementers MAY eventually replace SHA256 with a
stronger algorithm", I think that you need a better replacement plan.
Maybe you can use an attribute in the TXT record that identifies the
hash.  Or you could identify the scheme in the psk_identity itself.
Or you could prefix names with a protocol version identifier.  You
could even use a different service type name if it came to that.