Tom Ritter | 26 Aug 14:15 2015

[Trans] Tracking via multiple STHs (was Call for adoption, draft-linus-trans-gossip-ct)

On 25 August 2015 at 03:56, Ben Laurie <benl <at> google.com> wrote:
>
>
> On Thu, 13 Aug 2015 at 01:34 Tom Ritter <tom <at> ritter.vg> wrote:
>>
>> On 8 August 2015 at 12:25, Bryan Ford <brynosaurus <at> gmail.com> wrote:
>> > [Many good things]
>>
>> Okay.  If I simplify unfairly I think I agree with many of the root
>> points of your email.
>>
>> 1) Yes, more logs plus even a weeks worth of STHs probably affords too
>> much ability for tracking. Releasing a STH will have some sort of
>> probability attached to it, but again 'statistics'[0]. I've open a
>> ticket to make sure we don't lose this.
>
>
> I've been thinking about this for a while now, and I'd like to know how this
> attack works.
>
> When a client communicates with a log, assuming it manages to do so
> completely anonymously, it reveals at most two STHs it knows (i.e. if it
> asks for an STH consistency proof).
>
> A week's worth of STHs gives me ~10,000 pairs. Assuming, say, 1B people who
> visit sites using CT in that week, that puts each person into an anonymity
> set of size 100,000, assuming the attacker has full control over STHs the
> user caches. Which he doesn't.
>
> Also, once the attacker has narrowed the user to this set, what has he
> learnt? Nothing, since he already knew the 2 STHs the user had cached (he
> supplied them). Those two STHs are correlated with nothing else. What's
> more, one of them is now going to be removed from the cache (the older one),
> moving the user into a  really large anonymity set. In practice, the user
> will soon replace that STH with a more recent one, and different users will
> replace with different STHs, causing the set to become even larger over
> time. Anyway, now you can determine that one of at least 10M people visited
> some particular website. I find it hard to get excited about that.
>
> In order to further narrow the user down, or to learn anything correlated
> with the smaller (two STH) anonymity set, the attacker needs some other
> persistent marker so he can correlate other requests. But if he has that
> persistent marker, what is the STH marker for?
>
> In short: I am not seeing how this represents a privacy problem. Perhaps I'm
> missing something?


So in your thought process the attacker is a log colluding with a website to track a user? I imagined in a different way.


Two independent sites A and B want to collaborate to track a user cross-origin.  A feeds a client Carol some N specific STHs from the M logs Carol trusts, chosen to be older and less common, but still in the validity window.  Carol visits B and chooses to release some of the STHs she has stored, according to some policy.

If we were able to model a representation for how common older STHs are in the pools of clients, then for a given policy of how to choose which of those STHs to send to B I think we could calculate some statistics about how likely it is that Carol looks like someone else when talking to B and how useful/accurate such a tracking mechanism is.  

That's the concern I had in my head, others may have different variants .

-tom
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
trans issue tracker | 21 Aug 16:23 2015
Picon

[Trans] [trans] #106 (rfc6962-bis): Include LogID in the STH structure (TreeHeadSignature)

#106: Include LogID in the STH structure (TreeHeadSignature)

 Currently, STHs don't self-identify which log they are signed by.

 For RFC6962, this doesn't really matter: STHs are generally fetched
 directly from the log, so you implicitly know which log they are signed
 by.

 However, for ticket #10 (and #104) and for gossip, STHs (and inclusion
 proofs, which incorporate STHs) will be obtained from places other than
 the originating log.  Some mechanism will be needed for specifying which
 log they are signed by.

 Therefore, I propose that we:
 1. Add the LogID field to the TreeHeadSignature struct.
 2. Bump TreeHeadVersion from v1 to v2.

--

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:
  rob.stradling <at> comodo.com           |  rob.stradling <at> comodo.com
     Type:  task                     |     Status:  new
 Priority:  major                    |  Milestone:
Component:  rfc6962-bis              |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/106>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 21 Aug 16:06 2015
Picon

