Subject: [Trans] log metadata questions

From: David Mandelberg <[email-masked]>
Date: Wed, 11 Nov 2015 00:21:02 -0500

Hi,

I have a few questions about the log metadata 
(https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-10#section-9.1):

If (1) a log issues STH A, (2) the log is compromised, (3) the log 
issues STH B, and (4) the compromise is detected and determined to have 
occurred between #1 and #3, should the log's Final STH be A or B? If I 
understand correctly, setting the Final STH to A would invalidate any 
inclusion proofs from after the compromise, but B is technically the 
last STH issued by the log.

If a log ceases operation (and sets a Final STH) due to a planned 
algorithm rollover, for how long are the log's existing SCTs and 
inclusion proofs valid?

The Maximum Chain Length appears to be a restriction for submissions 
going forward, but is it also a commitment to the maximum length of 
chains logged in the past? I.e., should a relying party reject an SCT 
that applies to (or is embedded in) a certificate with a chain of length 
greater than the log's specified Maximum Chain Length?

-- 
David Eric Mandelberg / dseomn
http://david.mandelberg.org/

---

From: Eran Messeri <[email-masked]>
Date: Wed, 11 Nov 2015 11:11:19 +0000

On Wed, Nov 11, 2015 at 5:21 AM, David Mandelberg <[email-masked]>
wrote:

> Hi,
>
> I have a few questions about the log metadata (
> https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-10#section-9.1):
>
> If (1) a log issues STH A, (2) the log is compromised, (3) the log issues
> STH B, and (4) the compromise is detected and determined to have occurred
> between #1 and #3, should the log's Final STH be A or B? If I understand
> correctly, setting the Final STH to A would invalidate any inclusion proofs
> from after the compromise, but B is technically the last STH issued by the
> log.
>
That should be STH A. Note that a frozen log is still audited like an
active one (particularly SCTs issued before STH A should be checked for
inclusion). If the log is known to be compromised before issuing STH B then
there's no point  in auditing it - and you are right that SCTs / inclusion
proofs past the tree size mentioned in STH A would not be valid.

> algorithm rollover, for how long are the log's existing SCTs and inclusion
> proofs valid?
>
I expect in this case the log would be completely removed from the list of
logs recognized by the client when all of the certificates it has logged
are either expired or are logged in other logs.

>
> The Maximum Chain Length appears to be a restriction for submissions going
> forward, but is it also a commitment to the maximum length of chains logged
> in the past? I.e., should a relying party reject an SCT that applies to (or
> is embedded in) a certificate with a chain of length greater than the log's
> specified Maximum Chain Length?

That's open for discussion - generally the issue of changing a log's
metadata has been left open as changing each metadata item has different
implications. In that case I would not expect that to be a commitment to
the maximum length of chains logged in the past, as this information is
more relevant to submitters about to submit a chain.

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Matt Palmer <[email-masked]>
Date: Thu, 12 Nov 2015 09:42:37 +1100

> are either expired or are logged in other logs.

"logged in other logs" may not be a sufficient condition to allow a log to
be removed; otherwise-valid SCTs from the terminating log may be presented
for some time.

I know SCT redundancy in certificates is supposed to guard against a log
going away, but I presume a lot more logs will stop due to planned
termination than malfeasance, and that volume of terminations might be a
problem, even with the numbers of SCTs mandated for inclusion in
certificates.

The problem may also be present for SCT presentation in the TLS
handshake or OCSP response.  What are the expected mechanisms for a server
operator to select a log (or logs) to retrieve an SCT?  How will server
operators know to switch logs when the one they logged to "goes away"?  I'm
thinking this is analogous to the "fire and forget" problem of things like
bogon lists[1], and it would be nice not to create the same problem again.

- Matt

[1] lists of "invalid" IP networks, which many network operators added as
    "drop all traffic from these prefixes" in their routers.  When the list
    of "invalid" networks changed, because addresses in those ranges started
    to be allocated, chunks of the Internet were unreachable because network
    operators weren't keeping their bogon lists up-to-date.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 17 Nov 2015 14:02:28 +0000

> proofs past the tree size mentioned in STH A would not be valid.

Should it be? Surely this depends on the exact nature of the compromise?
Note that even if a log is compromised, it has little power to do anything
interesting to the entries in the log (i.e. they're either valid chains, in
which case the log has no power to alter them, or they are not, in which
case clients of the log can ignore them) ... so it seems to me that the
simplest thing to do is include as many entries as possible in the frozen
log.

> are either expired or are logged in other logs.

The reality is that this will be decided in practice when an algorithm
rollover is needed - informed by why that rollover is needed.

>> going forward, but is it also a commitment to the maximum length of chains
>> logged in the past? I.e., should a relying party reject an SCT that applies
>> to (or is embedded in) a certificate with a chain of length greater than
>> the log's specified Maximum Chain Length?
>

Indeed, the purpose of the Maximum Chain Length was to ensure that clients
get a predictable response from a log (i.e. if submission is going to fail,
clients should be able to know in advance, where possible).