Subject: Re: [Trans] Write-up of the "Strict CT" variant

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Tue, 6 Jun 2017 12:28:19 -0700

I'll echo what Filippo said and say that fast issuance (order of
minutes) is important, and anything that breaks fast issuance for new
sites (or for sites moving between providers) is a problem. In the long
run, getting a certificate will be part of standing up a web site just
as much as getting DNS and hosting are today. Are we willing to ask the
web to accept a delay of 24 hours for any new site? I think that would
be a big step backwards.

On 05/23/2017 05:42 AM, Eran Messeri wrote:
> Options for dealing with the delayed usability of certificates:
>
>   * Opt-in: servers requires presence of proofs via header / X.509
>     extension [6].
>
This seems like the most plausible option, with the same caveats as HSTS
about first visit. However, if Strict CT is only applied for a small
number of sites that opt in, is it worth the extra ecosystem complexity?
It seems like Strict CT on an opt-in basis would not be a meaningful
substitute for gossip.

> Certificate is used immediately, only with SCT: Clients accept
certificates only with SCTs for a limited duration; after that an
inclusion proof must be accompanied [4].
> [4] That requires auditing logs asynchronously, since an attacker with
persistent access could keep getting new SCTs issued, or some clients
may not have fresh STHs because they missed some updates.

This seems potentially promising but I think it has some flaws. Would
this auditing be done by the logs themselves, or by monitors? IIUC, logs
are allowed to produce infinite SCTs for the same cert once they've
logged it, and they don't have to produce the list of SCTs they've
signed. So the only party that could meaningfully audit for excessive
SCT generation would be the log itself, which is the party we're trying
to defend against.

---

From: Magnus Ahltorp <[email-masked]>
Date: Wed, 7 Jun 2017 14:51:39 +0200

6 June 2017 21:28 Jacob Hoffman-Andrews <[email-masked]> wrote:

> I'll echo what Filippo said and say that fast issuance (order of minutes) is important, and anything that breaks fast issuance for new sites (or for sites moving between providers) is a problem. In the long run, getting a certificate will be part of standing up a web site just as much as getting DNS and hosting are today. Are we willing to ask the web to accept a delay of 24 hours for any new site? I think that would be a big step backwards.

Well, that depends on the assurance level, doesn't it? For domain-validated certificates, sure, but those are next to worthless anyway. It would be hard to hold a CA responsible for issuing them, so the need for logging them is really small.

> > Certificate is used immediately, only with SCT: Clients accept certificates only with SCTs for a limited duration; after that an inclusion proof must be accompanied [4].
> > [4] That requires auditing logs asynchronously, since an attacker with persistent access could keep getting new SCTs issued, or some clients may not have fresh STHs because they missed some updates.
> 
> This seems potentially promising but I think it has some flaws. Would this auditing be done by the logs themselves, or by monitors? IIUC, logs are allowed to produce infinite SCTs for the same cert once they've logged it, and they don't have to produce the list of SCTs they've signed. So the only party that could meaningfully audit for excessive SCT generation would be the log itself, which is the party we're trying to defend against.

If we are talking about "limited duration" of SCTs, we are talking about the age of the timestamp in the SCT. Each timestamp that is used to generate an SCT is required to be logged in the log. That is what the log is logging, cert+timestamp.

/Magnus

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 7 Jun 2017 09:08:09 -0400

On Wed, Jun 7, 2017 at 8:51 AM, Magnus Ahltorp <[email-masked]> wrote:

> Well, that depends on the assurance level, doesn't it? For
> domain-validated certificates, sure, but those are next to worthless
> anyway. It would be hard to hold a CA responsible for issuing them, so the
> need for logging them is really small.
>

Let's not introduce CAs' marketing distinction into the technical
discussion.

Domain validated certificates - the basis for the Web PKI - are the only
security level that matter. The holder of such a certificate can
impersonate any site named in the certificate - whether from example.com to
google.com.

The other forms of certificates, "Organizationally Validated" or "Extended
Validation", or, in the EU, Qualified Website Authentication Certificates,
while nominally trying to provide higher assurance, do not meaningfully do
so in the security model of the Web (which is the Origin).

To that end, the past decade of CA misissuance responses have come down, in
part, to the misissuance of certificates that attest to a websites
identity, and CAs have been held responsible.

I can totally appreciate a perspective that believes that CAs' human
processes are far more secure than their automated processes, even if that
perspective is not supported by the data. However, if we accept that - from
a pragmatic and practical security perspective - that identifying a website
grants the capability of TLS termination (namely, lacking an EKU or having
an id-kp-serverAuth EKU, and naming one or more dNSName or iPAddress
identities in a SAN) - then these certificates are very much in scope of
the Web PKI, and thus need to be logged, as they present risk to the Web
PKI consumers.