[Trans] [trans] #105 (rfc6962-bis): Shrink LogID

#105: Shrink LogID

 SCTs currently contain...
     struct {
         opaque key_id[HASH_SIZE];
     } LogID;

 That's 32 bytes (assuming SHA-256) just to give clients a hint about which
 log public key should be used to verify the SCT signature.  Wasteful.

 Also, I don't see why it needs to be a "struct".

 There are various schemes we could use, but here's my proposal...

 1. Redefine LogID to...
     opaque LogID<1..2^8-1>;

 2. Change...
    '"key_id" is the HASH of the log's public key, calculated over the DER
     encoding of the key represented as SubjectPublicKeyInfo.'
    ...to...
    '"LogID" is the DER-encoding of an OID, excluding the ASN.1 tag and
     length bytes, that the log operator has allocated for the purpose of
     uniquely identifying this log.'

 3. Add the LogID OID to the log metadata.

 Any better ideas?

--

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:
  rob.stradling <at> comodo.com           |  rob.stradling <at> comodo.com
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  rfc6962-bis              |    Version:
 Severity:  -                        |   Keywords:
-------------------------------------+-------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/105>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 18 Aug 17:09 2015
Picon

[Trans] [trans] #104 (rfc6962-bis): Add SCT Inclusion Proof extension

#104: Add SCT Inclusion Proof extension

 If servers send inclusion proofs it reduces log load and increases client
 privacy.

 Add extensions to all three mechanisms (in-cert, TLS extension, OCSP
 extension) to allow this.

--

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  benl <at> google.com        |  rfc6962-bis <at> tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  blocker      |  Milestone:
Component:  rfc6962-bis  |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/104>
trans <http://tools.ietf.org/trans/>
Adam Eijdenberg | 17 Aug 19:24 2015
Picon

[Trans] Certificate Transparency Newsletter - August 2015


Hi CT watchers,

We wanted to put an update out to summarize what the Certificate
Transparency team at Google is working on as well as other efforts in
the space that we are aware of.  There are lots of other great
contributions taking place from other organizations and individuals so
we apologize for anything that we've missed and we'd also love to hear
more about them.

Standards work
==============
Achievements:
- Work continues on RFC6962-bis. Version 8 of the draft was published in
  July [1].
- IETF 93 was held in Prague in July, and the following CT presentations
  took place:
  - "trans" issues update [2] - Eran Messeri
  - CT Attack Model [3] - Steve Kent
  - draft-linus-trans-gossip-ct [4] - Daniel Kahn Gillmor and Linus
    Nordberg
  - CT for Binary Code [5] - Dacheng Zhang and Daniel Kahn Gillmor
  - Selective Logs [6] - Rich Salz
- New version of Gossip Internet Draft published in July [7].

Lookahead:
- We're very interested in exploring how we make it viable for a
  site-owner to be able to opt-in to requiring CT, ahead of any general
  browser-enforced deadlines.  We would welcome participation in helping
  define what this might look like in a manner that would work well for
  both browsers and site-owners.


Log servers
===========
Achievements:
- Symantec's log successfully completed compliance testing in August and
  the process has begun to move this into Chrome's trusted logs store
  [1].
- Testing is underway for one other log server implementation, Venafi.
- Design doc published for Google's open source log server [2].
- README updated with Quickstart instructions for building Google's open
  source log server [3].

Lookahead:
- Google is planning to update the open-source implementation to track
  the changes made in RFC6962-bis.


Client implementations
======================
Achievements:
- Apple's new App Transport Security for iOS 9 and Mac OS X 10.11
  includes support for Certificate Transparency [1], although we're not
  sure exactly what it does yet.  Does anyone reading this have details to share?
- Chrome 41, released in March of this year, began enforcing the CT
  requirement for all EV certificates issued after 1 Jan 2015.

Lookahead:
- Google is working with the Mozilla Foundation and a contractor to
  build a patch to contribute to Firefox to provide Certificate
  Transparency support in Firefox.
