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

[Al Cutter <[e-mail]>]

On 24 May 2017 8:33 pm, "Andrew Ayer" <[e-mail]> wrote:

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.


The short answer is because we've not built any support for doing that yet
:)

The slightly longer answer is that Trillian is a General Transparency
implementation, rather than a CT implementation, and there are some
divisions of responsibility in there:
  - Trillian maintains the trees of opaque blobs, updating them with
batches of new entries, and creates Trillian Tree Heads (signed with
Trillian tenant keys) for each update.
 - Then there's a CT 'personality' layer in front which uses Trillian APIs
to build a CT log, and that, currently, has no distributed state, so each
instance of this personality creates a CT STH from the data in the latest
Trillian Tree Head, and signs that with the CT log's key.

The CT personality layer could certainly be extended to somehow select and
"bless" STHs in some fashion.  This idea of logging STHs would also provide
a nice mechanism for doing that, as it happens :)


> 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

_______________________________________________
Trans mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/trans