Subject: [Trans] Long Poll

From: Evgeny <[email-masked]>
Date: Thu, 21 Mar 2019 13:47:28 +0300

I briefly read the rfc6962-bis I-D and didn't find whether it is 
possible to continuosly receive new entries. In Section 5.2 there is 
"/ct/v2/get-entries" request, but seems like it instantly returns 
entries or just an empty result. Is it possible to retrieve new entries 
via "long poll"? If not, is it planned to add this functionality to the 
spec? I find it weird to constantly issue GET requests in a loop.

---

From: Eran Messeri <[email-masked]>
Date: Thu, 21 Mar 2019 16:03:44 +0000

To put simply, the answer is no, there's no "long poll" endpoint and no
plan to add it to the spec.

The reason is it doesn't make sense to ask for new entries unless you know
they're there - by first calling get-sth to learn of a new tree head.

Generally the protocol is designed for auditing for tree consistency by a
client/monitor that observes STHs, fetches entries for the tree at the
specified size and validates the root hash published matches the one
calculated from the entries.

IIRC there are monitors that offer a polling service.

On Thu, Mar 21, 2019 at 10:47 AM Evgeny <[email-masked]> wrote:

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

---

From: Evgeny <[email-masked]>
Date: Thu, 21 Mar 2019 19:41:40 +0300

On Thu, Mar 21, 2019 at 7:03 PM, Eran Messeri <[email-masked]> wrote:
> The reason is it doesn't make sense to ask for new entries unless you 
> know they're there - by first calling get-sth to learn of a new tree 
> head.

In this case I can poll for get-sth, no? From section 8.2:

 > Fetch the current STH (Section 5.2).  Repeat until the STH changes.

How this "repeat" will look in practice? Like while(0) {... sleep(1)}?

---

From: Evgeny <[email-masked]>
Date: Thu, 21 Mar 2019 22:14:58 +0300

On Thu, Mar 21, 2019 at 7:41 PM, Evgeny <[email-masked]> wrote:
> Like while(0) {... sleep(1)}?

Oops, it should have been while(1) of course :)

---

From: Rasmus Dahlberg <[email-masked]>
Date: Fri, 22 Mar 2019 17:48:12 +0100

Hi,

You could fetch the latest STH periodically based on how often a log can produce
it: see MMD and STH frequency in Section 4.1.  For example, checking once per
hour makes sense if a log's MMD is 24 hours and its STH frequency is 24.  If you
are looking to fetch STHs today, i.e., from a log that is not CT/bis compliant,
you could learn how often STHs are normally produced by some initial polling
tests. Another option is to simply pick an interval that suits your needs,
preferably without being to aggressive based on how often STHs are produced.

On the topic of STH frequency, have anyone else noticed that Google's Icarus,
Pilot, Rocketeer and Skydiver logs switched from one hour STH interarrival times
to nearly instant updates somewhere around November 2018?  Try fetching one
hundred STHs back-to-back: most tree sizes will be unique.

If anyone knows what motivated this change I would happily be pointed in the
right direction. As many of you know, such high STH frequencies can cause a lot
of friction while experimenting and deploying various forms of gossip/auditing.

/R

---

From: Evgeny <[email-masked]>
Date: Fri, 22 Mar 2019 20:24:30 +0300

> preferably without being to aggressive based on how often STHs are 

Well, yes, I understand all this. Even if long polling is suboptimal in 
some sceanrios, what stops the authors from introducing long-polling 
API request for STH, it can be even optional. Because in my use case 
(that's a long story) I find long polling a better fit.

---

From: "Devon O'Brien" <[email-masked]>
Date: Fri, 22 Mar 2019 12:38:36 -0700

The capability to incorporate certificate logging requests, and therefore
mint substantially more frequent STHs is an artifact of the new codebase
that these CT Logs are running on. The migration was performed in November
[1] as you have observed, and was undertaken to increase reliability and
availability of these CT Logs. Frequent STHs are compliant with both RFC
6962 and the relevant CT-enforcing user agent policies, but if this
behavior is actively harmful, discussion on [email-masked] is
probably the most reliable venue for discussing changes that are outside
the scope of RFC 6962, as this will be visible to Log Operators, CAs, and
Browsers/UAs.

[1]
https://groups.google.com/a/chromium.org/d/msg/ct-policy/-AGqeW5r7ck/4M6BB9CEAQAJ

---

From: Rasmus Dahlberg <[email-masked]>
Date: Fri, 22 Mar 2019 21:30:38 +0100

Thanks, both for the link and your suggestion to bring this to Chrome's
CT policy mailing list. One of the reasons why I thought it was relevant to
bring up here is the fact that the draft developed by Nordberg, Gillmor
and Ritter depends on a sound STH frequency to preserve privacy [2].

2: https://datatracker.ietf.org/doc/draft-ietf-trans-gossip/

/R