> certificates only with SCTs for a limited duration; after that an inclusion
> proof must be accompanied [4].
> persistent access could keep getting new SCTs issued, or some clients may
> not have fresh STHs because they missed some updates.
> >
> are allowed to produce infinite SCTs for the same cert once they've logged
> it, and they don't have to produce the list of SCTs they've signed. So the
> only party that could meaningfully audit for excessive SCT generation would
> be the log itself, which is the party we're trying to defend against.
>
> If we are talking about "limited duration" of SCTs, we are talking about
> the age of the timestamp in the SCT. Each timestamp that is used to
> generate an SCT is required to be logged in the log. That is what the log
> is logging, cert+timestamp.
>

I think this may have resulted from a misunderstanding. I'll try to explain
one such scenario.

Consider at T=0, Certificate X is logged, and an SCT(X, 0) is issued. The
proof that such SCT has been incorporated into the STH will not be required
until T=24, so such a certificate can be used (without proof of inclusion)
from T=0 to T=24.

Now, if I am a malicious CA, a T=23, I approach the log again, and request
SCT(X, 23). The log, colluding with the CA, issues SCT(X, 23) - rather than
the expect SCT(X, 0). Further, the log does not incorporate the SCT(X, 0)
into STH(24) - it silently discards it.

Clients will not expect to see a proof of this inclusion until STH(47) -
that is, SCT(X, 23) + 24.

On T=46, I repeat this process, obtaining SCT(X, 46), and clients not
expecting this until STH(70).

By the CA and Log colluding, I can continue to extend the period upon which
I, the Evil Log, do not log this certificate.

This situation arises because the SCTs can be delivered through multiple
means, so it does not necessarily need to be fixed in the certificate. Yet
even if it was fixed in the certificate, so long as I, the Evil Server,
stop serving the cert prior to T=24, clients won't check the inclusion
proof. This is why it was remarked that some form of auditing - of the SCTs
produced by the log - would need to be asynchronously done, to ensure that
SCT(X, 0) wasn't 'extended' beyond that.

---

From: Magnus Ahltorp <[email-masked]>
Date: Wed, 7 Jun 2017 15:29:29 +0200

7 June 2017 15:08 Ryan Sleevi <[email-masked]> wrote:

> Let's not introduce CAs' marketing distinction into the technical discussion.
> 
> Domain validated certificates - the basis for the Web PKI - are the only security level that matter. The holder of such a certificate can impersonate any site named in the certificate - whether from example.com to google.com.
> 
> The other forms of certificates, "Organizationally Validated" or "Extended Validation", or, in the EU, Qualified Website Authentication Certificates, while nominally trying to provide higher assurance, do not meaningfully do so in the security model of the Web (which is the Origin).
> 
> To that end, the past decade of CA misissuance responses have come down, in part, to the misissuance of certificates that attest to a websites identity, and CAs have been held responsible.
> 
> I can totally appreciate a perspective that believes that CAs' human processes are far more secure than their automated processes, even if that perspective is not supported by the data. However, if we accept that - from a pragmatic and practical security perspective - that identifying a website grants the capability of TLS termination (namely, lacking an EKU or having an id-kp-serverAuth EKU, and naming one or more dNSName or iPAddress identities in a SAN) - then these certificates are very much in scope of the Web PKI, and thus need to be logged, as they present risk to the Web PKI consumers.

CAs cannot be held responsible for domain-validated certificates for the simple reason that they don't have documentation, and therefore cannot be required to produce documentation, which means that they can claim anything.

> I think this may have resulted from a misunderstanding. I'll try to explain one such scenario.
> 
> Consider at T=0, Certificate X is logged, and an SCT(X, 0) is issued. The proof that such SCT has been incorporated into the STH will not be required until T=24, so such a certificate can be used (without proof of inclusion) from T=0 to T=24.
> 
> Now, if I am a malicious CA, a T=23, I approach the log again, and request SCT(X, 23). The log, colluding with the CA, issues SCT(X, 23) - rather than the expect SCT(X, 0). Further, the log does not incorporate the SCT(X, 0) into STH(24) - it silently discards it.
> 
> Clients will not expect to see a proof of this inclusion until STH(47) - that is, SCT(X, 23) + 24.
> 
> On T=46, I repeat this process, obtaining SCT(X, 46), and clients not expecting this until STH(70).
> 
> By the CA and Log colluding, I can continue to extend the period upon which I, the Evil Log, do not log this certificate.
> 
> This situation arises because the SCTs can be delivered through multiple means, so it does not necessarily need to be fixed in the certificate. Yet even if it was fixed in the certificate, so long as I, the Evil Server, stop serving the cert prior to T=24, clients won't check the inclusion proof. This is why it was remarked that some form of auditing - of the SCTs produced by the log - would need to be asynchronously done, to ensure that SCT(X, 0) wasn't 'extended' beyond that.

