I just noticed that https://github.com/google/certificate-transparency-rfcs/pull/233 was merged, removing the STH from the get-entries response.
I am opposed to this change. The STH was added to the get-entries response to address skew between log frontends, a problem that arises today with RFC6962 deployments. Regularly, the Google CT logs will advertise a particular STH to my monitor. but fail to return entries all the way to that STH because the get-entries request is serviced by a different frontend which is lagging behind. When this happens, my monitor cannot authenticate the entries it just received, so it has to discard all of them and download them again later. This is a waste of bandwidth and slows down my monitor. Returning the latest STH with the get-entries response would allow my monitor to authenticate the entries and make forward progress. If the STH is removed from the get-entries response, this problem needs to be addressed a different way, such as by forbidding logs from exhibiting skew. I suspect that the Google log operators wouldn't like that. The same argument applies to the removal of the STH from the get-sth-consistency response (https://github.com/google/certificate-transparency-rfcs/pull/237), which I also oppose. What is the plan for the remaining PRs? If folks have comments, should we be sending them to the list now? Regards, Andrew _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
