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. > 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
