Subject: [Trans] Removal of STH from get-entries response

From: Andrew Ayer <[email-masked]>
Date: Wed, 3 May 2017 09:38:45 -0700

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

---

From: Melinda Shore <[email-masked]>
Date: Wed, 3 May 2017 08:44:44 -0800

> we be sending them to the list now?

Yes, please.

Melinda

---

From: Eran Messeri <[email-masked]>
Date: Wed, 3 May 2017 17:57:24 +0100

Thanks for the feedback - I've reverted this change now, due to your and
Ben's objections (There were no objections to these changes on the trans
meeting, hence why I thought there was consensus for them).
Given there's a clear, concrete use for having this field in the
get-entries response, I proposed closing tickets 168
<https://trac.ietf.org/trac/trans/ticket/168> and 169
<https://trac.ietf.org/trac/trans/ticket/169> as wontfix.

On Wed, May 3, 2017 at 5:38 PM, Andrew Ayer <[email-masked]> wrote:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Melinda Shore <[email-masked]>
Date: Wed, 3 May 2017 09:12:54 -0800

> meeting, hence why I thought there was consensus for them).

We make decisions on the mailing list, not in meetings.
Feel free to kick the chairs if you feel something needs
to be closed and requires a decision.

That said, is there any objection to closing both 168 and 169 as
wontfix?

Melinda