Re: [Trans] comments on draft-linux-trans-gossip-ct-01

[Tom Ritter <[e-mail]>]

On 22 March 2015 at 21:51, Benjamin Kaduk <[e-mail]> wrote:
> First off, I have a general comment that there seem to be some places in
> the document where it is implicitly assumed that the HTTPS client and
> server trust each other to behave correctly and are "only" truing to
> detect misbehavior by other parties (i.e., CAs or parties subverting the
> CA infrastructure, etc.), to the exclusion of having the client and server
> retain some level of distrust or sanity checking of each other.

If it is not clear, I think it should be made explicit that the
purpose of CT gossip is to detect misbehaving CT logs - and nothing
more.  The purpose of CT is to detect misbehaving CAs.

A misbehaving server is making itself vulnerable, so they have an
incentive to behave. If a server misbehaves in collusion with a log,
it will hopefully be detected by an HTTPS client sharing SCTs directly
with an auditor (which is mentioned in a sentence in 3.1.2, and is a
natural extension if a user _wishes_ to give up some privacy.) But
this scenario also doesn't seem to make a lot of sense - why would a
server collude with a log when it can achieve the same goal with
significantly less work and less risk?

> I'm not
> sure that the client wants to always trust the server, given that the
> scheme is positing a universe where some clients will sometimes
> successfully connect to hostile servers supplied with fraudulent
> certificates (that validate) by the attacker.

The client is trusting that it will eventually connect to a behaving
server and that a server is interested in detecting mis-issuance for
itself. Another way to phrase it is that a client is not cordoned off
for a given server once and forever, with no way to ever connect to
the valid server again

If it's not clear that the client does not empty it's SCT cache into a
server and say "Okay, I'm all set" -then it should be made so. The
client doesn't do that. It retains SCTs and reports them according to
some unspecified UA algorithm. (exponential backoff plus
randomization?)

> In a related vein, in 3.1.2, should the server be allowed to exclude SCTs
> that it considers legitimate?

This is an optimization: if a server sends you SCTs A,B,C and then you
as a client report back to it "I know about SCTs A, B, and C - it
doesn't make a whole lot of sense for a server to report those to the
auditor.

I suppose; however, that an attacker may feed a server invalid SCTs
somehow to 'load it's cache' such that it never reports them. So
perhaps yes, it should report the SCTs it knows about to an auditor.

> What are the consequences if the server
> misbehaves and shares "other data that they may learn from the submission
> of SCTs by HTTP clients"?

It would be a privacy violation of the client.

> I'm also a little confused by the last paragraph of 3.1.2, "the selection
> MUST NOT be influenced by potential HTTPS clients connecting directly to
> the auditor".  It seems like the only risk of allowing a client to request
> monitoring for a given site is additional resource usage by the server
> (assuming the client is aware of the privacy considerations of making such
> a request).  I suspect that there is a valid concern here, but the text as
> written may be overly broad.

It's designed to prevent the following traffic analysis:

- Adversary is watching traffic of the auditor and client, and wants
to learn historical client behavior
- Client connects to an auditor and sends a bunch of SCTs over HTTPS
- Auditor immediately goes and queries all the domains the client sent for
- Adversary learns which domains the client sent in SCTs for

-tom