Re: [dnssd] dnssd privacy draft

["Christian Huitema" <[e-mail]>]

On Thursday, June 23, 2016 5:23 PM, Martin Thomson wrote:
> 
> Interesting work.

Thanks.

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

Yes. The point is, do we have the appetite to design a pairing protocol in
this group? If we do, my preference would be to describe this pairing
protocol in a separate draft.

> 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.

It is already a requirement for DNS SD. There is a long discussion of that
in RFC 6763:

   The <Instance> portion of the Service Instance Name is a user-
   friendly name consisting of arbitrary Net-Unicode text [RFC5198].  It
   MUST NOT contain ASCII control characters (byte values 0x00-0x1F and
   0x7F) [RFC20] but otherwise is allowed to contain any characters,
   without restriction, including spaces, uppercase, lowercase,
   punctuation -- including dots -- accented characters, non-Roman text,
   and anything else that may be represented using Net-Unicode.  For
   discussion of why the <Instance> name should be a user-visible, user-
   friendly name rather than an invisible machine-generated opaque
   identifier, see Appendix C, "What You See Is What You Get".

Base64 guarantees that we will not be using control characters. I actually
checked whether we could get something more compact using a wider range of
Unicode character, but those require more bits on the wire and end up not
very efficient.

> 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?

Yes, that's a possibility. But the instance name is obtained directly from
the PTR record. Putting the information in the TXT record implies a longer
query process: first get the PTR records, then retrieve the TXT record for
each name in the PTR record. 

> 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.

Are you saying that specifically for the PSK identity encoding? The use of
time stamp there provides some level of protection against replay attacks,
described in section 6.5. Otherwise, servers will have to rely on extended
memory of previously used PSK identifiers.

> Also, you don't have to base64 the psk_identity, it's just octets, which
allows
> you to reclaim some of that space.

Well, section 5.1. of RFC4279 says: "The PSK identity MUST be first
converted to a character string, and then encoded to octets using UTF-8
[UTF8]." And I see the character string requirement enforced in some of the
TLS API. So base64 is just a way of being cautious.

> 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.

Good point. We should probably specify some fixed SNI value, so the SNI does
not leak server identity.

> 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.

Yes, we need to think about versioning. The simplest solution is probably to
encode a version number in the service type used by DNS SD. But better
suggestions are welcome.

-- Christian Huitema