[Trans] STH Discipline & Security Considerations

[Richard Barnes <[e-mail]>]

Hey all,

I wanted to follow up on my earlier comments and a bunch of side
conversations
I've had with people since then with a revised change proposal that I think
can
get -rfc6962-bis to a point we can live with.

tl;dr:
1. We/Mozilla can live with the Merkle tree for now, though we/community
might
   ultimately want something different later
2. At a systemic level, we need to move toward servers providing inclusion
   proofs, but -rfc6962-bis provides sufficient tools for this
3. We need to better document "STH discipline", and define a "canonical STH"
   for each element in the log
4. We need to update the security considerations to describe more clearly
the
   implications of various levels of auditing

I'm willing to write up a PR for (2); EKR has volunteered for (3).


# Auditing Models

There are basically two approaches to auditing available to clients:

1. Prospective: Browser does auditing checks at TLS connection time
2. Retrospective: Browser does auditing checks after TLS connection time

Prospective checking provides better assurance than retrospective, since it
prevents any harm that would come from a mis-issued, improperly-attested
certificate.  The cost is that the server has to send enough information the
cert and the browser has to cache enough information about the log that the
two
can be married up without further requests.

In practice, however, it looks like some degree of retrospective checking
will
be necessary even in browsers that support the cache enough information for
prospective checking.  On the one hand, if an inclusion proof can't be
embedded
in a cert, then we can't count on all server operators providing it (via
OCSP /
TLS).  On the other hand, including proofs in certs imposes issuance delays
that will not be acceptable in many circumstances, even if it is O(minutes).

And given Eran's SSL proxy proposal, with the amendments I suggested, I'm
now
pretty well convinced that the fetches you need for retrospective validation
can be done privately with something short of Tor (just).  The scalability
problems are bad, but probably ultimately workable.

It should be clear that either of these models work much better if the
server
provides inclusion proofs.  Together with the STH discipline notions below,
this would enable prospective auditing for all but very new certificates if
a
browser is willing to cache STHs.  Even in cases where CT information must
be
fetched, having the server send an inclusion proof would mean that the only
fetch would be for consistency, which is a less privacy-sensitive, more
cacheable query.


# STH Discipline

Either style of auditing also works better if logs have a notion of "STH
discipline", in the following sense:

1. The official state of the log comprises a sequence of STHs issued at
   specified intervals.

2. For each certificate in the log, there is a single "canonical STH" to
which
   the log will produce an inclusion proof.  Proofs to other STHs are done
by
   adding a consistency proof to the inclusion proof.

This property makes things work more smoothly in both auditing models:

- If the browser is willing to cache STHs, this tells the browser exactly
which
  STHs it needs to cache in order to validate all inclusion proofs.

- Everything is more cacheable, since there's only one inclusion proof per
  certificate, and a limited set of heads among which consistency needs to
be
  calculated.

- Cacheability means that the fetches of inclusion proofs get greater
privacy
  benefit from caching, since they depend only on the certificate, not the
STH
  that the client is using.  Likewise for consistency proofs, because of the
  reduced variety.

>From a protocol point of view, I haven't done a thorough evaluation of the
document, but there are at least a few things you would want to make this
model
work:

- Prose that articulates the above bounds on logs / inclusion proofs / STHs.
  Probably a notion of "STH issuance frequency" parallel to MMD.

- A field in an SCT that indicates the canonical STH for the certificate in
  question.  Possibly a serial number in STH that SCTs could refer to.

- An API endpoint for fetching STHs in the official sequence (in addition to
  the current one, which is the only option right now).

If this line of thinking sounds generally sane to people, I'll take a pass
through the document and make some concrete proposals.

Thanks,
--Richard