Subject: [Trans] Review of draft-linus-trans-gossip-ct-02

From: Ben Laurie <[email-masked]>
Date: Mon, 20 Jul 2015 13:51:33 +0100

Comments in {} when in quoted sections.

"2.  Overview

   Public append-only untrusted {verifiable is perhaps a better word} logs "

Diagram in section 3 appears to omit SCTs delivered over OCSP.

Also, the line from CA to Website is labelled "Cert and SCT" but the SCT
may be omitted.

Section 5

"Trusted Auditor Stream, HTTPS clients communicating directly with
      trusted CT auditors/monitors sharing SCTs, certificate chains and
      STHs. {Slightly confused: section 4 mentions auditors and monitors
using this channel between themselves?}"

5.1

" Note that clients
   send the same SCTs and chains to servers multiple times with the
   assumption that a potential man-in-the-middle attack eventually will
   cease so that an honest server will receive collected malicious SCTs
   and certificate chains. {note that if an SCT is sent over a channel that
used an SCT from the same log, then that new SCT can replace the existing
one for reporting - bad behaviour is still detected - i.e. an SCT can be
considered "sent" if it is sent over a channel validated by the same log}"

5.1.1

" The client MUST
   send to the server the ones in the store that are for that server and
   were not received from that server. {comment about "sent SCTs" applies}"

"An SCT MUST NOT be sent to any other HTTPS server than one serving
   the domain that the certificate signed by the SCT refers to.{Not all TLS
clients care about privacy: e.g. crawlers, so this MUST NOT is too strong}"

"First, the server
   recieving the SCT would learn about other sites visited by the HTTPS
   client{if SCTs are gossipped then this is clearly untrue: however, I
agree that it is hard to avoid some kind of privacy leak}. "

"Secondly, auditors or monitors recieving SCTs from the HTTPS
   server would learn information about the other HTTPS servers visited
   by its clients.{ditto}"

"If the HTTPS client has configuration options for not sending cookies
   to third parties, SCTs MUST be treated as cookies with respect to
   this setting.{don't understand - you already banned sending to third
parties}"

"The data sent in the POST is defined in Section 5.1.3.{what if the POST
fails, as it obviously will for most servers initially?}"

"   3.  if the leaf cert is not for a domain that the server is
       authoritative for, the SCT MUST be discarded {only true if you ban
SCT gossip}"

" It's important to note
   that the check must be on pairs of SCT and chain in order to catch
   different chains accompanied by the same SCT.  [XXX why is this
   important?]{given that logs do _not_ have to log multiple chains, I
suspect this is actually not important}"

" Note that an HTTPS server MAY perform a certificate chain validation
   on a submitted certificate chain, and if it matches a trust root
   configured on the server (but is otherwise unknown to the server),
   the HTTPS server MAY store the certificate chain and MAY choose to
   store any submitted SCTs even if they are unable to be verified.  The
   risk of spamming and denial of service can be mitigated by
   configuring the server with all known acceptable certificates (or
   certificate hashes). {Confused by this, surely the point is to find
certs/SCTs the server does not expect?}"

5.1.3

"      *  sct_data: An array of objects consisting of the base64
         representation of the binary SCT data as defined in [RFC6962]
         Section 3.2. {SCTs may be in the certs, so should they be
replicated here or not?}"

"   The 'x509_chain' element MUST contain at{typo} the leaf certificate and
the
   full chain to a known root."

5.2

"   o  Logs cannot issue STHs too frequently.  This is restricted to 1
      per hour. {probably should refer to 6962-bis for this restriction}"

Also in 5.2, note that servers could function as their own auditors.

5.2.2

"After retrieving the consistency proof to the most recent STH, they
   SHOULD pollinate this new STH among participating HTTPS Servers {and may
safely discard the older STH}. "

5.2.3

"  o  sths - an array of 0 or more fresh STH objects [XXX recently
      collected] from the log associated with log_id.  Each of these
      objects consists of {note that we've moved to binary format for SCTs
in 6962-bis}"

6.1.1

" Therefore, a
   client with an SCT for a given server should transmit that
   information in only two channels: to a server associated with the SCT
   itself; and to a trusted CT auditor, if one exists.{only if the client
cares about privacy}"

