Re: [Trans] [EXT] CT Log Costs and Incentives

[Devon O'Brien <[e-mail]>]

While there might or might not be a direct financial incentive for log operation, there are stakeholders in the CT ecosystem with very compelling indirect incentives.

As Chrome has demonstrated, User Agents have the strongest incentive. They represent their users’ interest in a secure browsing experience, and detecting and responding to mis-issuances within the WebPKI solidifies that promise to their users. In most, but not all cases, User Agents tend to also have the financial and infrastructural resources in place to operate a high assurance log. Similarly, entities like certain government agencies could also step up in this area since they operate on a similar mandate.

To a lesser extent, large PKIs have an incentive to run logs as well. Given certificate logging requirements, it makes sense that a massive PKI would rather deploy and depend upon their own CT log rather than depend on what’s turned out to be a more tumultuous log ecosystem than expected. As Steve pointed out, relying on the altruism of a log operator can be a hard business case to make.

Beyond either of these two cases, log operators can charge back infrastructure costs to CAs submitting to the log. These can be volume-based fees designed to allow scalability or allow for periodic renegotiation. Personally, I like this model the least since it offers the weakest commitment to CAs and UAs for continued operation.

As has been discussed on a few occasions over the past few years, many players in the CT ecosystem don’t see the need for more than 10-20 logs to exist in total. This threshold can feasibly be met by the above cases without requiring logs to operate as a token of goodwill.

- Devon

> On Mar 23, 2017, at 09:57, Tarah Wheeler <[e-mail]> wrote:
> 
> What are the financial incentives of the non-opaque log operators? I
> mistrust altruism as regards incentive for long-term stability. Is log
> operation a loss leader for orgs that provide other, more profitable
> services?
> 
> 
> -- 
> Tarah M. Wheeler
> 
> 
> 
> 
> 
> On 3/23/17, 10:07 AM, "Trans on behalf of Steve Matsumoto"
> <[e-mail] <mailto:[e-mail]> on behalf of [e-mail] <mailto:[e-mail]>> wrote:
> 
>> Hi everyone,
>> 
>> I've been thinking lately about the incentives that certificate logs
>> have for operating, and would like to start a discussion centered around
>> the costs and incentives for certificate log operators.
>> 
>> It seems to me that CT relies on the altruism of log operators. As far
>> as I know, logs don't receive any sort of compensation for operating,
>> and of the current known and included logs listed on the CT site [1], 4
>> are run by Google and 5 are run by CAs (Symantec, WoSign/StartSSL, and
>> CNNIC) that had some sort of security incident in the past and had to
>> implement CT as a result [2-4]. So besides the fact that CT will be
>> required in October, what incentives are there to run a certificate log?
>> Are there any plans to add incentives for logs to operate?
>> 
>> Complementary to the above question is whether or not the incentives
>> that log operators have outweigh the cost of running a log. I estimate
>> that the storage cost of the certificate entries for the largest log
>> (Google Pilot) is on the order of several hundred gigabytes, and that
>> the cost of reliability, staff, etc. is quite expensive. But if there
>> are any log operators who can comment more on this, that would be great.
>> 
>> Moreover, as far as I know, CT also relies on the altruism of log
>> monitors. Logs currently don't offer a way to retrieve entries by domain
>> name, so it's difficult for a domain to query the logs for its own
>> certificates (some of which may be rogue). Moreover, proving that a
>> certificate is not in a log requires checking the entire tree.
>> Therefore, CT needs monitors who periodically retrieve all newly-logged
>> certificates and check for suspicious certificates, and it's not
>> entirely clear how monitors decide whether a certificate is suspicious.
>> What are the incentives for these monitors?
>> 
>> Given that the number of logs is small and will probably be limited by
>> Google (partially because monitoring becomes difficult otherwise), are
>> there any plans to incentivize the "best" logs, i.e., those that keep
>> the most certificates or have the highest uptime? Is incentivizing logs
>> in this way something that we should do?
>> 
>> I'd be very interested in getting feedback from everyone, particularly
>> log operators and monitors, about this.
>> 
>> -Steve
>> 
>> [1] 
>> https://clicktime.symantec.com/a/1/59oePpKbG62hyNDvpJjPTDfulpqyjTGck38AfdP <https://clicktime.symantec.com/a/1/59oePpKbG62hyNDvpJjPTDfulpqyjTGck38AfdP>
>> V-S4=?d=CAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9IvfgPMVtpK-UKNt
>> Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ5xLjGfHLMj6
>> LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEai3x8ytUDPBy
>> dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5MqM5ZYk3EqhP
>> XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9RtcflWCpFBjX8
>> p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=https%3A%2F%2Fwww.certificate-transpare
>> ncy.org <http://ncy.org/>%2Fknown-logs
>> [2]
>> https://clicktime.symantec.com/a/1/mw81gxILG0yv90ZXFS1qixOhC68j21cVWOlygtZ <https://clicktime.symantec.com/a/1/mw81gxILG0yv90ZXFS1qixOhC68j21cVWOlygtZ>
>> HNc8=?d=CAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9IvfgPMVtpK-UKNt
>> Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ5xLjGfHLMj6
>> LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEai3x8ytUDPBy
>> dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5MqM5ZYk3EqhP
>> XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9RtcflWCpFBjX8
>> p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=https%3A%2F%2Fsecurity.googleblog.com <http://2fsecurity.googleblog.com/>%2
>> F2015%2F03%2Fmaintaining-digital-certificate-security.html
>> [3]
>> https://clicktime.symantec.com/a/1/L7ETjKNjE6aJIg2kJxMA-ySmW4-RcYG3BFCECcQ <https://clicktime.symantec.com/a/1/L7ETjKNjE6aJIg2kJxMA-ySmW4-RcYG3BFCECcQ>
>> T--k=?d=CAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9IvfgPMVtpK-UKNt
>> Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ5xLjGfHLMj6
>> LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEai3x8ytUDPBy
>> dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5MqM5ZYk3EqhP
>> XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9RtcflWCpFBjX8
>> p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=https%3A%2F%2Fsecurity.googleblog.com <http://2fsecurity.googleblog.com/>%2
>> F2015%2F10%2Fsustaining-digital-certificate-security.html
>> [4]
>> https://clicktime.symantec.com/a/1/TgVn9TlunMWDKiq9pWSvDsi2V-ip6xtqx8yPiWe <https://clicktime.symantec.com/a/1/TgVn9TlunMWDKiq9pWSvDsi2V-ip6xtqx8yPiWe>
>> 0ZuM=?d=CAG1JfK0a4CVoHF5eYIXWtRfPfhblXEujp476xHAieYvJKc-xm9IvfgPMVtpK-UKNt
>> Ayuo_LQxDM_vZcwOM-XKD68Mr1VKghAGdrKdDLhRDyqeE7Wdv2QMaqfZLzptPpJ5xLjGfHLMj6
>> LmTMLEt2KSnv0aACLYGg6CTfkhgYCRANSHKsKfy_yaf0IyK7qidqN_oYO6CYyEai3x8ytUDPBy
>> dnl9HmlLO86sl5AUXAs_XfYG3reUGYOKzzL_jKBkUV25kTgwNnvNsKsgBwHRo5MqM5ZYk3EqhP
>> XTOgwbFp9icvYN76ahOcI0UmsGJVELJpI2A3CIsZ-In3uc-QQVfU92AOSlCf9RtcflWCpFBjX8
>> p_VgXXyvCywwg9cmXjr_8YzTRM6Tc%3D&u=https%3A%2F%2Fsecurity.googleblog.com <http://2fsecurity.googleblog.com/>%2
>> F2016%2F10%2Fdistrusting-wosign-and-startcom.html
>> 
>> _______________________________________________
>> Trans mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/trans <https://www.ietf.org/mailman/listinfo/trans>
> 
> _______________________________________________
> Trans mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/trans <https://www.ietf.org/mailman/listinfo/trans>