[Cryptography] Certificate transparency on blockchains

[Tom Ritter]

On 26 March 2015 at 15:45, Greg <greg at kinostudios.com> wrote:
> Reading over it, I still have several concerns, which I will voice here but
> let me know if it would be better to also voice them on [trans].

It would be better to voice them on trans, which I am copying.  I
suggest we move it there for follow-ups.


> In Section 3.1.1, it says:
>
> <begin>
>
> HTTPS servers MUST perform a number of sanity checks on SCTs from
>    clients before storing them:
>
>    1.  if a bit-wise compare of the SCT matches one already in the
>        store, discard
>
>    2.  if the SCT can't be verified to be a valid SCT for the
>        accompanying leaf cert, issued by a known log, discard
>
>    3.  if the leaf cert is not for a domain that the server is
>        authoritative for, discard
>
>    Check number 1 is a pure optimisation.  Check number 2 is to prevent
>    spamming and attacks where an adversary can fill up the store prior
>    to attacking a client.  Check number 3 is to help misbehaving clients
>    from leaking what sites they visit.
>
> </end>
>
> Concern #1: Discarding invalid SCTs
> ============================
>
> It is not clear to me what's going on in (2) above.
>
> Specifically:
>
> - How is the server verifying the SCT for validity?


It checks if the signature over the data is valid.


> - Why is the server discarding the SCT if it is invalid?
>
> Wouldn't discarding an invalid SCT totally undermine the point of clients
> sharing them?


Keeping data for an invalid signature (or a signature for a log which
I do not recognize and thus don't have the public key) would allow
clients to store arbitrary data on your server. Complex rate-limiting
and DoS concerns now apply.



> Concern #2: The use of the word SHOULD
> =================================
>
> The doc states:
>
> (with ref to server => auditor comms):
> <begin>
>
> HTTPS servers SHOULD share all SCTs and certificate data they see
>    that pass the checks above
>
> </end>
>
> <begin>
>
> Auditors SHOULD provide the following URL accepting HTTPS POSTing of
>    SCT feedback data:
>
> </end>
>
> <begin>
>
> Auditors SHOULD regularly poll HTTPS servers at the well-known sct-
>    feedback URL.  How to determine which domains to poll is outside the
>    scope of this document
>
>
> </end>
>
>
> As per RFC2119, "SHOULD" means the advice is free to be ignored after the
> implications are "carefully weighed".
>
> This means that so far the document provides no guarantees that a
> misbehaving log will be caught.


Yup. We can't force anyone to participate unfortunately.  A client
_can_ opt-in to using a trusted auditor and send SCTs to them, which
then mitigates the concerns over a server not participating.  But I
will note that if a server does not participate they are essentially
opening themselves to attacks by logs. So they have an incentive to
participate.


> It is also disconcerting that instead of taking direct action themselves,


There is nothing stopping a server from being an auditor and detecting
log misbehavior.  I suppose we could add a note in the draft to that
effect, but it's a pretty weighty option I imagine most people will
not pursue.


> servers are supposed to initiate yet another HTTPS connection to an auditor.


(nit: Server can instead just make the SCTs available for auditors to
query and retrieve from them. Server doesn't have to initiate outbound
requests.)


> This is cumbersome and will probably leave open holes for a global MITM to
> prevent SCTs from reaching auditors, yet again undermining the entire point
> of sharing SCTs.


Yes, an attacker who can persistently isolate a client or server from
the rest of the internet is powerful, and is difficult to defeat. We
do not defend against such an attacker. I'm open to suggestions here,
but none really came to me.


> While it's definitely a positive sign that the sharing of SCTs and
> certificate chains is now an official recommendation, I am concerned that
> the particular implementation is without any teeth to deliver concrete
> results, and so until these concerns are addressed I am not convinced that
> the problem has been fully addressed.


That's fair.  There are limitations to the draft, to be sure - but
balancing the very difficult privacy concerns of literally
broadcasting the websites you've visited is also important.


-tom