6.1.4

"This is similar to
   the fingerprinting attack described in Section 6.1.2, but it is
   mitigated by the following factors: {mention rate limit?}"

6.1.6

"The log's inability to
      provide either proof will not be externally cryptographically-
      verifiable, as it may be indistinguishable from a network error.
{note that anyone who sees the whole log can independently prove
inconsistency/non-inclusion}"

---

From: Linus Nordberg <[email-masked]>
Date: Thu, 23 Jul 2015 11:16:05 +0200

Ben Laurie <[email-masked]> wrote
Mon, 20 Jul 2015 13:51:33 +0100:

| Comments in {} when in quoted sections.
| 
| "2.  Overview
| 
|    Public append-only untrusted {verifiable is perhaps a better word} logs "

I kind of like "untrusted" and it seems like 6962 and 6962bis do
too. But if they're changing, I guess we should consider changing here
too.

| Diagram in section 3 appears to omit SCTs delivered over OCSP.

Fixed in 03-dev (branch master in git repo at [0]).

[0] https://github.com/ln5/draft-linus-trans-gossip-ct

| Also, the line from CA to Website is labelled "Cert and SCT" but the SCT
| may be omitted.

OK. Adding brackets around "& SCT". (We need a better notation for
optional.)

| Section 5
| 
| "Trusted Auditor Stream, HTTPS clients communicating directly with
|       trusted CT auditors/monitors sharing SCTs, certificate chains and
|       STHs. {Slightly confused: section 4 mentions auditors and monitors
| using this channel between themselves?}"

Addressed in 03-dev:

# Who gossips {#who}

- HTTPS clients and servers (SCT Feedback and STH Pollination)
- HTTPS servers and CT auditors (SCT Feedback)
- CT auditors and monitors (Trusted Auditor Relationship)

Additionally, some HTTPS clients may engage with an auditor who they
trust with their privacy:

- HTTPS clients and CT auditors (Trusted Auditor Relationship)

| 5.1
| 
| " Note that clients
|    send the same SCTs and chains to servers multiple times with the
|    assumption that a potential man-in-the-middle attack eventually will
|    cease so that an honest server will receive collected malicious SCTs
|    and certificate chains. {note that if an SCT is sent over a channel that
| used an SCT from the same log, then that new SCT can replace the existing
| one for reporting - bad behaviour is still detected - i.e. an SCT can be
| considered "sent" if it is sent over a channel validated by the same log}"
|
| 5.1.1
| 
| " The client MUST
|    send to the server the ones in the store that are for that server and
|    were not received from that server. {comment about "sent SCTs" applies}"

03-dev hsa the following.

   The client MUST NOT send the same set of SCTs to the same server more
   often than TBD.  [benl: "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)]

Does this capture it? (For purposes of tracking your requested
adddition, not resolving it.)

| "An SCT MUST NOT be sent to any other HTTPS server than one serving
|    the domain that the certificate signed by the SCT refers to.{Not all TLS
| clients care about privacy: e.g. crawlers, so this MUST NOT is too strong}"

I see. Wonder how we could express that. Should we try to differentiate
between browsers with real people using them and other clients? Or bring
in "user consent"?

| "First, the server
|    recieving the SCT would learn about other sites visited by the HTTPS
|    client{if SCTs are gossipped then this is clearly untrue: however, I
| agree that it is hard to avoid some kind of privacy leak}. "

It is true for the first N clients gossiping was my first reaction. Then
there was an interesting discussion off list about if either of those
claims could be proven correct through simulation. Without more data my
position is that we don't know and should err on the side of safety and
not gossip SCTs. Not counting SCT Feedback here. That we should do.

| "Secondly, auditors or monitors recieving SCTs from the HTTPS
|    server would learn information about the other HTTPS servers visited
|    by its clients.{ditto}"

See above.

| "If the HTTPS client has configuration options for not sending cookies
|    to third parties, SCTs MUST be treated as cookies with respect to
|    this setting.{don't understand - you already banned sending to third
| parties}"

This is for local attacks, i.e. someone digging through the local
store. Should probably expand. Added a TODO for now.

| "The data sent in the POST is defined in Section 5.1.3.{what if the POST
| fails, as it obviously will for most servers initially?}"

