Subject: [dnssd] dnssd privacy draft

From: Martin Thomson <[email-masked]>
Date: Fri, 24 Jun 2016 10:23:09 +1000

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.

---

From: "Christian Huitema" <[email-masked]>
Date: Fri, 24 Jun 2016 12:26:34 -0700

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

> 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

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Jun 2016 10:32:26 +1000

> protocol in a separate draft.

Sounds like hard work :)  Might be worth doing though.

> It is already a requirement for DNS SD.

OK, my fault for assuming that PTR meant that there was a domain name
in the response.

> memory of previously used PSK identifiers.

What sort of replay are you concerned about?  An attacker can replay
the ClientHello, and maybe the 0-RTT data that is included, but that's
all.  The simplest mitigation for that is to not permit 0-RTT; well,
on the first attempt anyway.  At that point, there is fresh entropy
from the server every time.

(I assume here that you aren't looking to aggressively shave every
last RTT from the protocol; you just added a bunch with the
indirection step.)

(That point on resumption makes me think: you might want to add a
fixed octet at the start of psk_identity so that a server can
distinguish between nonces and its own resumption psk_identity values.
It could distinguish based on length, I suppose, but that is a little
inconvenient.)

> TLS API. So base64 is just a way of being cautious.

Damn you 4279 for adding useless constraints!  TLS 1.3 says nothing of
the sort about the field.  Nonetheless, I understand the caution now.

---

From: Alf Watt <[email-masked]>
Date: Sun, 26 Jun 2016 21:17:58 -0700

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

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 26 Jun 2016 21:24:31 -0700

> from the server every time.

I am concerned with the privacy issue. Suppose I contact a server and send a
Client-Hello with a PSK Identity. If the identity is valid, the servers
replies with Server-Hello. If the identity is incorrect, server will reject
the connection, maybe sending an Alert. Suppose now that the Client hello is
a Replay from some exchange I monitored previously. If I see a Server Hello
coming back, I know this is the same server that I observed before. Hence,
linkability.

-- Christian Huitema

---

From: Martin Thomson <[email-masked]>
Date: Mon, 27 Jun 2016 14:58:58 +1000

> coming back, I know this is the same server that I observed before. Hence,

I see.

You could include some material from the instance name in the
calculation of the MAC that you are using for psk_identity.  Then if
the server moves, it's name will change, as will what it considers to
be a valid handshake.