Re: [dnssd] dnssd privacy draft

[Tim Chown <[e-mail]>]

Hi,

> On 24 Jun 2016, at 20:26, Christian Huitema <[e-mail]> wrote:
> 
> 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.

On this, that’s a question to ask of the WG, but also of our AD. I think it’s very important that we tackle privacy issues as and when they arise, and thus this work is very welcome.

I hope that we can attract enough interest to progress it; the initial signs are encouraging. Our AD is very happy that we have identified and started this work. It’s possible he may feel there is a more appropriate WG to work on the problem. This is something we can discuss in Berlin, but for now let’s continue the discussion.

I sent a pointer to the work to the ietf-privacy list, which Stephen Farrell pointed me to - see https://www.ietf.org/mailman/listinfo/ietf-privacy. I encouraged people there to join dnssd to discuss the draft further.

BTW I noticed another draft that treads in similar space: draft-winfaa-intarea-broadcast-consider-02; I have emailed the authors to alert them to our work in dnssd, as it was not cited in their draft. 

Tim

>> 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
> 
> 
> 
> _______________________________________________
> dnssd mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnssd
>