Then no SCT Feedback is happening. Do we need to add text?

| "   3.  if the leaf cert is not for a domain that the server is
|        authoritative for, the SCT MUST be discarded {only true if you ban
| SCT gossip}"

Yes.

| " It's important to note
|    that the check must be on pairs of SCT and chain in order to catch
|    different chains accompanied by the same SCT.  [XXX why is this
|    important?]{given that logs do _not_ have to log multiple chains, I
| suspect this is actually not important}"

This could be of interest to the operator of the web site. Creating more
incentive for them to play along is probably valuable. It can be debated
whether it's worth it or not.

| " Note that an HTTPS server MAY perform a certificate chain validation
|    on a submitted certificate chain, and if it matches a trust root
|    configured on the server (but is otherwise unknown to the server),
|    the HTTPS server MAY store the certificate chain and MAY choose to
|    store any submitted SCTs even if they are unable to be verified.  The
|    risk of spamming and denial of service can be mitigated by
|    configuring the server with all known acceptable certificates (or
|    certificate hashes). {Confused by this, surely the point is to find
| certs/SCTs the server does not expect?}"

I think we thought this would help catching an SCT even if it doesn't
verify correctly by imposing some limits on the cert chain that came
with it.

| 5.1.3
| 
| "      *  sct_data: An array of objects consisting of the base64
|          representation of the binary SCT data as defined in [RFC6962]
|          Section 3.2. {SCTs may be in the certs, so should they be
| replicated here or not?}"
| 
| "   The 'x509_chain' element MUST contain at{typo} the leaf certificate and
| the
|    full chain to a known root."

Fixed.

| 5.2
| 
| "   o  Logs cannot issue STHs too frequently.  This is restricted to 1
|       per hour. {probably should refer to 6962-bis for this restriction}"
| 
| Also in 5.2, note that servers could function as their own auditors.

Would be good to mention that somewhere, yes.

| 5.2.2
| 
| "After retrieving the consistency proof to the most recent STH, they
|    SHOULD pollinate this new STH among participating HTTPS Servers {and may
| safely discard the older STH}. "

Unless it should be gossiped some more? We only know that it's correct
with regard to the particular view of the log we're being served. I
don't think we've decided when to stop gossiping about a particular STH
yet.

| 5.2.3
| 
| "  o  sths - an array of 0 or more fresh STH objects [XXX recently
|       collected] from the log associated with log_id.  Each of these
|       objects consists of {note that we've moved to binary format for SCTs
| in 6962-bis}"

Hmm. We've been looking at RFC6962 so far but that's not how to do it I
guess. I'll read up on 6962bis and change this draft accordingly.

| 6.1.1
| 
| " Therefore, a
|    client with an SCT for a given server should transmit that
|    information in only two channels: to a server associated with the SCT
|    itself; and to a trusted CT auditor, if one exists.{only if the client
| cares about privacy}"

See comment above ("I see. Wonder how we could express that.[...]")

| 6.1.4
| 
| "This is similar to
|    the fingerprinting attack described in Section 6.1.2, but it is
|    mitigated by the following factors: {mention rate limit?}"

The limitation on how often a log can issue an STH? Yes, we should look
over this section in the light of that change.

| 6.1.6
| 
| "The log's inability to
|       provide either proof will not be externally cryptographically-
|       verifiable, as it may be indistinguishable from a network error.
| {note that anyone who sees the whole log can independently prove
| inconsistency/non-inclusion}"

That's a monitor, isn't it?

---

From: Ben Laurie <[email-masked]>
Date: Thu, 23 Jul 2015 09:53:55 +0000

> don't think we've decided when to stop gossiping about a particular STH

The point is that the newer STH includes the older one (i.e. it proves the
log contains all the things the older one proved it contained), so there's
no value in retaining the older STH...

| 6.1.6

> If we define everyone who keeps a copy of the log as a monitor, then yes.
Intuitively, a mirror is not a monitor, but still has a complete copy.

---

