Re: [Trans] Ticket 170

On Tue, May 9, 2017 at 8:20 PM, Melinda Shore <melinda.shore@gmail.com>
wrote:

> On 5/9/17 11:38 AM, Andrew Ayer wrote:
> > I'm assuming logs would still be free to use the same key if they
> > wanted, right?
>
> Right, and the question raised in the ticket was whether or
> not key identiers needs to be added to the log metadata.
>
It's a bit more nuanced than that: We have to go through the document and
specify which key should be used for signing and which key should be used
for verification every time a signing operation is mentioned.

Adding a second key would complicate client implementation: Clients that
verify SCTs and audit them would need both keys (more metadata) and would
have to choose the right one for each verification (more logic). That
applies both to monitors and TLS clients.

It would complicate the specification and has the potential for creating a
joint that would immediately rust: If all 6962-bis logs choose to use the
same key for signing SCTs and STHs then there'd be no guarantee that
clients could cope with different keys for each.

Andrew asserts it "might help security" but does not specify how - I assume
he refers to the ability for different components of a log to be in
different security domains (front-ends that can sign SCTs are in one,
signers that issue STHs are in another).
However, compromise of any of those security domains (either in the form of
stealing key material or compelling signing of arbitrary SCTs / STHs) would
create a breach of compliance with the Merkle Tree properties required in
6962-bis:
* If a rogue SCT is issued, it will fail auditing - the log will not be
able to produce an inclusion proof to any STH.
* If a rogue STH is issued, it will fail consistency checking - the log
will not be able to produce a consistency proof to other STHs.
* If a rogue SCT and STH are issued, then the rogue STH will fail
consistency checking.

Both kinds of failure are equally bad as far as 6962-bis is concerned:
Because of the tight coupling between SCT and STH signatures, I don't see
the value of using a separate key for each.

>
> Melinda
>
>
>
> _______________________________________________
> Trans mailing list
> Trans@ietf.org
> https://www.ietf.org/mailman/listinfo/trans
>
>