- Google is planning to launch a set of DNS servers to be able to handle
  inclusion proof checking over DNS. The primary motivation for doing so
  is so that a client (such as Chrome, or other browsers that wish to
  use this) can perform inclusion proof checks without directly
  revealing the browsing history of the user to any new parties,
  including Google. The intent is that the client will receive an
  inclusion proof by performing a DNS lookup for a TXT record for a
  specially crafted hostname, via the user's existing DNS resolver
  (typically an ISP) which in turn will resurse to eventually service
  the request from a Google DNS server.  In this manner the client is
  only revealing the leaf hashes they see (and thus the sites they
  visit) to their existing DNS resolver, which already (in practically
  all cases) has just serviced a DNS request for that same site and thus
  already knows their browsing history.
- Google is building out log mirrors for all logs included by Chrome,
  and the intent is that read-only requests from Chrome (for STHes, or
  inclusion-proofs (via the DNS mechanism above)) will be serviced by a
  log mirror, rather than the underlying logs.
- Google is building out Chrome support to include STH fetching, and to
  use the DNS inclusion proof method outlined above.  We intend to
  provide more information (including protocol details) as we make
  progress.
- Google is working with the OpenSSL community on adding experimental
  support into OpenSSL client for retrieving and validating all SCTs
  associated with a TLS connection [2].


Server implementations
======================
Achievements:
- haproxy [1], nginx [2] and Apache [3] support serving SCTs via TLS
  extensions (thanks to Janusz Dziemidowicz, Graham Edgecombe and Jeff
  Trawick respectively).
- New section added to Certificate Transparency site to demonstrate how
  to use these [4].
- (Apologies this is so specific to Google, but this was a big effort
  due to the scale of the organization/infrastructure) Google.com
  properties are now serving SCTs via the TLS Extension.

Lookahead:
- Google is looking at how to add SCT support to QUIC protocol, which is
  used to communicate between Chrome and many Google properties.


Monitors
========
Achievements:
- Both DigiCert [1] and Comodo [2] have implemented log monitors
  allowing interested parties to view certificates that are issued for
  a domain.
- Matt Palmer released an open-source Ruby framework for building your
  own monitor [3].

Lookahead:
- Google is also looking at adding a way to allow interested parties to
  search for and view certificates found in CT logs.
- Comodo is planning to release their monitor as open-source.

_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
trans issue tracker | 13 Aug 02:23 2015
Picon

[Trans] [trans] #103 (gossip): Evaluate if we need tighter requirements around STHs when we take into account multiple logs.

#103: Evaluate if we need tighter requirements around STHs when we take into
account multiple logs.

 We've been kicking this around a bit, but wanted to make sure we captured
 it concretely.

 Bryan mentioned this in his emails also, see
 https://mailarchive.ietf.org/arch/msg/trans/7FR3aRVwi4FZLhmJfy9UnAxQNuU

--

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-threat-
  tom <at> ritter.vg          |  analysis <at> tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  gossip       |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/103>
trans <http://tools.ietf.org/trans/>
Bryan Ford | 9 Aug 15:41 2015
Picon

Re: [Trans] Gossip draft CFA closed

Dear Melinda,

From: Melinda Shore <melinda.shore <at> gmail.com>
Subject: [Trans] Gossip draft CFA closed
Date: August 7, 2015 at 3:02:28 PM EDT


Hi, all:

Thank you for your feedback on the call for working group
adoption of draft-linux-trans-gossip-ct.  It's very clear
that there's widespread support for adoption, and that we've
both got people to work on the draft and to review it.  Bryan
Ford raised some technical issues during the discussion but
those have been resolved (future revisions of the draft should
include some text clarifying the conditions under which the
data will be gossiped and what problems gossip is *not*
intended to solve).

I must object to your conclusion that the “technical issues” I brought up during the discussion “have been resolved” - at any rate, I consider them neither purely “technical issues” nor having “been resolved”, as should be eminently clear from my E-mails on the topic.