From: Tom Ritter <[email-masked]>
Date: Fri, 24 Jul 2015 20:38:12 -0500

> between browsers with real people using them and other clients? Or bring

Well, if a crawler sends an SCT for amazon.com to ritter.vg - I'm
going to ignore it. (I don't want you filling up my disk space.)

If you configure you server to accept any SCT, and your crawler sends
all the SCTs to it... I would describe this as a Trusted Auditor
relationship, that just happens to use (roughly) the same protocol as
SCT Feedback.  How Trusted Auditors are implemented is well out of
scope. So I don't think any change is necessary, but we could clarify
I suppose.

> not gossip SCTs.

Strong ++

> store. Should probably expand. Added a TODO for now.

Did we ban sending to third parties?  I don't think so.  I know for
sure we said "don't send SCTs for amazon.com to ritter.vg".  But if
ritter.vg embeds something from https://amazon.com - that connection
_could_ send SCTs.  UNLESS the client is configured to not send
cookies on these sort of connections (the browser setting is Third
Party Cookies.)  If Third Party Cookies are disallowed, then SCTs on
such connections should also be disallowed.*

* There are probably other sorts of super-cookies amazon.com could
use, but we should not introduce a new leak.

> Then no SCT Feedback is happening. Do we need to add text?

In general we need to do a full pass and review for the cases of "What
happens if the client's attempt to send Feedback/Pollination data
fails".

> whether it's worth it or not.

I swore earlier Ben said it would be useful for site operators to
receive not only chains, but the cert ordering that was sent from the
server... but I can't find that email so perhaps I'm attributing
someone else's comments to him.  I think including the cert chain and
the cert ordering from the server* will be an open issue for a bit
longer.

* If that's even easily retrieved in the appropriate browser layer!

> verify correctly by imposing some limits on the cert chain that came

Storing the server cert and chain helps catch unknown certs.
Storing the SCT(s) may help find that cert in a log.  (Or detect
misbehavior by a log.)

So, to answer Ben's question - yes. Perhaps the "reduce the risk of
spamming" sentence was confusing?

> See comment above ("I see. Wonder how we could express that.[...]")

If they don't care about privacy, they can talk to a Trusted Auditor.
And clients of course choose their own definition of "Trusted".

> no value in retaining the older STH...

++ to this

-tom

---

From: Ben Laurie <[email-masked]>
Date: Sat, 25 Jul 2015 10:26:38 +0000

> * If that's even easily retrieved in the appropriate browser layer!

I'm pretty sure I didn't say that. Not that I am particularly opposed to
it, my position is simply that I am not sure what value it adds.

On ordering: its pretty unclear how clients deal with validating chains in
general, and whether they care about order. I know from feeding crawled
chains to logs that _many_ chains are served incorrectly, so clearly
clients are doing quite a bit of remediation on the served chains. :-)

BTW, I snipped all your comments about SCT gossip, but I do agree with your
characterisation of the recipient as some kind of Trusted Auditor. I'm not
sure I saw gossip between Trusted Auditors explicitly addressed - would
that be allowed, or dangerous?

---

From: Tom Ritter <[email-masked]>
Date: Wed, 29 Jul 2015 19:20:44 -0500

On 25 July 2015 at 05:26, Ben Laurie <[email-masked]> wrote:
> I'm pretty sure I didn't say that. Not that I am particularly opposed to it,
> my position is simply that I am not sure what value it adds.

Sorry, I don't know where it came from then.  And agreed.

> sure I saw gossip between Trusted Auditors explicitly addressed - would that
> be allowed, or dangerous?

As long as the Trusted Auditor didn't act in a predictable way with
regards to data fed by a client, I believe it is safe for them do SCT
Feedback to servers, STH pollination to servers, or send their results
directly into a whole different Trusted Auditor.  It's only dangerous
if I can observe a Client <-> Trusted Auditor connection, and make
strong inferences about what happened on that connection.  So, clients
inputs should be delayed/mixed before being acted on, and Trusted
Auditors should be _encouraged_ to both collect as many users as they
can (including other Trusted Auditors), and to do SCT Feedback and STH
Pollination as much as they can.

-tom