-
Notifications
You must be signed in to change notification settings - Fork 2
/
Copy pathdraft-ietf-dnssd-privacy-02.txt
1344 lines (910 loc) · 54.7 KB
/
draft-ietf-dnssd-privacy-02.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Network Working Group C. Huitema
Internet-Draft Private Octopus Inc.
Intended status: Standards Track D. Kaiser
Expires: January 4, 2018 University of Konstanz
July 3, 2017
Privacy Extensions for DNS-SD
draft-ietf-dnssd-privacy-02.txt
Abstract
DNS-SD (DNS Service Discovery) normally discloses information about
both the devices offering services and the devices requesting
services. This information includes host names, network parameters,
and possibly a further description of the corresponding service
instance. Especially when mobile devices engage in DNS Service
Discovery over Multicast DNS at a public hotspot, a serious privacy
problem arises.
We propose to solve this problem by a two-stage approach. In the
first stage, hosts discover Private Discovery Service Instances via
DNS-SD using special formats to protect their privacy. These service
instances correspond to Private Discovery Servers running on peers.
In the second stage, hosts directly query these Private Discovery
Servers via DNS-SD over TLS. A pairwise shared secret necessary to
establish these connections is only known to hosts authorized by a
pairing system.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018.
Huitema & Kaiser Expires January 4, 2018 [Page 1]
Internet-Draft DNS-SD Privacy Extensions July 2017
Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
2. Privacy Implications of DNS-SD . . . . . . . . . . . . . . . 4
2.1. Privacy Implication of Publishing Service Instance Names 4
2.2. Privacy Implication of Publishing Node Names . . . . . . 5
2.3. Privacy Implication of Publishing Service Attributes . . 5
2.4. Device Fingerprinting . . . . . . . . . . . . . . . . . . 6
2.5. Privacy Implication of Discovering Services . . . . . . . 7
3. Design of the Private DNS-SD Discovery Service . . . . . . . 7
3.1. Device Pairing . . . . . . . . . . . . . . . . . . . . . 8
3.2. Discovery of the Private Discovery Service . . . . . . . 8
3.2.1. Obfuscated Instance Names . . . . . . . . . . . . . . 9
3.2.2. Using a Predictable Nonce . . . . . . . . . . . . . . 9
3.2.3. Using a Short Proof . . . . . . . . . . . . . . . . . 10
3.2.4. Direct Queries . . . . . . . . . . . . . . . . . . . 12
3.3. Private Discovery Service . . . . . . . . . . . . . . . . 12
3.3.1. A Note on Private DNS Services . . . . . . . . . . . 13
3.4. Randomized Host Names . . . . . . . . . . . . . . . . . . 14
3.5. Timing of Obfuscation and Randomization . . . . . . . . . 14
4. Private Discovery Service Specification . . . . . . . . . . . 14
4.1. Host Name Randomization . . . . . . . . . . . . . . . . . 15
4.2. Device Pairing . . . . . . . . . . . . . . . . . . . . . 15
4.3. Private Discovery Server . . . . . . . . . . . . . . . . 15
4.3.1. Establishing TLS Connections . . . . . . . . . . . . 16
4.4. Publishing Private Discovery Service Instances . . . . . 16
4.5. Discovering Private Discovery Service Instances . . . . . 17
4.6. Direct Discovery of Private Discovery Service Instances . 18
4.7. Using the Private Discovery Service . . . . . . . . . . . 18
5. Security Considerations . . . . . . . . . . . . . . . . . . . 18
5.1. Attacks Against the Pairing System . . . . . . . . . . . 19
5.2. Denial of Discovery of the Private Discovery Service . . 19
Huitema & Kaiser Expires January 4, 2018 [Page 2]
Internet-Draft DNS-SD Privacy Extensions July 2017
5.3. Replay Attacks Against Discovery of the Private Discovery
Service . . . . . . . . . . . . . . . . . . . . . . . . . 19
5.4. Denial of Private Discovery Service . . . . . . . . . . . 20
5.5. Replay Attacks against the Private Discovery Service . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
1. Introduction
DNS-SD [RFC6763] over mDNS [RFC6762] enables configurationless
service discovery in local networks. It is very convenient for
users, but it requires the public exposure of the offering and
requesting identities along with information about the offered and
requested services. Parts of the published information can seriously
breach the user's privacy. These privacy issues and potential
solutions are discussed in [KW14a] and [KW14b].
There are cases when nodes connected to a network want to provide or
consume services without exposing their identity to the other parties
connected to the same network. Consider for example a traveler
wanting to upload pictures from a phone to a laptop when connected to
the Wi-Fi network of an Internet cafe, or two travelers who want to
share files between their laptops when waiting for their plane in an
airport lounge.
We expect that these exchanges will start with a discovery procedure
using DNS-SD [RFC6763] over mDNS [RFC6762]. One of the devices will
publish the availability of a service, such as a picture library or a
file store in our examples. The user of the other device will
discover this service, and then connect to it.
When analyzing these scenarios in Section 2, we find that the DNS-SD
messages leak identifying information such as the instance name, the
host name or service properties. We review the design constraint of
a solution in Section 3, and describe the proposed solution in
Section 4.
While we focus on a mDNS-based distribution of the DNS-SD resource
records, our solution is agnostic about the distribution method and
also works with other distribution methods, e.g. the classical
hierarchical DNS.
Huitema & Kaiser Expires January 4, 2018 [Page 3]
Internet-Draft DNS-SD Privacy Extensions July 2017
1.1. Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Privacy Implications of DNS-SD
DNS-Based Service Discovery (DNS-SD) is defined in [RFC6763]. It
allows nodes to publish the availability of an instance of a service
by inserting specific records in the DNS ([RFC1033], [RFC1034],
[RFC1035]) or by publishing these records locally using multicast DNS
(mDNS) [RFC6762]. Available services are described using three types
of records:
PTR Record: Associates a service type in the domain with an
"instance" name of this service type.
SRV Record: Provides the node name, port number, priority and weight
associated with the service instance, in conformance with
[RFC2782].
TXT Record: Provides a set of attribute-value pairs describing
specific properties of the service instance.
In the remaining subsections, we will review the privacy issues
related to publishing instance names, node names, service attributes
and other data, as well as review the implications of using the
discovery service as a client.
2.1. Privacy Implication of Publishing Service Instance Names
In the first phase of discovery, the client obtains all the PTR
records associated with a service type in a given naming domain.
Each PTR record contains a Service Instance Name defined in Section 4
of [RFC6763]:
Service Instance Name = <Instance> . <Service> . <Domain>
The <Instance> portion of the Service Instance Name is meant to
convey enough information for users of discovery clients to easily
select the desired service instance. Nodes that use DNS-SD over mDNS
[RFC6762] in a mobile environment will rely on the specificity of the
instance name to identify the desired service instance. In our
example of users wanting to upload pictures to a laptop in an
Internet Cafe, the list of available service instances may look like:
Huitema & Kaiser Expires January 4, 2018 [Page 4]
Internet-Draft DNS-SD Privacy Extensions July 2017
Alice's Images . _imageStore._tcp . local
Alice's Mobile Phone . _presence._tcp . local
Alice's Notebook . _presence._tcp . local
Bob's Notebook . _presence._tcp . local
Carol's Notebook . _presence._tcp . local
Alice will see the list on her phone and understand intuitively that
she should pick the first item. The discovery will "just work".
However, DNS-SD/mDNS will reveal to anybody that Alice is currently
visiting the Internet Cafe. It further discloses the fact that she
uses two devices, shares an image store, and uses a chat application
supporting the _presence protocol on both of her devices. She might
currently chat with Bob or Carol, as they are also using a _presence
supporting chat application. This information is not just available
to devices actively browsing for and offering services, but to
anybody passively listing to the network traffic.
2.2. Privacy Implication of Publishing Node Names
The SRV records contain the DNS name of the node publishing the
service. Typical implementations construct this DNS name by
concatenating the "host name" of the node with the name of the local
domain. The privacy implications of this practice are reviewed in
[RFC8117]. Depending on naming practices, the host name is either a
strong identifier of the device, or at a minimum a partial
identifier. It enables tracking of both the device, and, by
extension, the device's owner.
2.3. Privacy Implication of Publishing Service Attributes
The TXT record's attribute-value pairs contain information on the
characteristics of the corresponding service instance. This in turn
reveals information about the devices that publish services. The
amount of information varies widely with the particular service and
its implementation:
o Some attributes like the paper size available in a printer, are
the same on many devices, and thus only provide limited
information to a tracker.
o Attributes that have freeform values, such as the name of a
directory, may reveal much more information.
Combinations of attributes have more information power than specific
attributes, and can potentially be used for "fingerprinting" a
specific device.
Huitema & Kaiser Expires January 4, 2018 [Page 5]
Internet-Draft DNS-SD Privacy Extensions July 2017
Information contained in TXT records does not only breach privacy by
making devices trackable, but might directly contain private
information about the user. For instance the _presence service
reveals the "chat status" to everyone in the same network. Users
might not be aware of that.
Further, TXT records often contain version information about services
allowing potential attackers to identify devices running exploit-
prone versions of a certain service.
2.4. Device Fingerprinting
The combination of information published in DNS-SD has the potential
to provide a "fingerprint" of a specific device. Such information
includes:
o The list of services published by the device, which can be
retrieved because the SRV records will point to the same host
name.
o The specific attributes describing these services.
o The port numbers used by the services.
o The values of the priority and weight attributes in the SRV
records.
This combination of services and attributes will often be sufficient
to identify the version of the software running on a device. If a
device publishes many services with rich sets of attributes, the
combination may be sufficient to identify the specific device.
A sometimes heard argument is that devices providing services can be
identified by observing the local traffic, and that trying to hide
the presence of the service is futile. This argument, however, does
not carry much weight because
1. proving privacy at the discovery layer is of the essence for
enabling automatically configured privacy-preserving network
applications. Application layer protocols are not forced to
leverage the offered privacy, but if device tracking is not
prevented at the deeper layers, including the service discovery
layer, obfuscating a certain service's protocol at the
application layer is futile.
2. Further, even if the application layer does not protect privacy,
it is hard to record and analyse the unicast traffic (which most
Huitema & Kaiser Expires January 4, 2018 [Page 6]
Internet-Draft DNS-SD Privacy Extensions July 2017
applications will generate) compared to just listening to the
multicast messages sent by DNS-SD/mDNS.
The same argument can be extended to say that the pattern of services
offered by a device allows for fingerprinting the device. This may
or may not be true, since we can expect that services will be
designed or updated to avoid leaking fingerprints. In any case, the
design of the discovery service should avoid making a bad situation
worse, and should as much as possible avoid providing new
fingerprinting information.
2.5. Privacy Implication of Discovering Services
The consumers of services engage in discovery, and in doing so reveal
some information such as the list of services they are interested in
and the domains in which they are looking for the services. When the
clients select specific instances of services, they reveal their
preference for these instances. This can be benign if the service
type is very common, but it could be more problematic for sensitive
services, such as for example some private messaging services.
One way to protect clients would be to somehow encrypt the requested
service types. Of course, just as we noted in Section 2.4, traffic
analysis can often reveal the service.
3. Design of the Private DNS-SD Discovery Service
In this section, we present the design of a two-stage solution that
enables private use of DNS-SD, without affecting existing users. The
solution is largely based on the architecture proposed in [KW14b],
which separates the general private discovery problem in three
components. The first component is an offline pairing mechanism,
which is performed only once per pair of users. It establishes a
shared secret over an authenticated channel, allowing devices to
authenticate using this secret without user interaction at any later
point in time. We use the pairing system proposed in
[I-D.ietf-dnssd-pairing].
The further two components are online (in contrast to pairing they
are performed anew each time joining a network) and compose the two
service discovery stages, namely
o Discovery of the Private Discovery Service -- the first stage --
in which hosts discover the Private Discovery Service (PDS), a
special service offered by every host supporting our extension.
After the discovery, hosts connect to the PSD offered by paired
peers.
Huitema & Kaiser Expires January 4, 2018 [Page 7]
Internet-Draft DNS-SD Privacy Extensions July 2017
o Actual Service Discovery -- the second stage -- is performed
through the Private Discovery Service, which only accepts
encrypted messages associated with an authenticated session; thus
not compromising privacy.
In other words, the hosts first discover paired peers and then
directly engage in privacy preserving service discovery.
The stages are independent with respect to means used for
transmitting the necessary data. While in our extension the messages
for the first stage are transmitted using IP multicast, the messages
for the second stage are transmitted via unicast. One could also
imagine using a Distributed Hash Table for the first stage, being
completely independent of multicast.
3.1. Device Pairing
Any private discovery solution needs to differentiate between
authorized devices, which are allowed to get information about
discoverable entities, and other devices, which should not be aware
of the availability of private entities. The commonly used solution
to this problem is establishing a "device pairing".
Device pairing has to be performed only once per pair of users. This
is important for user-friendliness, as it is the only step that
demands user-interaction. After this single pairing, privacy
preserving service discovery works fully automatically. In this
document, we utilize [I-D.ietf-dnssd-pairing] as the pairing
mechanism.
The pairing yields a mutually authenticated shared secret, and
optionally mutually authenticated public keys or certificates added
to a local web of trust. Public key technology has many advantages,
but shared secrets are typically easier to handle on small devices.
3.2. Discovery of the Private Discovery Service
The first stage of service discovery is to check whether instances of
compatible Private Discovery Services are available in the local
scope. The goal of that stage is to identify devices that share a
pairing with the querier, and are available locally. The service
instances can be discovered using regular DNS-SD procedures, but the
list of discovered services will have to be filtered so only paired
devices are retained.
Huitema & Kaiser Expires January 4, 2018 [Page 8]
Internet-Draft DNS-SD Privacy Extensions July 2017
3.2.1. Obfuscated Instance Names
The instance names for the Private Discovery Service are obfuscated,
so that authorized peers can associate the instance with its
publisher, but unauthorized peers can only observe what looks like a
random name. To achieve this, the names are composed as the
concatenation of a nonce and a proof, which is composed by hashing
the nonce with a pairing key:
PrivateInstanceName = <nonce>|<proof>
proof = hash(<nonce>|<key>)
The publisher will publish as many instances as it has established
pairings.
The discovering party that looks for instances of the service will
receive lists of advertisements from nodes present on the network.
For each advertisement, it will parse the instance name, and then,
for each available pairing key, compares the proof to the hash of the
nonce concatenated with this pairing key. If there is no match, it
discards the instance name. If there is a match, it has discovered a
peer.
3.2.2. Using a Predictable Nonce
Assume that there are N nodes on the local scope, and that each node
has on average M pairings. Each node will publish on average M
records, and the node engaging in discovery may have to process on
average N*M instance names. The discovering node will have to
compute on average M potential hashes for each nonce. The number of
hash computations would scale as O(N*M*M), which means that it could
cause a significant drain of resource in large networks.
In order to minimize the amount of computing resource, we suggest
that the nonce be derived from the current time, for example set to a
representation of the current time rounded to some period. With this
convention, receivers can predict the nonces that will appear in the
published instances.
The publishers will have to create new records at the end of each
rounding period. If the rounding period is set too short, they will
have to repeat that very often, which is inefficient. On the other
hand, if the rounding period is too long, the system may be exposed
to replay attacks. We propose to set a value of about 5 minutes,
which seems to be a reasonable compromise.
Receivers can pre-calculate all the M relevant proofs once per time
interval and then establish a mapping from the corresponding instance
Huitema & Kaiser Expires January 4, 2018 [Page 9]
Internet-Draft DNS-SD Privacy Extensions July 2017
names to the pairing data in form of a hash table. These M relevant
proofs are the proofs resulting from hashing a host's M pairing keys
alongside the current nonce. Each time they receive an instance
name, they can test in O(1) time if the received service information
is relevant or not.
Unix defines a 32 bit time stamp as the number of seconds elapsed
since January 1st, 1970 not counting leap seconds. The most
significant 24 bits of this 32 bit number represent the number of 256
seconds intervals since the epoch. 256 seconds correspond to 4
minutes and 16 seconds, which is close enough to our design goal of 5
minutes. We will thus use this 24 bit number as nonce, represented
as 3 octets.
For coping with time skew, receivers pre-calculate proofs for the
respective next time interval and store hash tables for the last, the
current, and the next time interval. When receiving a service
instance name, receivers first check whether the nonce corresponds to
the current, the last or the next time interval, and if so, check
whether the instance name is in the corresponding hash table. For
(approximately) meeting our design goal of 5 min validity, the last
time interval may only be considered if the current one is less than
half way over and the next time interval may only be considered if
the current time interval is more than half way over.
Publishers will need to compute O(M) hashes at most once per time
stamp interval. If records can be created "on the fly", publishers
will only need to perform that computation upon receipt of the first
query during a given interval, and cache the computed results for the
remainder of the interval. There are however scenarios in which
records have to be produced in advance, for example when records are
published within a scope defined by a domain name and managed by a
"classic" DNS server. In such scenarios, publishers will need to
perform the computations and publication exactly once per time stamp
interval.
3.2.3. Using a Short Proof
Devices will have to publish as many instance names as they have
peers. The instance names will have to be represented via a text
string, which means that the binary concatenation of nonce and proof
will have to be encoded using a binary-to-text conversion such as
BASE64 ([RFC2045] section 6.8) or BASE32 ([RFC4648] section 6).
Using long proofs, such as the full output of SHA256 [RFC4055], would
generate fairly long instance names: 48 characters using BASE64, or
56 using BASE32. These long names would inflate the network traffic
required when discovering the privacy service. They would also limit
Huitema & Kaiser Expires January 4, 2018 [Page 10]
Internet-Draft DNS-SD Privacy Extensions July 2017
the number of DNS-SD PTR records that could be packed in a single
1500 octet sized packet, to 23 or fewer with BASE64, or 20 or fewer
with BASE32.
Shorter proofs lead to shorter messages, which is more efficient as
long as we do not encounter too many collisions. A collision will
happen if the proof computed by the publisher using one key matches a
proof computed by a receiver using another key. If a receiver
mistakenly believes that a proof fits one of its peers, it will
attempt to connect to the service as explained in section Section 4.5
but in the absence of the proper pairwise shared key, the connection
will fail. This will not create an actual error, but the probability
of such events should be kept low.
The following table provides the probability that a discovery agent
maintaining 100 pairings will observe a collision after receiving
100000 advertisement records. It also provides the number of
characters required for the encoding of the corresponding instance
name in BASE64 or BASE32, assuming 24 bit nonces.
+-------+------------+--------+--------+
| Proof | Collisions | BASE64 | BASE32 |
+-------+------------+--------+--------+
| 24 | 5.96046% | 8 | 16 |
| 32 | 0.02328% | 11 | 16 |
| 40 | 0.00009% | 12 | 16 |
| 48 | 3.6E-09 | 12 | 16 |
| 56 | 1.4E-11 | 15 | 16 |
+-------+------------+--------+--------+
Table 1
The table shows that for a proof, 24 bits would be too short. 32 bits
might be long enough, but the BASE64 encoding requires padding if the
input is not an even multiple of 24 bits, and BASE32 requires padding
if the input is not a multiple of 40 bits. Given that, the desirable
proof lengths are thus 48 bits if using BASE64, or 56 bits if using
BASE32. The resulting instance name will be either 12 characters
long with BASE64, allowing 54 advertisements in an 1500 byte mDNS
message, or 16 characters long with BASE32, allowing 47
advertisements per message.
In the specification section, we will assume BASE64, and 48 bit
proofs composed of the first 6 bytes of a SHA256 hash.
Huitema & Kaiser Expires January 4, 2018 [Page 11]
Internet-Draft DNS-SD Privacy Extensions July 2017
3.2.4. Direct Queries
The preceding sections assume that the discovery is performed using
the classic DNS-SD process, in which a query for all available
"instance names" of a service provides a list of PTR records. The
discoverer will then select the instance names that correspond to its
peers, and request the SRV and TXT records corresponding to the
service instance, and then obtain the relevant A or AAAA records.
This is generally required in DNS-SD because the instance names are
not known in advance, but for the Private Discovery Service the
instance names can be predicted, and a more efficient Direct Query
method can be used.
At a given time, the node engaged in discovery can predict the nonce
that its peer will use, since that nonce is composed by rounding the
current time. The node can also compute the proofs that its peers
might use, since it knows the nonce and the keys. The node can thus
build a list of instance names, and directly query the SRV records
corresponding to these names. If peers are present, they will answer
directly.
This "direct query" process will result in fewer network messages
than the regular DNS-SD query process in some circumstances,
depending on the number of peers per node and the number of nodes
publishing the presence discovery service in the desired scope.
When using mDNS, it is possible to pack multiple queries in a single
broadcast message. Using name compression and 12 characters per
instance name, it is possible to pack 70 queries in a 1500 octet mDNS
multicast message. It is also possible to request unicast replies to
the queries, resulting in significant efficiency gains in wireless
networks.
3.3. Private Discovery Service
The Private Discovery Service discovery allows discovering a list of
available paired devices, and verifying that either party knows the
corresponding shared secret. At that point, the querier can engage
in a series of directed discoveries.
We have considered defining an ad-hoc protocol for the private
discovery service, but found that just using TLS would be much
simpler. The directed Private Discovery Service is just a regular
DNS-SD service, accessed over TLS, using the encapsulation of DNS
over TLS defined in [RFC7858]. The main difference with plain DNS
over TLS is the need for authentication.
Huitema & Kaiser Expires January 4, 2018 [Page 12]
Internet-Draft DNS-SD Privacy Extensions July 2017
We assume that the pairing process has provided each pair of
authorized client and server with a shared secret. We can use that
shared secret to provide mutual authentication of clients and servers
using "Pre-Shared Key" authentication, as defined in [RFC4279] and
incorporated in the latest version of TLS [I-D.ietf-tls-tls13].
One difficulty is the reliance on a key identifier in the protocol.
For example, in TLS 1.3 the PSK extension is defined as:
opaque psk_identity<0..2^16-1>;
struct {
select (Role) {
case client:
psk_identity identities<2..2^16-1>;
case server:
uint16 selected_identity;
}
} PreSharedKeyExtension
According to the protocol, the PSK identity is passed in clear text
at the beginning of the key exchange. This is logical, since server
and clients need to identify the secret that will be used to protect
the connection. But if we used a static identifier for the key,
adversaries could use that identifier to track server and clients.
The solution is to use a time-varying identifier, constructed exactly
like the "proof" described in Section 3.2, by concatenating a nonce
and the hash of the nonce with the shared secret.
3.3.1. A Note on Private DNS Services
Our solution uses a variant of the DNS over TLS protocol [RFC7858]
defined by the DNS Private Exchange working group (DPRIVE). DPRIVE
further published an UDP variant, DNS over DTLS [RFC8094], which
would also be a candidate.
DPRIVE and Private Discovery solve however two somewhat different
problems. DPRIVE is concerned with the confidentiality of DNS
transactions, addressing the problems outlined in [RFC7626].
However, DPRIVE does not address the confidentiality or privacy
issues with publication of services, and is not a direct solution to
DNS-SD privacy:
o Discovery queries are scoped by the domain name within which
services are published. As nodes move and visit arbitrary
networks, there is no guarantee that the domain services for these
networks will be accessible using DNS over TLS or DNS over DTLS.
Huitema & Kaiser Expires January 4, 2018 [Page 13]
Internet-Draft DNS-SD Privacy Extensions July 2017
o Information placed in the DNS is considered public. Even if the
server does support DNS over TLS, third parties will still be able
to discover the content of PTR, SRV and TXT records.
o Neither DNS over TLS nor DNS over DTLS applies to MDNS.
In contrast, we propose using mutual authentication of the client and
server as part of the TLS solution, to ensure that only authorized
parties learn the presence of a service.
3.4. Randomized Host Names
Instead of publishing their actual host names in the SRV records,
nodes could publish randomized host names. That is the solution
argued for in [RFC8117].
Randomized host names will prevent some of the tracking. Host names
are typically not visible by the users, and randomizing host names
will probably not cause much usability issues.
3.5. Timing of Obfuscation and Randomization
It is important that the obfuscation of instance names is performed
at the right time, and that the obfuscated names change in synchrony
with other identifiers, such as MAC Addresses, IP Addresses or host
names. If the randomized host name changed but the instance name
remained constant, an adversary would have no difficulty linking the
old and new host names. Similarly, if IP or MAC addresses changed
but host names remained constant, the adversary could link the new
addresses to the old ones using the published name.
The problem is handled in [RFC8117], which recommends to pick a new
random host name at the time of connecting to a new network. New
instance names for the Private Discovery Services should be composed
at the same time.
4. Private Discovery Service Specification
The proposed solution uses the following components:
o Host name randomization to prevent tracking.
o Device pairing yielding pairwise shared secrets.
o A Private Discovery Server (PDS) running on each host.
o Discovery of the PDS instances using DNS-SD.
Huitema & Kaiser Expires January 4, 2018 [Page 14]
Internet-Draft DNS-SD Privacy Extensions July 2017
These components are detailed in the following subsections.
4.1. Host Name Randomization
Nodes publishing services with DNS-SD and concerned about their
privacy MUST use a randomized host name. The randomized name MUST be
changed when network connectivity changes, to avoid the correlation
issues described in Section 3.5. The randomized host name MUST be
used in the SRV records describing the service instance, and the
corresponding A or AAAA records MUST be made available through DNS or
MDNS, within the same scope as the PTR, SRV and TXT records used by
DNS-SD.
If the link-layer address of the network connection is properly
obfuscated (e.g. using MAC Address Randomization), the Randomized
Host Name MAY be computed using the algorithm described in section
3.7 of [RFC7844]. If this is not possible, the randomized host name
SHOULD be constructed by simply picking a 48 bit random number
meeting the Randomness Requirements for Security expressed in
[RFC4075], and then use the hexadecimal representation of this number
as the obfuscated host name.
4.2. Device Pairing
Nodes that want to leverage the Private Directory Service for private
service discovery among peers MUST share a secret with each of these
peers. Each shared secret MUST be a 256 bit randomly chosen number.
We RECOMMEND using the pairing mechanism proposed in
[I-D.ietf-dnssd-pairing] to establish these secrets.
[[TODO: Should we support mutually authenticated certificates? They
can also be used to initiate TLS and have several advantages, i.e.
allow setting an expiry date.]]
4.3. Private Discovery Server
A Private Discovery Server (PDS) is a minimal DNS server running on
each host. Its task is to offer resource records corresponding to
private services only to authorized peers. These peers MUST share a
secret with the host (see Section 4.2). To ensure privacy of the
requests, the service is only available over TLS [RFC5246], and the
shared secrets are used to mutually authenticate peers and servers.
The Private Name Server SHOULD support DNS push notifications
[I-D.ietf-dnssd-push], e.g. to facilitate an up-to-date contact list
in a chat application without polling.
Huitema & Kaiser Expires January 4, 2018 [Page 15]
Internet-Draft DNS-SD Privacy Extensions July 2017
4.3.1. Establishing TLS Connections
The PDS MUST only answer queries via DNS over TLS [RFC7858] and MUST
use a PSK authenticated TLS handshake [RFC4279]. The client and
server SHOULD negotiate a forward secure cipher suite such as DHE-PSK
or ECDHE-PSK when available. The shared secret exchanged during
pairing MUST be used as PSK. To guarantee interoperability,
implementations of the Private Name Server MUST support
TLS_PSK_WITH_AES_256_GCM_SHA384.
When using the PSK based authentication, the "psk_identity" parameter
identifying the pre-shared key MUST be identical to the "Instance
Identifier" defined in Section 4.4, i.e. 24 bit nonce and 48 bit
proof encoded in BASE64 as 12 character string. The server will use
the pairing key associated with this instance identifier.
4.4. Publishing Private Discovery Service Instances
Nodes that provide the Private Discovery Service SHOULD advertise
their availability by publishing instances of the service through
DNS-SD.
The DNS-SD service type for the Private Discovery Service is
"_pds._tcp".
Each published instance describes one server and one pairing. In the
case where a node manages more than one pairing, it should publish as
many instances as necessary to advertise the PDS to all paired peers.
Each instance name is composed as follows:
pick a 24 bit nonce, set to the 24 most
significant bits of the 32 bit Unix GMT time.
compute a 48 bit proof:
proof = first 48 bits of HASH(<nonce>|<pairing key>)
set the 72 bit binary identifier as the concatenation
of nonce and proof
set instance_name = BASE64(binary identifier)
In this formula, HASH SHOULD be the function SHA256 defined in
[RFC4055], and BASE64 is defined in section 6.8 of [RFC2045]. The
concatenation of a 24 bit nonce and 48 bit proof result in a 72 bit
string. The BASE64 conversion is 12 characters long per [RFC6763].
Huitema & Kaiser Expires January 4, 2018 [Page 16]
Internet-Draft DNS-SD Privacy Extensions July 2017
4.5. Discovering Private Discovery Service Instances
Nodes that wish to discover Private Discovery Service Instances
SHOULD issue a DNS-SD discovery request for the service type
"_pds._tcp". They MAY, as an alternative, use the Direct Discovery
procedure defined in Section 4.6. If nodes send a DNS-SD discovery
request, they will receive in response a series of PTR records,
providing the names of the instances present in the scope.
For each time interval, the querier SHOULD pre-calculate a hash table
mapping instance names to pairings according to the following
conceptual algorithm:
nonce = 24 bit rounded time stamp of the\
respective next time interval
for each available pairing
retrieve the key Xj of pairing number j
compute F = first 48 bits of hash(nonce, Xj)
construct the binary instance_name as described\
in the previous section
instance_names[nonce][instance_name] = Xj;
The querier SHOULD store the hash tables for the previous, the
current, and the next time interval.
The querier SHOULD examine each instance to see whether it
corresponds to one of its available pairings, according to the
following conceptual algorithm:
for each received instance_name:
convert the instance name to binary using BASE64
if the conversion fails,
discard the instance.
if the binary instance length is not multiple 72 bits,
discard the instance.
nonce = first 24 bits of binary.
Check that the nonce matches the first 24 bits of
the current time, or the previous interval (24 bit number
minus 1) if the current interval is less than half over,
or the next interval (24 bit number plus 1) if the
current interval is more than half over. If the
nonce does not match an acceptable value, discard
the instance.
if ((Xj = instance_names[nonce][instance_name]) != null)
mark the pairing number j as available
Huitema & Kaiser Expires January 4, 2018 [Page 17]
Internet-Draft DNS-SD Privacy Extensions July 2017
The check of the current time is meant to mitigate replay attacks,
while not mandating a time synchronization precision better than two
minutes.
Once a pairing has been marked available, the querier SHOULD try
connecting to the corresponding instance, using the selected key.
The connection is likely to succeed, but it MAY fail for a variety of
reasons. One of these reasons is the probabilistic nature of the
hint, which entails a small chance of "false positive" match. This
will occur if the hash of the nonce with two different keys produces
the same result. In that case, the TLS connection will fail with an
authentication error or a decryption error.
4.6. Direct Discovery of Private Discovery Service Instances
Nodes that wish to discover Private Discovery Service Instances MAY
use the following Direct Discovery procedure instead of the regular
DNS-SD Discovery explained in Section 4.5.
To perform Direct Discovery, nodes should compose a list of Private
Discovery Service Instances Names. There will be one name for each
pairing available to the node. The Instance name for each name will
be composed of a nonce and a proof, using the algorithm specified in
Section 4.4.
The querier will issue SRV record queries for each of these names.
The queries will only succeed if the corresponding instance is
present, in which case a pairing is discovered. After that, the
querier SHOULD try connecting to the corresponding instance, as
explained in Section 4.4.
4.7. Using the Private Discovery Service
Once instances of the Private Discovery Service have been discovered,
peers can establish TLS connections and send DNS requests over these
connections, as specified in DNS-SD.
5. Security Considerations
This document specifies a method for protecting the privacy of nodes
that offer and query for services. This is especially useful when
operating in a public space. Hiding the identity of the publishing
nodes prevents some forms of "targeting" of high value nodes.
However, adversaries can attempt various attacks to break the