-
Notifications
You must be signed in to change notification settings - Fork 2
/
draft-ietf-trans-gossip-01.txt
1456 lines (996 loc) · 59.2 KB
/
draft-ietf-trans-gossip-01.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
TRANS L. Nordberg
Internet-Draft NORDUnet
Intended status: Experimental D. Gillmor
Expires: April 22, 2016 ACLU
T. Ritter
October 20, 2015
Gossiping in CT
draft-ietf-trans-gossip-01
Abstract
The logs in Certificate Transparency are untrusted in the sense that
the users of the system don't have to trust that they behave
correctly since the behaviour of a log can be verified to be correct.
This document tries to solve the problem with logs presenting a
"split view" of their operations. It describes three gossiping
mechanisms for Certificate Transparency: SCT Feedback, STH
Pollination and Trusted Auditor Relationship.
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 April 22, 2016.
Copyright Notice
Copyright (c) 2015 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
Nordberg, et al. Expires April 22, 2016 [Page 1]
Internet-Draft Gossiping in CT October 2015
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
2. Defining the problem . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Terminology and data flow . . . . . . . . . . . . . . . . . . 5
5. Who gossips with whom . . . . . . . . . . . . . . . . . . . . 6
6. What to gossip about and how . . . . . . . . . . . . . . . . 6
7. Gossip Mechanisms . . . . . . . . . . . . . . . . . . . . . . 6
7.1. SCT Feedback . . . . . . . . . . . . . . . . . . . . . . 6
7.1.1. HTTPS client to server . . . . . . . . . . . . . . . 7
7.1.2. HTTPS server to auditors . . . . . . . . . . . . . . 9
7.1.3. SCT Feedback data format . . . . . . . . . . . . . . 10
7.2. STH pollination . . . . . . . . . . . . . . . . . . . . . 10
7.2.1. HTTPS Clients and Proof Fetching . . . . . . . . . . 12
7.2.2. STH Pollination without Proof Fetching . . . . . . . 13
7.2.3. Auditor and Monitor Action . . . . . . . . . . . . . 13
7.2.4. STH Pollination data format . . . . . . . . . . . . . 13
7.3. Trusted Auditor Stream . . . . . . . . . . . . . . . . . 14
7.3.1. Trusted Auditor data format . . . . . . . . . . . . . 14
8. 3-Method Ecosystem . . . . . . . . . . . . . . . . . . . . . 14
8.1. SCT Feedback . . . . . . . . . . . . . . . . . . . . . . 15
8.2. STH Pollination . . . . . . . . . . . . . . . . . . . . . 15
8.3. Trusted Auditor Relationship . . . . . . . . . . . . . . 16
8.4. Interaction . . . . . . . . . . . . . . . . . . . . . . . 17
9. Security considerations . . . . . . . . . . . . . . . . . . . 17
9.1. Censorship/Blocking considerations . . . . . . . . . . . 17
9.2. Privacy considerations . . . . . . . . . . . . . . . . . 19
9.2.1. Privacy and SCTs . . . . . . . . . . . . . . . . . . 19
9.2.2. Privacy in SCT Feedback . . . . . . . . . . . . . . . 19
9.2.3. Privacy for HTTPS clients performing STH Proof
Fetching . . . . . . . . . . . . . . . . . . . . . . 20
9.2.4. Privacy in STH Pollination . . . . . . . . . . . . . 20
9.2.5. Privacy in STH Interaction . . . . . . . . . . . . . 21
9.2.6. Trusted Auditors for HTTPS Clients . . . . . . . . . 21
9.2.7. HTTPS Clients as Auditors . . . . . . . . . . . . . . 22
10. Policy Recommendations . . . . . . . . . . . . . . . . . . . 22
10.1. Mixing Recommendations . . . . . . . . . . . . . . . . . 22
10.2. Blocking Recommendations . . . . . . . . . . . . . . . . 24
10.2.1. Frustrating blocking . . . . . . . . . . . . . . . . 24
10.2.2. Responding to possible blocking . . . . . . . . . . 24
Nordberg, et al. Expires April 22, 2016 [Page 2]
Internet-Draft Gossiping in CT October 2015
11. IANA considerations . . . . . . . . . . . . . . . . . . . . . 25
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
13. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 25
13.1. Changes between ietf-00 and ietf-01 . . . . . . . . . . 25
13.2. Changes between -01 and -02 . . . . . . . . . . . . . . 25
13.3. Changes between -00 and -01 . . . . . . . . . . . . . . 25
14. Normative References . . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction
The purpose of the protocols in this document, collectively referred
to as CT Gossip, is to detect certain misbehavior by CT logs. In
particular, CT Gossip aims to detect logs that are providing
incosistent views to different log clients and logs failing to
include submitted certificates within the time period stipulated by
MMD.
[TODO: enumerate the interfaces used for detecting misbehaviour?]
One of the major challenges of any gossip protocol is limiting damage
to user privacy. The goal of CT gossip is to publish and distribute
information about the logs and their operations, but not to leak any
additional information about the operation of any of the other
participants. Privacy of consumers of log information (in
particular, of web browsers and other TLS clients) should not be
undermined by gossip.
This document presents three different, complementary mechanisms for
non-log elements of the CT ecosystem to exchange information about
logs in a manner that preserves the privacy of HTTPS clients. They
should provide protective benefits for the system as a whole even if
their adoption is not universal.
2. Defining the problem
When a log provides different views of the log to different clients
this is described as a partitioning attack. Each client would be
able to verify the append-only nature of the log but, in the extreme
case, each client might see a unique view of the log.
The CT logs are public, append-only and untrusted and thus have to be
monitored for consistency, i.e., they should never rewrite history.
Additionally, monitors and other log clients need to exchange
information about monitored logs in order to be able to detect a
partitioning attack (as described above).
Nordberg, et al. Expires April 22, 2016 [Page 3]
Internet-Draft Gossiping in CT October 2015
Gossiping about log responses to queries helps address the problem of
detecting malicious or compromised logs with respect to a
partitioning attack. We want some side of the partitioned tree, and
ideally both sides, to see the other side.
Disseminating information about a log poses a potential threat to the
privacy of end users. Some data of interest (e.g. SCTs) are
linkable to specific log entries and thereby to specific sites, which
makes sharing them with others privacy-sensitive. Gossiping about
this data has to take privacy considerations into account in order
not to leak associations between users of the log (e.g., web
browsers) and certificate holders (e.g., web sites). Even sharing
STHs (which do not link to specific log entries) can be problematic -
user tracking by fingerprinting through rare STHs is one potential
attack (see Section 7.2).
3. Overview
SCT Feedback enables HTTPS clients to share Signed Certificate
Timestamps (SCTs) (Section 3.3 of [RFC-6962-BIS]) with CT auditors in
a privacy-preserving manner by sending SCTs to originating HTTPS
servers which in turn share them with CT auditors.
In STH Pollination, HTTPS clients use HTTPS servers as pools sharing
Signed Tree Heads (STHs) (Section 3.6 of [RFC-6962-BIS]) with other
connecting clients in the hope that STHs will find their way to
auditors and monitors.
HTTPS clients in a Trusted Auditor Relationship share SCTs and STHs
with trusted auditors or monitors directly, with expectations of
privacy sensitive data being handled according to whatever privacy
policy is agreed on between client and trusted party.
Despite the privacy risks with sharing SCTs there is no loss in
privacy if a client sends SCTs for a given site to the site
corresponding to the SCT. This is because the site's logs would
already indicate that the client is accessing that site. In this way
a site can accumulate records of SCTs that have been issued by
various logs for that site, providing a consolidated repository of
SCTs that could be shared with auditors. Auditors can use this
information to detect logs that misbehaves by not including
certificates within the time period stipulated by the MMD metadata.
Sharing an STH is considered reasonably safe from a privacy
perspective as long as the same STH is shared by a large number of
other log clients. This "safety in numbers" can be achieved by
requiring gossiping of STHs only of a certain "freshness" while also
Nordberg, et al. Expires April 22, 2016 [Page 4]
Internet-Draft Gossiping in CT October 2015
refusing to gossip about STHs from logs with too high an STH issuance
frequency (see Section 7.2).
4. Terminology and data flow
This document relies on terminology and data structures defined in
[RFC-6962-BIS], including STH, SCT, Version, LogID, SCT timestamp,
CtExtensions, SCT signature, Merkle Tree Hash.
The following picture shows how certificates, SCTs and STHs flow
through a CT system with SCT Feedback and STH Pollination. It does
not show what goes in the Trusted Auditor Relationship stream.
+- Cert ---- +----------+
| | CA | ----------+
| + SCT -> +----------+ |
v | Cert [& SCT]
+----------+ |
| Log | ---------- SCT -----------+
+----------+ v
| ^ +----------+
| | SCT & Certs --- | Website |
| |[1] | +----------+
| |[2] STH ^ |
| |[3] v | |
| | +----------+ | |
| +--------> | Auditor | | HTTPS traffic
| +----------+ | |
| / | SCT
| / SCT & Certs |
Log entries / | |
| / STH STH
v /[4] | |
+----------+ | v
| Monitor | +----------+
+----------+ | Browser |
+----------+
# Auditor Log
[1] |--- get-sth ------------------->|
|<-- STH ------------------------|
[2] |--- leaf hash + tree size ----->|
|<-- index + inclusion proof --->|
[3] |--- tree size 1 + tree size 2 ->|
|<-- consistency proof ----------|
[4] SCT, cert and STH among multiple Auditors and Monitors
Nordberg, et al. Expires April 22, 2016 [Page 5]
Internet-Draft Gossiping in CT October 2015
5. Who gossips with whom
o HTTPS clients and servers (SCT Feedback and STH Pollination)
o HTTPS servers and CT auditors (SCT Feedback)
o CT auditors and monitors (Trusted Auditor Relationship)
Additionally, some HTTPS clients may engage with an auditor who they
trust with their privacy:
o HTTPS clients and CT auditors (Trusted Auditor Relationship)
6. What to gossip about and how
There are three separate gossip streams:
o SCT Feedback - transporting SCTs and certificate chains from HTTPS
clients to CT auditors/monitors via HTTPS servers.
o STH Pollination - HTTPS clients and CT auditors/monitors using
HTTPS servers as STH pools for exchanging STHs.
o Trusted Auditor Stream, HTTPS clients communicating directly with
trusted CT auditors/monitors sharing SCTs, certificate chains and
STHs.
7. Gossip Mechanisms
7.1. SCT Feedback
The goal of SCT Feedback is for clients to share SCTs and certificate
chains with CT auditors and monitors while still preserving the
privacy of the end user. The sharing of SCTs contribute to the
overall goal of detecting misbehaving logs by providing auditors and
monitors with SCTs from many vantage points, making it possible to
catch a higher number of violations of MMD and also catch logs
presenting inconsistent views.
SCT Feedback is the most privacy-preserving gossip mechanism, as it
does not directly expose any links between an end user and the sites
they've visisted to any third party.
[Here's an alternative to that paragraph: SCT Feedback is the most
privacy-preserving gossip mechanism, as it does not create any
potential cross-origin tracking mechanisms. ]
Nordberg, et al. Expires April 22, 2016 [Page 6]
Internet-Draft Gossiping in CT October 2015
HTTPS clients store SCTs and certificate chains they see, and later
send them to the originating HTTPS server by posting them to a well-
known URL (associated with that server), as described in
Section 7.1.1. Note that clients will send the same SCTs and chains
to servers multiple times with the assumption that a potential man-
in-the-middle attack eventually will cease, and an honest server will
receive collected malicious SCTs and certificate chains.
HTTPS servers store SCTs and certificate chains received from clients
and later share them with CT auditors by either posting them to
auditors or making them available via a well-known URL. This is
described in Section 7.1.2.
7.1.1. HTTPS client to server
When an HTTPS client connects to an HTTPS server, the client receives
a set of SCTs as part of the TLS handshake. The client MUST discard
SCTs that are not signed by a log known to the client and SHOULD
store the remaining SCTs together with the corresponding certificate
chain for later use in SCT Feedback.
When the client later reconnects to any HTTPS server for the same
domain, it again receives a set of SCTs. The client MUST add new
SCTs from known logs to its store of SCTs for the server. The client
MUST send to the server any SCTs in the store that are associated
with that server but which were not received from that server.
[TODO: fix the above paragraph - it is vague and confusing. maybe an
example including a client caching at most one SCT per host+log would
clarify]
[TODO: define "same domain"]
Note that the SCT store also contains SCTs received in certificates.
The client MUST NOT send the same set of SCTs to the same server more
often than TBD.
[benl says: "sent to the server" only really counts if the server
presented a valid SCT in the handshake and the certificate is known
to be unrevoked (which will be hard for a MitM to sustain)]
[TODO: expand on rate/resource limiting motivation]
Refer to Section 10.1 for recommendations about strategies.
An SCT MUST NOT be sent to any other HTTPS server than one serving
the domain to which the certificate signed by the SCT refers. Not
Nordberg, et al. Expires April 22, 2016 [Page 7]
Internet-Draft Gossiping in CT October 2015
following this constraint would lead to two types of privacy leaks.
First, the server receiving the SCT would learn about other sites
visited by the HTTPS client. Secondly, auditors or monitors
receiving SCTs from the HTTPS server would learn information about
the other HTTPS servers visited by its clients.
If the HTTPS client has configuration options for not sending cookies
to third parties, SCTs of third parties MUST be treated as cookies
with respect to this setting. This prevents third party tracking
through the use of SCTs/certificates, which would bypass the cookie
policy.
SCTs and corresponding certificates are POSTed to the originating
HTTPS server at the well-known URL:
https://<domain>/.well-known/ct/v1/sct-feedback
The data sent in the POST is defined in Section 7.1.3.
HTTPS servers perform a number of sanity checks on SCTs from clients
before storing them:
1. if a bit-wise compare of an SCT plus chain matches a pair already
in the store, this SCT and chain pair MAY be discarded
2. if the SCT can't be verified to be a valid SCT for the
accompanying leaf cert, issued by a known log, the SCT SHOULD be
discarded
3. if the leaf cert is not for a domain for which the server is
authoritative, the SCT MUST be discarded
Check number 1 is for detecting duplicates and minimizing processing
and storage by the server. It's important to note that the check
should be on pairs of SCT and chain in order to catch different
chains accompanied by the same SCT. This mis-matched chain
information may be useful as a diagnostic tool for HTTPS server
operators.
Check number 2 is to prevent DoS attacks where an adversary can fill
up the store prior to attacking a client, or a denial of service
attack on the server's storage space.
Check number 3 is to help malfunctioning clients from leaking which
sites they visit and additionally to prevent DoS attacks.
Note that an HTTPS server MAY choose to store a submitted SCT and the
accompanying certificate chain even when the SCT can't be verified
Nordberg, et al. Expires April 22, 2016 [Page 8]
Internet-Draft Gossiping in CT October 2015
according to check number 2. One such case would be when a
certificate chain validation is performed and the chain ends in a
trust anchor configured on the server. In this instance, the server
could also be configured to not bother with known-to-be-good (i.e.
administratively-vetted) leaf certificates, and only store unknown
leaf certificates that chain to a known trust anchor. The risk of
spamming and denial of service can be mitigated by configuring the
server with all known acceptable certificates (or certificate hashes)
applicable to this server. This information may enable a HTTPS
server operator to detect attacks or unusual behavior of Certificate
Authorities even outside the Certificate Transparency ecosystem.
7.1.2. HTTPS server to auditors
HTTPS servers receiving SCTs from clients SHOULD share SCTs and
certificate chains with CT auditors by either serving them on the
well-known URL:
https://<domain>/.well-known/ct/v1/collected-sct-feedback
or by HTTPS POSTing them to a set of preconfigured auditors. This
allows an HTTPS server to choose between an active push model or a
passive pull model.
The data received in a GET of the well-known URL or sent in the POST
is defined in Section 7.1.3.
HTTPS servers SHOULD share all SCTs and accompanying certificate
chains they see that pass the checks in Section 7.1.1. If this is an
infeasible amount of data, the server may choose to expire
submissions according to an undefined policy. Suggestions for such a
policy can be found in Section 10.1.
HTTPS servers MUST NOT share any other data that they may learn from
the submission of SCT Feedback by HTTPS clients, like the HTTPS
client IP address or the time of submission.
Auditors SHOULD provide the following URL accepting HTTPS POSTing of
SCT feedback data:
https://<auditor>/ct/v1/sct-feedback
Auditors SHOULD regularly poll HTTPS servers at the well-known
collected-sct-feedback URL. The frequency of the polling and how to
determine which domains to poll is outside the scope of this
document. However, the selection MUST NOT be influenced by potential
HTTPS clients connecting directly to the auditor. For example, if a
poll to example.com occurs directly after a client submits an SCT for
Nordberg, et al. Expires April 22, 2016 [Page 9]
Internet-Draft Gossiping in CT October 2015
example.com, an adversary observing the auditor can trivially
conclude the activity of the client.
7.1.3. SCT Feedback data format
The data shared between HTTPS clients and servers, as well as between
HTTPS servers and CT auditors/monitors, is a JSON object [RFC7159]
with the following content:
o sct_feedback: An array of objects consisting of
* x509_chain: An array of base64-encoded X.509 certificates. The
first element is the end-entity certificate, the second chains
to the first and so on.
* sct_data: An array of objects consisting of the base64
representation of the binary SCT data as defined in
[RFC-6962-BIS] Section 3.3.
The 'x509_chain' element MUST contain at least the leaf certificate
and SHOULD contain the full chain to a root accepted by all of the
logs in the set of logs issuing all the SCTs in the 'sct_data'
element.
Some clients have trust anchors that are locally added (e.g. by an
administrator or by the user themselves). A local trust anchors is
potentially privacy-sensitive since it may carry information about
the specific computer or user. If a certificate is covered by SCTs
issued by publicly trusted logs, but it chains to a privacy-sensitive
local trust anchor, the client SHOULD submit it as an "x509\_chain"
consisting only of the leaf certificate.
[TBD: Be strict about what sct_data may contain or is this
sufficiently implied by previous sections?]
[TBD: There was discussion about including a few field for
client->server reporting, which is the exact set and order of
certificates sent by the HTTPS server to the client. This is
additional diagnostic information that a HTTPS server could use to
check it's deployment... but is pretty much useless to CT or gossip.
Right now we're not including this, but we're polling server
operators to see if they would welcome this data.]
7.2. STH pollination
The goal of sharing Signed Tree Heads (STHs) through pollination is
to share STHs between HTTPS clients, CT auditors, and monitors in
while still preserving the privacy of the end user. The sharing of
Nordberg, et al. Expires April 22, 2016 [Page 10]
Internet-Draft Gossiping in CT October 2015
STHs contribute to the overall goal of detecting misbehaving logs by
providing CT auditors and monitors with SCTs from many vantage
points, making it possible to detect logs that are presenting
inconsistent views.
HTTPS servers supporting the protocol act as STH pools. HTTPS
clients and CT auditors and monitors in the possession of STHs should
pollinate STH pools by sending STHs to them, and retrieving new STHs
to send to other STH pools. CT auditors and monitors should perform
their auditing and monitoring duties by retrieving STHs from pools.
STH Pollination is carried out by sending STHs to HTTPS servers
supporting the protocol, and retrieving new STHs. In the case of
HTTPS clients, STHs SHOULD be sent in an already established TLS
session. This makes it hard for an attacker to disrupt STH gossiping
without also disturbing ordinary secure browsing (https://). This is
discussed more in Section 10.2.1.
HTPS clients send STHs to HTTPS servers by POSTing them to the well-
known URL:
https://<domain>/.well-known/ct/v1/sth-pollination
The data sent in the POST is defined in Section 7.2.4.
The response contains zero or more STHs in the same format, described
in Section 7.2.4.
An HTTPS client may acquire STHs by several methods:
o in replies to pollination POSTs;
o asking logs that it recognises for the current STH, either
directly (v2/get-sth) or indirectly (for example over DNS)
o resolving an SCT and certificate to an STH via an inclusion proof
o resolving one STH to another via a consistency proof
HTTPS clients (who have STHs), CT auditors, and monitors SHOULD
pollinate STH pools with STHs. Which STHs to send and how often
pollination should happen is regarded as undefined policy with the
exception of privacy concerns explained in the next section.
Suggestions for the policy may be found in Section 10.1.
An HTTPS client could be tracked by giving it a unique or rare STH.
To address this concern, we place restrictions on different
components of the system to ensure an STH will not be rare.
Nordberg, et al. Expires April 22, 2016 [Page 11]
Internet-Draft Gossiping in CT October 2015
o HTTPS clients sliently ignore STHs from logs with an STH issuance
frequency of more than one STH per hour. Logs use the STH
Frequency Count metadata to express this ([RFC-6962-BIS] sections
3.6 and 5.1).
o HTTPS clients silently ignore STHs which are not fresh.
An STH is considered fresh iff its timestamp is less than 14 days in
the past. Given a maximum STH issuance rate of one per hour, an
attacker has 336 unique STHs per log for tracking. Clients MUST
ignore STHs older than 14 days. We consider STHs within this
validity window to be personally identifiable data, and STHs outside
this window not personally identifiable.
A log may cease operation, in which case there will soon be no STH
within the validity window. Clients SHOULD perform all three methods
of gossip about a log that has ceased operation - it is possible the
log was still compromised and gossip can detect that. STH
Pollination is the one mechanism where a client must know about a log
shutdown. A client who does not know about a log shutdown MUST NOT
attempt any heuristic to detect a shutdown. Instead the client MUST
be informed about the shutdown from a verifiable source (e.g. a
software update). The client SHOULD be provided the final STH issued
by the log and SHOULD resolve SCTs and STHs to this final STH. If an
SCT or STH cannot be resolved to the final STH... XXX?
When multiplied by the number of logs from which a client accepts
STHs, this number of unique STHs grow and the negative privacy
implications grow with it. It's important that this is taken into
account when logs are chosen for default settings in HTTPS clients.
This concern is discussed upon in Section 9.2.5.
7.2.1. HTTPS Clients and Proof Fetching
There are two types of proofs a client may retrieve.
An HTTPS client will retrieve SCTs from an HTTPS server, and must
obtain an inclusion proof to an STH in order to verify the promise
made by the SCT.
An HTTPS client may receive SCT bundled with an inclusion proof to a
historical STH via an unspecified future mechanism. Because this
historical STH is considered personally identifiable information per
above, the client must obtain a consistency proof to a more recent
STH.
If a client requested either proof directly from a log or auditor, it
would reveal the client's browsing habits to a third party. To
Nordberg, et al. Expires April 22, 2016 [Page 12]
Internet-Draft Gossiping in CT October 2015
mitigate this risk, an HTTPS client MUST retrieve the proof in a
manner that disguises the client.
Depending on the client's DNS provider, DNS may provide an
appropriate intermediate layer that obfuscates the linkability
between the user of the client and the request for inclusion (while
at the same time providing a caching layer for oft-requested
inclusion proofs.)
[TODO: Add a reference to Google's DNS mechanism more proper than
http://www.certificate-transparency.org/august-2015-newsletter]
Anonymity networks such as Tor also present a mechanism for a client
to anonymously retrieve a proof from an auditor or log.
7.2.2. STH Pollination without Proof Fetching
An HTTPS client MAY participate in STH Pollination without fetching
proofs. In this situation, the client receives STHs from a server,
applies the same validation logic to them (signed by a known log,
within a validity window) and will later pass them to a HTTPS server.
When operating in this fashion, the HTTPS client is promoting gossip
for Certificate Transparency, but derives no direct benefit itself.
In comparison, a client who resolves SCTs or historical STHs to
recent STHs and pollinates them is assured that if it was attacked,
there is a probability that the ecosystem will detect and respond to
the attack (by distrusting the log).
7.2.3. Auditor and Monitor Action
Auditors and Monitors participate in STH pollination by retrieving
STHs from HTTPS servers. They verify that the STH is valid by
checking the signature, and requesting a consistency proof from the
STH to the most recent STH.
After retrieving the consistency proof to the most recent STH, they
SHOULD pollinate this new STH among participating HTTPS Servers. In
this way, as STHs "age out" and are no longer fresh, their "lineage"
continues to be tracked in the system.
7.2.4. STH Pollination data format
The data sent from HTTPS clients and CT monitors and auditors to
HTTPS servers is a JSON object [RFC7159] with the following content:
o sths - an array of 0 or more fresh SignedTreeHead's as defined in
[RFC-6962-BIS] Section 3.6.1.
Nordberg, et al. Expires April 22, 2016 [Page 13]
Internet-Draft Gossiping in CT October 2015
[XXX An STH is considered fresh iff TBD.]
7.3. Trusted Auditor Stream
HTTPS clients MAY send SCTs and cert chains, as well as STHs,
directly to auditors. Note that there are privacy implications in
doing so, these are outlined in Section 9.2.1 and Section 9.2.6.
The most natural trusted auditor arrangement arguably is a web
browser that is "logged in to" a provider of various internet
services. Another equivalent arrangement is a trusted party like a
corporation to which an employee is connected through a VPN or by
other similar means. A third might be individuals or smaller groups
of people running their own services. In such a setting, retrieving
proofs from that third party could be considered reasonable from a
privacy perspective. The HTTPS client does its own auditing and
might additionally share SCTs and STHs with the trusted party to
contribute to herd immunity. Here, the ordinary [RFC-6962-BIS]
protocol is sufficient for the client to do the auditing while SCT
Feedback and STH Pollination can be used in whole or in parts for the
gossip part.
Another well established trusted party arrangement on the internet
today is the relation between internet users and their providers of
DNS resolver services. DNS resolvers are typically provided by the
internet service provider (ISP) used, which by the nature of name
resolving already know a great deal about which sites their users
visit. As mentioned in Section XXX, in order for HTTPS clients to be
able to retrieve proofs in a privacy preserving manner, logs could
expose a DNS interface in addition to the ordinary HTTPS interface.
An informal writeup of such a protocol can be found at XXX.
7.3.1. Trusted Auditor data format
[TBD specify something here or leave this for others?]
8. 3-Method Ecosystem
The use of three distinct methods for monitoring logs may seem
excessive, but each represents a needed component in the CT
ecosystem. To understand why, the drawbacks of each component must
be outlined. In this discussion we assume that an attacker knows
which mechanisms an HTTPS client and HTTPS server implement.
Nordberg, et al. Expires April 22, 2016 [Page 14]
Internet-Draft Gossiping in CT October 2015
8.1. SCT Feedback
SCT Feedback requires the cooperation of HTTPS clients and more
importantly HTTPS servers. Although SCT Feedback does require a
significant amount of server-side logic to respond to the
corresponding APIs, this functionality does not require
customization, so it may be pre-provides and work out of the box.
However, to take full advantage of the system, an HTTPS server would
wish to perform some configuration to optimize its operation:
o Minimize its disk commitment by whitelisting known SCTs and
certificate chains
o Maximize its chance of detecting a misissued certificate by
configuring a trust store of CAs
o Establish a "push" mechanism for POSTing SCTs to Auditors and
Monitors
These configuration needs, and the simple fact that it would require
some deployment of software, means that some percentage of HTTPS
servers will not deploy SCT Feedback.
If SCT Feedback was the only mechanism in the ecosystem, any server
that did not implement the feature, would open itself and its users
to attack without any possibility of detection.
If SCT Feedback was not deployed, users who wished to have the
strongest measure of privacy protection (by disabling STH Pollination
Proof Fetching and forgoing a Trusted Auditor) could be attacked
without risk of detection.
8.2. STH Pollination
STH Pollination requires the cooperation of HTTPS clients, HTTPS
servers, and logs.
For a client to fully participate in STH Pollination, and have this
mechanism detect attacks against it, the client must have a way to
safely perform Proof Fetching in a privacy preserving manner. The
client may pollinate STHs it receives without performing Proof
Fetching, but we do not consider this option in this section.
HTTPS Servers must deploy software (although, as in the case with SCT
Feedback this logic can be pre-provided) and commit some configurable
amount of disk space to the endeavor.
Nordberg, et al. Expires April 22, 2016 [Page 15]
Internet-Draft Gossiping in CT October 2015
Logs must provide access to clients to query proofs in a privacy
preserving manner, most likely through DNS.
Unlike SCT Feedback, the STH Pollination mechanism is not hampered if
only a minority of HTTPS servers deploy it. However, it makes an
assumption that an HTTPS client performs anonymized Proof Fetching
(such as the DNS mechanism discussed). However, any manner that is
anonymous for some (such as clients who use shared DNS services such
as a large ISP), may not be anonymous for others.
For instance, DNS leaks a considerable amount of information
(including what data is already present in the cache) in plaintext
over the network. For this reason, some percentage of HTTPS clients
may choose to not enable the Proof Fetching component of STH
pollination. (Although they can still request and send STHs among
participating HTTPS servers, as mentioned earlier this affords them
no direct benefit.)
If STH Pollination was the only mechanism deployed, users that
disable it would be able to be attacked without risk of detection.
If STH Pollination was not deployed, HTTPS Clients visiting HTTPS
Servers who did not deploy SCT Feedback could be attacked without
risk of detection.
8.3. Trusted Auditor Relationship
The Trusted Auditor Relationship is expected to be the rarest gossip
mechanism, as an HTTPS Client is providing an unadulterated report of
its browsing history to a third party. While there are valid and
common reasons for doing so, there is no appropriate way to enter
into this relationship without retrieving informed consent from the
user.
However, the Trusted Auditor Relationship mechanism still provides
value to a class of HTTPS Clients. For example, web crawlers have no
concept of a "user" and no expectation of privacy. Organizations
already performing network monitoring for anomalies or attacks can
run their own Trusted Auditor for the same purpose with marginal
increase in privacy concerns.
The ability to change one's Trusted Auditor is a form of Trust
Agility that allows a user to choose who to trust, and be able to
revise that decision later without consequence. A Trusted Auditor
connection can be made more confidential than DNS (through the use of
TLS), and can even be made (somewhat) anonymous through the use of
anonymity services such as Tor. (Note that this does ignore the de-
Nordberg, et al. Expires April 22, 2016 [Page 16]
Internet-Draft Gossiping in CT October 2015
anonymization possibilities available from viewing a user's browsing
history.)
If the Trusted Auditor relationship was the only mechanism deployed,
users who do not enable it (the majority) would be able to be
attacked without risk of detection.
If the Trusted Auditor relationship was not deployed, crawlers and
organizations would build it themselves for their own needs. By
standardizing it, users who wish to opt-in (for instance those
unwilling to participate fully in STH Pollination) can have an
interoperable standard they can use to choose and change their
trusted auditor.
8.4. Interaction
The interactions of the mechanisms is thus outlined:
HTTPS Clients can be attacked without risk of detection if they do
not participate in any of the three mechanisms.
HTTPS Clients are afforded the greatest chance of detecting an attack
when they either participate in STH Pollination with Proof Fetching
or have a Trusted Auditor relationship. Participating in SCT
Feedback enables a HTTPS Client to assist in detecting the exact
target of an attack, although they do not gain any direct benefit
from it.
HTTPS Servers that omit SCT Feedback may never learn about targeted
attacks against them, even if the attack occurred and the log
distrusted. They do gain some herd immunity, enabling them to detect
attacks, through their clients participating in STH Pollination or a
Trusted Auditor Relationship.
When HTTPS Servers omit SCT feedback, it allow a portion of their
users to be attacked without detection; the vulnerable users are
those who do not participate in STH Pollination with Proof Fetching
and that not have a Trusted Auditor relationship.
9. Security considerations
9.1. Censorship/Blocking considerations
We assume a network attacker who is able to fully control the
client's internet connection for some period of time - including
selectively blocking requests to certain hosts and truncating TLS
connections based on information observed or guessed about client
Nordberg, et al. Expires April 22, 2016 [Page 17]
Internet-Draft Gossiping in CT October 2015
behavior. In order to successfully detect log misbehavior, the
gossip mechanisms must still work even in these conditions.
There are several gossip connections that can be blocked:
1. Clients sending SCTs to servers in SCT Feedback
2. Servers sending SCTs to auditors in SCT Feedback (server push
mechanism)
3. Servers making SCTs available to auditors (auditor pull
mechanism)
4. Clients fetching proofs in STH Pollination
5. Clients sending STHs to servers in STH Pollination
6. Servers sending STHs to clients in STH Pollination
7. Clients sending SCTs to Trusted Auditors
If a party cannot connect to another party, it can be assured that
the connection did not succeed. While it may not have been
maliciously blocked, it knows the transaction did not succeed.
Mechanisms which result in a positive affirmation from the recipient
that the transaction succeeded allow confirmation that a connection
was not blocked. In this situation, the party can factor this into
strategies suggested in Section 10.1 and in Section 10.2.2.
The connections that allow positive affirmation are 1, 2, 4, 5, and
7.
More insidious is blocking the connections that do not allow positive
confirmation: 3 and 6. An attacker may truncate a or drop a response
from a server to a client, such that the server believes it has
shared data with the recipient, when it has not. However, in both
scenatios (3 and 6), the server cannot distinguish the client as a
cooperating member of the CT ecosystem or as an attacker performing a
sybil attack, aiming to flush the server's data store. Therefore the
fact that these connections can be undetectably blocked does not
actually alter the threat model of servers responding to these
requests. The choice of algorithm to release data is crucial to
protect against these attacks, strategies are suggested in
Section 10.1.