As I stated clearly earlier, I feel that the entire gossip approach is fundamentally flawed.  It’s not just some technical issues within the draft that can be easily fixed, but the whole approach.  My concerns are with the strategy, not just minor “technical issues”.

And similarly, I do not see how it can be concluded from the E-mail discussion that my concerns “have been resolved” (or even addressed).  

Any approach will add complexity to the system: a gossip protocol will, and a multisignature approach will.  Have the advantages, disadvantages, and relative complexities of each of these approaches been weighed and considered in any way?  Or was it somehow just “assumed as a given” since before I started participating that gossip was the right approach and no one is interested in questioning that now?

I’ll grant that no one else on the list seems to be echoing my concerns with the gossip approach at the moment - so if you wish to close the call for adoption anyway over my objections, please feel free to do so; I assume that’s what the “rough” in “rough consensus” is for.  But please do not mischaracterize my position as merely having raised “some technical issues” that “have been resolved.”

Bryan

Attachment (smime.p7s): application/pkcs7-signature, 4834 bytes
_______________________________________________
Trans mailing list
Trans <at> ietf.org
https://www.ietf.org/mailman/listinfo/trans
Melinda Shore | 7 Aug 21:02 2015
Picon

[Trans] Gossip draft CFA closed

Hi, all:

Thank you for your feedback on the call for working group
adoption of draft-linux-trans-gossip-ct.  It's very clear
that there's widespread support for adoption, and that we've
both got people to work on the draft and to review it.  Bryan
Ford raised some technical issues during the discussion but
those have been resolved (future revisions of the draft should
include some text clarifying the conditions under which the
data will be gossiped and what problems gossip is *not*
intended to solve).

The authors should resubmit the draft as draft-ietf-trans-gossip,
and Paul and I will work with them to establish delivery
milestones.

Thanks again for your comments and discussion.

Melinda
trans issue tracker | 31 Jul 16:47 2015
Picon

[Trans] [trans] #102 (rfc6962-bis): "root" should be "trust anchor"

#102: "root" should be "trust anchor"

 Through the I-D we refer to root certificates, whereas the intent (and the
 practice) is that the "roots" actually include intermediates, too.

 This seems important, since browsers also include intermediates in their
 trust anchors.

 So, we need to correct the use of the term "root" throughout the document.

--

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-
  benl <at> google.com        |  rfc6962-bis <at> tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  rfc6962-bis  |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/102>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 28 Jul 14:47 2015
Picon

[Trans] [trans] #101 (gossip): Handle Shutdown Log Case

#101: Handle Shutdown Log Case

 Draft needs to handle what should be done when a log closes.  Shouldn't be
 too difficult, we can have clients pollinate the final STH - but will the
 client _know_ when a log has been shut down?

 It seems like there will be two cases:
  - The client knows the log is shut down or will be shut down at a
 specific datetime, and it can use this information to correctly pollinate
 the final STH.
  - The client doesn't know, the log shuts down, and it starts getting old
 STHs that it doesn't pollinate (believing them to be a malicious
 timestamp-fingerprint attack)

--

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-threat-
  tom <at> ritter.vg          |  analysis <at> tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  gossip       |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/101>
trans <http://tools.ietf.org/trans/>
trans issue tracker | 28 Jul 14:45 2015
Picon

[Trans] [trans] #100 (gossip): Review in light of blocking

#100: Review in light of blocking

 We should make sure the draft adequately handles the cases of a network
 attacker temporarily blocking certain upstream requests.

--

-- 
-------------------------+-------------------------------------------------
 Reporter:               |      Owner:  draft-ietf-trans-threat-
  tom <at> ritter.vg          |  analysis <at> tools.ietf.org
     Type:  defect       |     Status:  new
 Priority:  major        |  Milestone:
Component:  gossip       |    Version:
 Severity:  -            |   Keywords:
-------------------------+-------------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/trans/trac/ticket/100>
trans <http://tools.ietf.org/trans/>

Gmane