Subject: [Trans] Ticket 170

From: Melinda Shore <[email-masked]>
Date: Tue, 9 May 2017 09:50:57 -0700

Hi, all:

We have a disagreement on closing ticket 170
(https://trac.ietf.org/trac/trans/ticket/170),
on the use of distinct keys for signing SCTs and STHs.  Eran proposed
closing it as "wontfix" (i.e. not provide text describing how to use
different keys on the frontend and the backend).  Linus disagreed,
and since he's both a log implementer and operator that carries some
weight.  This needs a bit more discussion, and in particular we
need feedback from people running logs.

Melinda

---

From: Andrew Ayer <[email-masked]>
Date: Tue, 9 May 2017 11:38:26 -0700

On Tue, 9 May 2017 09:50:57 -0700
Melinda Shore <[email-masked]> wrote:

> on the use of distinct keys for signing SCTs and STHs.

I'm not entirely convinced of the security benefit.

However, speaking as a monitor/auditor implementer, I do not believe
separate keys would add any complexity to implementations - it's just a
matter of storing two keys instead of one and using the right one when
verifying signatures.  Therefore, this proposal seems like a costless
addition to the protocol that might help security.

I'm assuming logs would still be free to use the same key if they
wanted, right?

Regards,
Andrew

---

From: Melinda Shore <[email-masked]>
Date: Tue, 9 May 2017 12:20:59 -0700

> I'm assuming logs would still be free to use the same key if they

Right, and the question raised in the ticket was whether or
not key identiers needs to be added to the log metadata.

Melinda

---

From: Eran Messeri <[email-masked]>
Date: Wed, 10 May 2017 11:44:14 +0100

> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>
>

---

From: Linus Nordberg <[email-masked]>
Date: Wed, 10 May 2017 14:51:05 +0200

Eran Messeri <[email-masked]> wrote

> the value of using a separate key for each.

I've so far been thinking of a misissued SCT as a less severe breach of
log compliance. SCT's are silly creatures anyway and we'll have to
dispose of them ASAP, aight? That's probably not correct.

An adversary who can continously produce SCT's wouldn't even have
trouble fooling TLS clients which refused to accept an SCT with a
timestamp older than now() - MMD. Which leaves us with an even smaller
class of attacks.

I withdraw my support for separate keys for signing SCT's and STH's and
will update #170 to reflect this. Thanks for your patience.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 11 May 2017 12:45:23 -0800

Thank you, Linus.  I've closed the ticket as "wontfix."

Melinda