Subject: Re: [dnssd] dnssd privacy draft

From: Daniel Kaiser <[email-masked]>
Date: Tue, 5 Jul 2016 06:58:38 +0200

We already took the SIGMA-protocols, which IKE is based on, into
consideration. The method proposed in rfc4322 depends on keys
retrievable via DNS and on DNSSEC; I think configuring this would pose
to much overhead.
Further, rfc4322 proposes means for opportunistic encryption which is
not what we want as a means for establishing a pairing. For a pairing,
the users should authenticate each other.

As of yet, we have mainly discussed means of pairing for users meeting
in person; in this scenario, authentication can be easily performed by
verifying a fingerprint. Users are already used to this workflow when
using chat applications like "Signal".

To offer the possibility of zero configuration pairing,
we discussed using a pairing service announced via mDNS in trusted
networks (e.g. at home).

kind regards
Daniel

On 06/27/2016 06:17 AM, Alf Watt wrote:
> Opportunistic Encryption using the Internet Key Exchange (IKE) might be suitable for the purposes proposed here.
> 
>  https://tools.ietf.org/html/rfc4322
> 
> Best,
> Alf
> 
>> On Jun 26, 2016, at 5:32 PM, Martin Thomson <[email-masked]> wrote:
>>
>> On 25 June 2016 at 05:26, Christian Huitema <[email-masked]> wrote:
>>> 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.
>>
>> Sounds like hard work :)  Might be worth doing though.
> 
> _______________________________________________
> dnssd mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnssd
>

---

From: Martin Thomson <[email-masked]>
Date: Tue, 12 Jul 2016 11:38:24 +1000

> using chat applications like "Signal".

Is that really what happens here, or is it more of a leap of faith?

---

From: Tim Chown <[email-masked]>
Date: Tue, 12 Jul 2016 08:40:51 +0000

Hi,

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

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