Re: [Trans] What logs are storing (was: The RFC6979 requirement in RFC6962-bis is bad)

On Tue, May 9, 2017 at 6:37 PM, Eran Messeri <eranm@google.com> wrote:

> The downsides with storing signatures (for SCTs and STHs), which is an
> additional storage requirement for something that can be generated
> on-the-fly:
> * Storage costs and processing: Logs have to use highly-reliable storage,
> so every piece of data stored costs more and requires more processing to be
> verified.
>

TBH the cost of running a log is mostly going to be opex, the overhead of
storing an extra few tens of GB for a really big log like Pilot are
probably not going to be that noticeable.

> * Potential corruptions: What would a log do if it finds out it stores a
> corrupted signature? It could continue operation by re-signing without
> problems, unlike a corruption of the list of entries, where it's clear it's
> unhealthy (a safety measure in some log implementations is to hash all
> entries up to the last-issued STH and verify root hash, before adding new
> entries and producing a new one).
>

This is an interesting one...
Recalculating the root of a large tree from the leaf images is a kinda*
sequential operation but verifying the signatures over SCTs+leaves can be
as obscenely parallel as your storage permits. (*Not entirely true, you can
recurse and go wide of course, but that's considerably more complicated
than existing implementations I'm aware of which mostly tend to use a
compact Merkle tree approach.)
Also, unless the corruption of your signature and/or corresponding leaf
entry caused precisely one of them to be invalid DER, you don't really have
any idea which part is wrong, so simply re-signing and continuing operation
would probably not be wise.

>
> This is a viable solution to the problem of deterministic signatures,
> though, so it should be mentioned in -bis.
> How about requiring returning the same signature for the same SCT / STH,
> without requiring the use of deterministic signature schemes?
>

At least for SCTs this is not a good idea; if you require this, then by
implication you also require a strongly consistent global queue with
deduping for putting the to-be-sequenced leaves into. That's certainly one
way of building a log, but there are others, and not everyone's got Spanner
:)

Incidentally this is why RFC6962 says  'the log ... MAY return the same SCT
as it returned before'; I'd imagine most log implementations will generally
do this because it makes sense from the operators' PoV of controlling
growth, but there may be situations when they can't guarantee it.

>
> On Tue, May 9, 2017 at 12:14 AM, Andrew Ayer <agwa@andrewayer.name> wrote:
>
>> On Tue, 09 May 2017 00:54:38 +0200
>> Linus Nordberg <linus@sunet.se> wrote:
>>
>> > Andrew Ayer <agwa@andrewayer.name> wrote
>> > Mon, 8 May 2017 11:11:41 -0700:
>> >
>> > > 3. When producing a new STH or SCT, sign it, store the signature,
>> > > and serve the stored signature instead of re-signing on-the-fly
>> > > every time the log needs to serve the STH or SCT.  Since the log
>> > > already needs to store information about STHs and SCTs, also
>> > > storing the signature should not be burdensome.
>> >
>> > Why do logs already need to store information about SCTs?
>>
>> Technically it's not required, but practically speaking logs need to
>> return an SCT for an existing entry when someone submits an
>> already-logged certificate (otherwise the log could be spammed into
>> oblivion).  To construct that SCT, the log needs to know the timestamp
>> of the existing entry.  A logical place to store the signature would be
>> alongside the timestamp.
>>
>> > Do logs already need to store information about STHs because of the
>> > proposed get-sths API [0][1][2] or something else?
>>
>> Even without the get-sths API, the log needs to store the timestamp of
>> the current STH.  That would be a logical place to store the signature.
>>
>> Regards,
>> Andrew
>>
>> _______________________________________________
>> Trans mailing list
>> Trans@ietf.org
>> https://www.ietf.org/mailman/listinfo/trans
>>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>