Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad

[Andrew Ayer <[e-mail]>]

On Mon, 22 May 2017 16:21:54 +0200
Linus Nordberg <[e-mail]> wrote:

> Hi,
> 
> It should be clear by now that I'd be sad if 6962bis would allow logs to
> return a different stream of bytes for the same ingoing parameters, for
> SCTs and STHs, but more interesting would be to hear other wg members
> views on the balance we're trying to strike.

I would also be sad - particularly in the case of STHs.  I may be
willing to give up mandatory consistent SCT signatures, since
privacy with SCTs might be a lost cause anyways, and because it's
hard for logs to ensure consistent SCT signatures without using
deterministic signatures (due to the need to issue SCTs from many
different frontends).  However, it doesn't seem hard for logs to have
consistent STH signatures.

> Regarding current deployment, are there any 6269bis logs deployed yet?

I don't know of any.  However, it may be interesting to note that of
the 31 publicly-known RFC6962 logs[1], all but two (Clicky and Behind
the Sofa) return the same signature for repeated get-sth requests, which
suggests that this is not a difficult requirement for STHs.  The two
logs which return a new signature for each get-sth request are running
Trillian. It would be interesting to hear from the Trillian developers
why Trillian behaves this way and whether it would be difficult to
persist STH signatures as other implementations do.

> Regarding correctness vs. completeness, what in -24 is incorrect with
> this regard?
> 
> Regarding added cost of implementation, using RSA is an option.
> 
> Regarding gossip unclearity, the suggested change risks making it harder
> to get STH gossip going.

Agreed.  We may never know how necessary consistent STH signatures are
if attempts to experiment with STH gossip are stillborn due to privacy
concerns.  It would make more sense to start out with a strong
requirement, and loosen it later if it turns out to be unnecessary.

Regards,
Andrew

[1] https://sslmate.com/labs/ct_ecosystem/ecosystem.html