It is definitely possible to generate new timestamps and not log them, but I was rebutting "they don't have to produce the list of SCTs they've signed", which is not true, unless "don't have to" is different from "not required to". Logs are required to produce the list of all timestamps they have signed when MMD has passed. That is what it means to be a log.

/Magnus

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 7 Jun 2017 09:57:17 -0400

On Wed, Jun 7, 2017 at 9:29 AM, Magnus Ahltorp <[email-masked]> wrote:

> CAs cannot be held responsible for domain-validated certificates for the
> simple reason that they don't have documentation, and therefore cannot be
> required to produce documentation, which means that they can claim anything.
>

At the risk of going offtopic, by broadening into policy discussions, at
least with respect to the Web PKI - which is certainly the only (publicly)
deployed instance of CT,
https://cabforum.org/baseline-requirements-documents/ govern and
https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.4.5.pdf
applies (Sections 3.2.2.4 & .5 and Section 5.4)

TL;DR: Yes they do produce documentation, no, they cannot claim anything.

> It is definitely possible to generate new timestamps and not log them, but
> I was rebutting "they don't have to produce the list of SCTs they've
> signed", which is not true, unless "don't have to" is different from "not
> required to". Logs are required to produce the list of all timestamps they
> have signed when MMD has passed. That is what it means to be a log.

I'm not sure your usage of "required" to. If you mean in the abstract,
philosophical sense - yes, a well-behaving log is expected to do so.

However, an evil log can lie - and not produce such timestamps, by not
integrating them into the log, despite having signed them. Which was the
point - only an Honest Log can audit the production of all of its SCTs and
make sure they're integrated, but the concern here is about a Dishonest
Log, which would only integrate some of the SCTs into the STH.

---

From: Magnus Ahltorp <[email-masked]>
Date: Wed, 7 Jun 2017 16:36:17 +0200

7 June 2017 15:57 Ryan Sleevi <[email-masked]> wrote:

> I'm not sure your usage of "required" to. If you mean in the abstract, philosophical sense - yes, a well-behaving log is expected to do so.
> 
> However, an evil log can lie - and not produce such timestamps, by not integrating them into the log, despite having signed them. Which was the point - only an Honest Log can audit the production of all of its SCTs and make sure they're integrated, but the concern here is about a Dishonest Log, which would only integrate some of the SCTs into the STH. 

But then "they don't have to produce the list of SCTs they've signed" would be a meaningless statement, since no action by anyone in the world would make them "have to" do anything. The only reasonable interpretation of "have to" in this context is what is called "MUST" in RFC 2119. If you mean "can do this undetected until time t", then say so.

But, in the same sentence, Jacob wrote: "IIUC, logs are allowed to produce infinite SCTs for the same cert once they've logged it", which is what I based my answer on. If the log disregards all rules and doesn't care about being discovered as a bad log, surely it wouldn't care about whether it was allowed to produce many SCTs for the same cert or not. Which means that restricting that wouldn't solve that problem.

/Magnus

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 7 Jun 2017 11:31:09 -0400

On Wed, Jun 7, 2017 at 10:36 AM, Magnus Ahltorp <[email-masked]> wrote:
>
> But, in the same sentence, Jacob wrote: "IIUC, logs are allowed to produce
> infinite SCTs for the same cert once they've logged it", which is what I
> based my answer on. If the log disregards all rules and doesn't care about
> being discovered as a bad log, surely it wouldn't care about whether it was
> allowed to produce many SCTs for the same cert or not. Which means that
> restricting that wouldn't solve that problem.
>

I think there may be some disconnect here still, unfortunately.

For example, in your response, you note "and doesn't care about being
discovered about a bad log". The concerns raised - with respect to the
production of SCTs and the deferring of inclusion proof fetching on the
basis of that timestamp - were to highlight that it creates a scenario in
which a bad log would not be discovered using the scheme, as proposed. This
is why it was highlighted that 'someone' would have to examine the SCTs
produced - including those _before_ the 'must include inclusion proof' time
- so make sure that those SCTs were, in fact, logged. Which brings us back
to the original problem, of clients checking inclusion proofs of SCTs
asynchronously/out-of-band (and/or gossiping them), which suggests that a
solution of stapled inclusion proofs (with a 'grace period') doesn't solve
the client-checking problem, and the (original) discussion of stapled
inclusion proofs (with no grace period) is operationally unviable, because
it means a certificate cannot be deployed until the inclusion. These were
all motivating design factors in both the original and subsequent designs
of 6962 and 6962-bis, but were perhaps not articulated clearly as such.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 7 Jun 2017 11:44:54 -0400

