On 24 May 2017 8:33 pm, "Andrew Ayer" <[email protected]> wrote:
On Mon, 22 May 2017 16:21:54 +0200 Linus Nordberg <[email protected]> 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 [email protected] https://www.ietf.org/mailman/listinfo/trans
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