> Let's not introduce CAs' marketing distinction into the technical

​Marketing is sometimes based on facts. In this case inconvenient facts for
people proposing to trash the WebPKI trust model. If you want to spread
disinformation, then I am going to respond to correct.

https://www.scmagazineuk.com/updated-97-of-malicious-mobile-malware-targets-android/article/535410/

The press have stopped writing articles about 97% of malware targeting
Android because it is no longer news. Apple do have some advantages in
their structure besides enforcing what amounts to EV validation of
developers. But it is the validation of every developer before they get
developer credentials that makes the rest of their model feasible.

> impersonate any site named in the certificate - whether from example.com
> to google.com.
>

​Domain Validation is not the 'basis' for the WebPKI. It did not even exist
until late in the dotCom boom. The WebPKI was originally designed to
establish accountability. It is the bridge between the online and offline
accountability infrastructure.

What was not anticipated in the original design was that there would be a
demand for certificates that only provided encryption and a minimal level
of authentication. And in our defense, I will point out that even the banks
were not encrypting their entire sites until quite late in the game. Back
in 1997, RSA was a serious resource hog even at 1024 bits and SSL
accelerators were only just starting to exist in usable form (you could buy
'em, taking delivery was another matter).

> so in the security model of the Web (which is the Origin).

​I suggest that stating that the Web has a single security model is
obviously wrong.

The JavaScript security model is origin but even that is a retrofit and it
is not the Web security model.​

> To that end, the past decade of CA misissuance responses have come down,
> in part, to the misissuance of certificates that attest to a websites

Issuance ​of phishing certificates with Paypal in the name is exploding.
But if you aren't actually bothered about phishing fraud, I guess you can
claim an improvement.

One of the facts that the industry is going to have to face is that there
is a choice, only one of the following can be true:

* Every site is encrypted.
* Certificates are not issued to criminals.

​Now the WebPKI model for EV and DV is very much that the second is true
and always has been in the 25 years I have been involved in its
development. And no, I do not need an adventure in 'alternative history'. I
was there. I was part of the original design discussions.

What I am getting at though is something different. There are in fact
multiple security concerns for a system as large as the Web and one size
fits all security is not going to work. The problem with equating enabling
encryption with 'security' is that it just is not so. Encryption is a
starting point for security but it is a weak one. That was how I broke
SSL/1.0, Marc had only considered confidentiality as a security concern.

The way to address the conflict raised above is to observer that while it
is true that every communication should be encrypted, it is not true that
every communication should be represented to the user as providing
security.

What we need to do is to bifurcate the DV level and distinguish between
certificates that only enable confidentiality and those that provide
authentication. The first would become a new category 'minimal validation'
and would not be required to prevent issue of paypal certificates etc, or
provide for revocation or any other controls. The second would be an
enhanced DV providing full revocation and lifecycle management.

> perspective is not supported by the data.
>

​Actually it is.

The work factor for obtaining an EV cert as a criminal is markedly higher
than for DV which is in turn markedly higher than that for those who don't
do any lifecycle controls.
​

​PHB​

---

From: Watson Ladd <[email-masked]>
Date: Sun, 11 Jun 2017 18:22:56 -0700

On Jun 7, 2017 8:45 AM, "Phillip Hallam-Baker" <[email-masked]> wrote:

> Let's not introduce CAs' marketing distinction into the technical discussion.

Marketing is sometimes based on facts. In this case inconvenient facts
for people proposing to trash the WebPKI trust model. If you want to
spread disinformation, then I am going to respond to correct.

The press have stopped writing articles about 97% of malware targeting
Android because it is no longer news. Apple do have some advantages in
their structure besides enforcing what amounts to EV validation of
developers. But it is the validation of every developer before they
get developer credentials that makes the rest of their model feasible.

> Domain validated certificates - the basis for the Web PKI - are the only security level that matter. The holder of such a certificate can impersonate any site named in the certificate - whether fro…

Domain Validation is not the 'basis' for the WebPKI. It did not even
exist until late in the dotCom boom. The WebPKI was originally
designed to establish accountability. It is the bridge between the
online and offline accountability infrastructure.

So I get to sue Verisign if they issue a cert incorrectly? Oh wait,
that isn't actually the case: CAs disclaim all responsibility for what
you say they they are supposed to do. Was it ever the case that this
was possible?