Subject: [Trans] WGLC comments on draft-ietf-trans-6962-bis-24

From: Richard Barnes <[email-masked]>
Date: Mon, 16 Jan 2017 17:23:27 -0500

Hey all,

Sorry I’ve missed the WGLC deadline.  I wanted to summarize for this list
some discussions that have been going on within the Firefox team.
Basically, we’ve started to look at what it would take to deploy CT inside
of Firefox (including code, policy, etc), and come away with some concerns
that the system as currently specified can’t be deployed in a way that
actually provides the desired guarantees, in particular protection against
equivocation by logs.  For what it’s worth, these comments apply roughly
equally to RFC 6962 and 6962bis.

tl;dr:

- It is not practical to build a publicly verifiable log system that
incorporates SCTs
- The existing tools for public verifiability need to be made more
efficient in order to work on the scale envisioned

I recognize that it’s very late in the day to be raising these issues, but
we believe they go to the heart of the value proposition of CT and so it’s
important they be addressed before 6962bis goes to RFC. I speak for both
myself and my colleagues here at Mozilla in saying that we are more than
willing to put in the time to help get to consensus on these topics.

Details below.

Thanks,
--Richard

===

Fundamentally, CT is a public ledger system: every certificate is supposed
to be entered into a log and RPs only accept certificates which are logged.
In order for this to work properly, RPs need to be able to verify that
there is public consensus about the state of the log. Otherwise, logs can
“equivocate”: represent to the RP that a given certificate was published
when it in fact was not. Unfortunately, in practice RPs are not doing this
verification (for reasons discussed below), and so CT reduces to a
countersignature scheme in which the RP trusts the log not to equivocate.
There are two primary challenges here, as detailed below.

# SCTs, and thus immediate issuance, are incompatible with public
verifiability

It has been known for quite some time that the public verifiability piece
of CT introduces latency in certificate issuance. In order to allow for
immediate certificate issuance, logs instead issue SCTs, which are just
promises to incorporate the certificate into the log; effectively the SCT
is a countersignature on the certificate. However, if an RP accepts a
certificate + SCT, then it is vulnerable to collusion between a CA which
issues a bogus cert and a log which issues a bogus SCT but never
incorporates the cert into the log.

We are unaware of any way to efficiently address this issue without
introducing either privacy problems or latency. In order to validate
inclusion in the log, the RP needs to validate that other entities (e.g.,
the software manufacturer) have the same view of the log. Either the RP
downloads the whole log (which is inefficient), queries for the specific
certificate in question (which has privacy problems) or retrieves a
checkpoint which vouches for some batch of certificates (which introduces
batch latency).

There seem to be two major ways to address this issue:

1. Accept issuance latency: An RP will only accept a cert as valid when
accompanied by proof that it has been incorporated into the public record

2. Accept some window of vulnerability to equivocation during which SCTs
are accepted and then retrospectively checked. The RP would provisionally
accept a certificate that claimed to have been very recently issued and
then check for log presence a few minutes later (once an inclusion proof
should be available)

Unfortunately, there’s not really an effective way to accomplish the latter
with high reliability and without bad privacy problems.  Going back to the
server and asking for an inclusion proof is safe from a privacy
perspective, but there’s a significant risk of failure given how often
servers are multi-homed.  And asking anyone but the server leaks browsing
history.  It’s theoretically possible that some private information
retrieval scheme could save us, but that would be a big new chunk of work,
and unlikely to deploy in the near term.

Note that it is not possible to just not require public verifiability for
certificates which claim to be recently issued; because this attack depends
on the log and the CA colluding, they can just issue certificates with
recent timestamps.

# CT’s public verifiability mechanisms are too inefficient to be deployed
at scale

If this WG is going to meet its charter goals, CT needs to have a working
public verifiability system. What that means in practice is that it’s
efficient for the RP to acquire whatever information it needs to validate
that a certificate is in the public record. In the current system, this
basically means:

  - Acquire an inclusion proof [hopefully provided by the site the RP is
connecting to].
  - Acquire the STH that the inclusion proof chains back to and validate
that the STH was publicly logged.

Clearly in order to be efficient, multiple certs must chain back up to the
same STH; this is also a privacy requirement because otherwise retrieving a
given STH leaks which certificate you are verifying.  For similar privacy
reasons, clients need to proactively download and validate every STH they
might encounter, to avoid making queries for STHs (which leak browsing
history).  So, what this means is that the RP needs to periodically
retrieve:

  - All the STHs that any certificate might chain to
  - The consistency proofs between those STHs

The good news is that if the RP does this, then it will be in a position to
verify that any certificate with an inclusion proof has been publicly
logged; it will be protected from equivocation.  The bad news is that this
scheme generates so much data it cannot be deployed.

To get an idea of scale here, I looked all of the submissions to the Google
Pilot log over December 2016.  Let’s assume that the log creates a new STH
for every 2048 certificates it receives, in order to minimize issuance
latency; it takes around 8 minutes for Pilot to get 2048 certificates, on
average.  At this rate, Pilot produces around 6000 STHs per month.  The
good news is that at this rate, an RP can easily store all of the STHs it
needs, around ~192kB of hashes per month, ~2.3MB per year.

The bad news is that the RP has to download an inordinate amount of
information to verify these STHs. In addition to the STHs themselves, it
will need to download around 6000 consistency proofs over the course of a
month.  Each proof is around 20 hashes, so at the end of the day this is
~125k hashes (4MB of data) that an RP has to download every month, 48MB for
the year. That’s a pretty big chunk of data.

There are no doubt several plausible alternative data structures, but just
to give a sense of what’s possible, consider the following design:  Replace
the global Merkle tree with a series of time-windowed trees, one for each
batch.  Then glue these together with a conventional Haber-Stornetta hash
chain.  (See my cartoon at <https://ipv.sx/tmp/ct-hs.pdf>)  This has the
same number of STHs as the design above but because the consistency proofs
are trivial (you just validate that STH_n includes the hash of STH_{n-1}),
the total download size for the month is just ~6k hashes (192kB of data).
This scheme also saves you a few bytes on inclusion proofs, since you only
have to go to the batch level.

There are also intermediate designs that preserve the overall Merkle tree
structure at the cost of a bit more data, and probably a lot of other
designs we haven’t thought of (such as the “segmented” scheme that was in
the pre-I-D versions of CT).

In any case, if we claim that CT represent a system that is actually
publicly verifiable, then we need to get rid of SCTs and come up with a way
to push log state to RPs more efficiently.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 17 Jan 2017 10:34:34 -0500 (EST)

On Mon, 16 Jan 2017, Richard Barnes wrote:

Speaking as individual only...

> - It is not practical to build a publicly verifiable log system that incorporates SCTs
> - The existing tools for public verifiability need to be made more efficient in order to work on the scale
> envisioned

So I think there might be a different perception here of the goal of
CT. I think you are looking at a 100% catch-before-it-happens
scenario. While the document is only about "exposing rogue parties".

> Fundamentally, CT is a public ledger system: every certificate is supposed to be entered into a log and RPs
> only accept certificates which are logged. In order for this to work properly, RPs need to be able to verify
> that there is public consensus about the state of the log. Otherwise, logs can “equivocate”: represent to the
> RP that a given certificate was published when it in fact was not. Unfortunately, in practice RPs are not
> doing this verification (for reasons discussed below), and so CT reduces to a countersignature scheme in which
> the RP trusts the log not to equivocate. There are two primary challenges here, as detailed below.

The monitors are supposed to use multiple logs, presumably not all of
which are colluding. So a rogue log would be found out and lose its
trust? Maybe not in time for this one client visiting this one website,
but that was never the expected goal of CT.

> It has been known for quite some time that the public verifiability piece of CT introduces latency in
> certificate issuance. In order to allow for immediate certificate issuance, logs instead issue SCTs, which are
> just promises to incorporate the certificate into the log; effectively the SCT is a countersignature on the
> certificate. However, if an RP accepts a certificate + SCT, then it is vulnerable to collusion between a CA
> which issues a bogus cert and a log which issues a bogus SCT but never incorporates the cert into the log.

So that is someting monitors should look at.

> We are unaware of any way to efficiently address this issue without introducing either privacy problems or
> latency. In order to validate inclusion in the log, the RP needs to validate that other entities (e.g., the
> software manufacturer) have the same view of the log. Either the RP downloads the whole log (which is
> inefficient), queries for the specific certificate in question (which has privacy problems) or retrieves a
> checkpoint which vouches for some batch of certificates (which introduces batch latency).

So personally, I would like to know that ACME-style issued certificates
would start being accepted within a few minutes. At least for those
sites that did not have a certificate before. If we are talking about
renewing, then it should be able to properly submit new entries to log
before actually activating the new certs, so some latency wouldn't matter.

Am I missing something?

Paul

---

From: Richard Barnes <[email-masked]>
Date: Tue, 17 Jan 2017 10:49:12 -0500

> scenario. While the document is only about "exposing rogue parties".

Those two goals are not as different as you might think.  Either way, you
need for the client to detect equivocation.  You need the same data; it's
just a question of when.

>> to be entered into a log and RPs

I think you mean "RPs" where you say "monitors", right?

Even in this scenario, in order for the rogue log to be found out, you
still need a system for detecting equivocation, which we don't have now.

>> of CT introduces latency in
>> certificate issuance. In order to allow for immediate certificate
>> issuance, logs instead issue SCTs, which are
>> introducing either privacy problems or

As I noted in my little quantitative analysis, you can get the data
structures down to a reasonable size with a ~8min issuance delay if you're
willing to refactor the log structure.

--Richard

---

From: Rob Stradling <[email-masked]>
Date: Tue, 17 Jan 2017 16:30:23 +0000

On 17/01/17 15:34, Paul Wouters wrote:
<snip>
> scenario. While the document is only about "exposing rogue parties".
<snip>
> before actually activating the new certs, so some latency wouldn't matter.

Forking the thread to propose an idea:

Let a domain owner specify (perhaps via an extension to the proposed 
Expect-CT HTTP header?) the minimum age of each SCT that TLS clients may 
accept when establishing TLS connections to servers within that domain 
space.  (I'm imagining that minimum SCT ages would typically be measured 
in days, rather than weeks or months).

This mechanism would transform CT from a detection system to a 
prevention system.  Well, sort of.  Since each cert for that domain 
space would have to be publicly logged some number of days in advance of 
it being used, the legitimate domain owner would have a window of 
opportunity to detect a misissued cert (and request that it be revoked) 
before an attacker could actually use it for their nefarious purposes.

Of course, the downside of this mechanism is that it's a footgun.  If a 
domain owner forgets to obtain a cert and to publicly log it 
sufficiently far in advance, there will be a period of time during which 
they can't serve a compliant cert to TLS clients, even if they have a 
correctly issued cert ready to go.

Any comments?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

---

From: Tom Ritter <[email-masked]>
Date: Tue, 17 Jan 2017 11:07:47 -0600

On 17 January 2017 at 10:30, Rob Stradling <[email-masked]> wrote:
> space.  (I'm imagining that minimum SCT ages would typically be measured in
> days, rather than weeks or months).
>
> This mechanism would transform CT from a detection system to a prevention
> system.  Well, sort of.  Since each cert for that domain space would have to
> be publicly logged some number of days in advance of it being used, the
> legitimate domain owner would have a window of opportunity to detect a
> misissued cert (and request that it be revoked) before an attacker could
> actually use it for their nefarious purposes.
>
> domain owner forgets to obtain a cert and to publicly log it sufficiently
> far in advance, there will be a period of time during which they can't serve
> a compliant cert to TLS clients, even if they have a correctly issued cert
> ready to go.
>
> Any comments?

It assumes the malicious log doesn't backdate a SCT..

It also assumes the client has a clock that is correct to the order of
a few days...

-tom

---

From: Rob Stradling <[email-masked]>
Date: Tue, 17 Jan 2017 17:16:06 +0000

On 17/01/17 17:07, Tom Ritter wrote:
<snip>
> It assumes the malicious log doesn't backdate a SCT..

True.  So, require multiple SCTs from multiple logs, and let the TLS 
client consider only the age of the most recent SCT timestamp.

> It also assumes the client has a clock that is correct to the order of

True.  Is it, or might it soon be, reasonable to make that assumption?

e.g., https://roughtime.googlesource.com/roughtime sounds promising, I 
think.

---

From: Andrew Ayer <[email-masked]>
Date: Tue, 17 Jan 2017 09:40:43 -0800

On Tue, 17 Jan 2017 16:30:23 +0000
Rob Stradling <[email-masked]> wrote:

> > So personally, I would like to know that ACME-style issued
> > certificates would start being accepted within a few minutes. At
> > least for those sites that did not have a certificate before. If we
> > are talking about renewing, then it should be able to properly
> > submit new entries to log before actually activating the new certs,
> > so some latency wouldn't matter.
> 
> Expect-CT HTTP header?) the minimum age of each SCT that TLS clients
> may accept when establishing TLS connections to servers within that
> domain space.  (I'm imagining that minimum SCT ages would typically
> be measured in days, rather than weeks or months).
> 
> space would have to be publicly logged some number of days in advance
> of it being used, the legitimate domain owner would have a window of 
> opportunity to detect a misissued cert (and request that it be
> revoked) before an attacker could actually use it for their nefarious
> purposes.
> 
> Of course, the downside of this mechanism is that it's a footgun.  If
> a domain owner forgets to obtain a cert and to publicly log it 
> sufficiently far in advance, there will be a period of time during
> which they can't serve a compliant cert to TLS clients, even if they
> have a correctly issued cert ready to go.
> 
> Any comments?

I think it's a good idea.  It's a footgun, but it's much safer
than HPKP, since the minimum SCT age needn't be more than a few days.
If you screw up HPKP, you're bricked until the pins expire, which could
be months.

I would like to propose a similar mechanism that tells the client
to expect that an inclusion proof be included in the TLS handshake.
This will save clients from having to validate the SCT, which is
fraught with difficulty.  This is a worse footgun, since it will lock
server operators into using a TLS server implementation that supports
inclusion proofs, but this will become less bad as more TLS servers add
support.  It's still safer than HPKP.

Regards,
Andrew

---

From: Bill Frantz <[email-masked]>
Date: Tue, 17 Jan 2017 16:32:57 -0800

<snip>
>e.g., https://roughtime.googlesource.com/roughtime sounds promising, I think.
>

Machines such as the Raspberry PI and the Beaglebone do not have 
clock chips, although it is easy to add an external real time 
clock board. They can set their clocks from NTP if they have 
internet access, which is more-or-less needed to run a browser, 
unless running on private network. I can see scenerios where 
they can have a very badly off clock though.

Cheers - Bill

---------------------------------------------------------------------------
Bill Frantz        | Re: Computer reliability, performance, and security:
408-356-8506       | The guy who *is* wearing a parachute is 
*not* the
www.pwpconsult.com | first to reach the ground.  - Terence Kelly

---

From: Eran Messeri <[email-masked]>
Date: Wed, 18 Jan 2017 09:21:56 +0000

I agree the most suitable place for this option is the Expect-CT header
(because there's no other way for domain owners to signal any CT
preferences to the UAs right now).

As Tom points out, this is a prevention mechanism against mis-issuance by a
CA and does not provide any protection against malicious logs.

On Wed, Jan 18, 2017 at 12:32 AM, Bill Frantz <[email-masked]> wrote:

> Machines such as the Raspberry PI and the Beaglebone do not have clock
> chips, although it is easy to add an external real time clock board. They
> can set their clocks from NTP if they have internet access, which is
> more-or-less needed to run a browser, unless running on private network. I
> can see scenerios where they can have a very badly off clock though.
>
That's a real concern - Chrome folks have data around client clock accuracy
(and how that affects SSL connections), requiring client clock to be
accurate to within a day may be a high bar (again, would need data to
confirm).

> 408-356-8506       | The guy who *is* wearing a parachute is *not* the
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Rob Stradling <[email-masked]>
Date: Wed, 18 Jan 2017 12:43:22 +0000

On 18/01/17 00:32, Bill Frantz wrote:
> chips, although it is easy to add an external real time clock board.
> They can set their clocks from NTP if they have internet access, which
> is more-or-less needed to run a browser, unless running on private
> network. I can see scenerios where they can have a very badly off clock
> though.

Is it (or might it soon be) reasonable to expect a TLS client to know 
whether or not it has a reliable time source?  If so, then TLS clients 
could just ignore "minimum SCT ages" when they're insufficiently 
confident of when "now" is.

As a way of dealing with clocks that are far behind, perhaps TLS clients 
that implement CT could treat any observed SCT timestamp (that 
corresponds to any observed cert) and any observed STH timestamp as 
trustworthy evidence that these timestamps are in the past rather than 
in the future.  (If multiple SCTs/STHs from multiple logs all agree that 
time X is in the past, then the TLS client can have even greater 
confidence that this is indeed so).

---

From: Eran Messeri <[email-masked]>
Date: Wed, 18 Jan 2017 13:29:04 +0000

I find this analysis very useful, though some of it seems to be based on
different security model than the one we currently use for CT (and as Paul
pointed out, 6962 and 6962-bis are about “exposing rogue parties”).

The analysis is correct on the difficulty of public verifiability when only
SCTs are used, which we’re addressing by implementing the DNS-based protocol
<https://bugs.chromium.org/p/chromium/issues/detail?id=506227> (in part to
get data about its reliability). There’s academic work underway to get
inclusion proofs, and report log misbehaviour, in a privacy-preserving
manner (I hope to be able to share a paper soon).

Ultimately I agree with Richard’s analysis and Andrew Ayer’s comment
<https://www.ietf.org/mail-archive/web/trans/current/msg02630.html>, that
inclusion proofs (and the STHs they chain to) should be embedded in the
certificate, together with the SCT.
6962-bis specifies the mechanism
<https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-24#section-4.4>
to do it and UAs can require it as a policy.

The claim that “CT’s public verifiability mechanisms are too inefficient to
be deployed at scale” is based on the following operating assumptions for
CT (my understanding from an out-of-band chat with Richard):
- The goal is to not require auditing after the fact but have all auditing
information beforehand (stronger model).
- Logs issue STHs every 8 minutes.
- SCTs are augmented with inclusion proofs up to the STHs covering them.
- Clients download all STHs, check consistency and store them.
- When a certificate with SCT and inclusion proof is observed, it is
rejected if it’s not chaining up to one of the STHs in the client’s
storage. If it is, then the SCT’s signature and inclusion proof are checked.

This variation of CT is supposed to provide security against log
misbehaviour but is still deemed too expensive to deploy at the cost of
4MB/month of data for each client. However:
- This assumes CAs are happy to wait 8 minutes for certificate issuance
(issuance bandwidth is high, but that benefits only large-volume CAs).
- It effectively brings down the MMD to 8 minutes.
- What about clients that have been offline for a while and have yet to
catch up with recently-issued STHs? If SSL connections are blocked until a
client catches up, that’s equivalent to on-line certificate checks (OCSP).
- A clear-cached-load of Facebook clocks at 1.6MB, slashdot.org 3.2MB,
bbc.co.uk 875KB, which should give some context for the 4MB/month cost
(note not all clients have to participate; herd immunity means all clientns
benefit even if only some audit logs).
- Equivocation may not be possible, but the threat of logs presenting
split-views remains (even if all clients start with a “trusted” STH) - a
collaborative way to compare the view logs present is still necessary
(our auditing
implementation in Chrome <https://codereview.chromium.org/2017563002/> does
not require it as STHs are pushed daily to clients).

Exploration of different schemes for CT with stronger guarantees should be
independent of 6962-bis.
6962-bis allows us to address some of the issues with 6962 (like enabling
embedding of inclusion proofs) and even trial variants (using the
extensions mechanisms).

Hearing a major UA vendor state that CAs should tolerate some latency
during certificate issuance for the benefit of the ecosystem is exciting
news. We can do it with 6962-bis: newer CT log implementations and the
upcoming Trillian based implementation are capable of integrating added
chains into the tree within O(tens of seconds to minutes). Different,
potentially simpler, systems can be built under that assumption (and I’ll
let proper cryptographers suggest them :)).

Eran

On Tue, Jan 17, 2017 at 3:49 PM, Richard Barnes <[email-masked]> wrote:

>> Fundamentally, CT is a public ledger system: every certificate is
>>> supposed to be entered into a log and RPs

---

From: Richard Barnes <[email-masked]>
Date: Wed, 18 Jan 2017 10:12:59 -0500

> pointed out, 6962 and 6962-bis are about “exposing rogue parties”).

Let me again bust this myth that 6962 / 6962-bis do anything to expose
rogue logs.  Without some sort of consistency checking mechanism, logs can
lie without any risk of discovery.  That is true of CT as deployed today.
There is no way to detect a rogue log.

And a consistency checking mechanism only creates risk to rogue logs to the
degree that it is deployed and used.  If only 5% of SCTs ever get checked
for consistency, then a rogue log has a 95% chance of getting away with any
particular lie.  So we really need consistency checking at scale.

> The analysis is correct on the difficulty of public verifiability when
> only SCTs are used, which we’re addressing by implementing the DNS-based
> protocol <https://bugs.chromium.org/p/chromium/issues/detail?id=506227>
> (in part to get data about its reliability). There’s academic work underway
> to get inclusion proofs, and report log misbehaviour, in a
> privacy-preserving manner (I hope to be able to share a paper soon).
>

... and I definitely agree that 6962-bis is an improvement over 6962 in
this regard!

>
> The claim that “CT’s public verifiability mechanisms are too inefficient
> to be deployed at scale” is based on the following operating assumptions
> for CT (my understanding from an out-of-band chat with Richard):
> collaborative way to compare the view logs present is still necessary (our auditing
> implementation in Chrome <https://codereview.chromium.org/2017563002/>
> does not require it as STHs are pushed daily to clients).
>

The problem here is that the document is not clear about what guarantees it
provides, and where it tries to explain clearly it assumes a mechanism for
auditing SCTs exists.  For example:

"""
   If a server
   presents a valid signed timestamp for a certificate, then the client
   knows that a log has committed to publishing the certificate.  From
   this, the client knows that monitors acting for the subject of the
   certificate have had some time to notice the misissue and take some
   action, such as asking a CA to revoke a misissued certificate, or
   that the log has misbehaved, which will be discovered when the SCT is
   audited.
"""

The problem here is that there is no effective mechanism for auditing SCTs
right now.  The DNS thing you mention might work, though it seems to me to
have really poor scaling properties (and it is completely unimplementable
in Firefox, for software reasons).  Or the log refactoring I'm proposing
might work.  But we're clearly pretty far from consensus here.

So either we need to block this document on the creation of some auditing
mechanism that we all feel comfortable with, or we need to put some clear
warning labels on this thing in terms of the guarantees it provides, and in
particular, its vulnerability to rogue logs.

> news. We can do it with 6962-bis
>

Indeed, it sounds like we've got some consensus here at least on the
browser side of things that CAs and servers should be moving from SCTs
towards inclusion proofs.  I think there are a couple of straightforward
things we could add to the document to facilitate that transition:

* Adding an explicit lifetime to SCTs and a recommendation that RPs impose
a maximum lifetime on SCTs on the order of the STH issuance frequency of
the log
* Adding a recommendation that RPs require signatures from multiple logs

Those changes would bound the risk from SCTs in the short run, and give us
a tool to phase out SCTs in the long run (in favor of inclusion proofs).

> : newer CT log implementations and the upcoming Trillian based
> implementation are capable of integrating added chains into the tree within
> O(tens of seconds to minutes).
>

I would be interested to know what about the operation of adding to the
tree causes this degree of latency.  To be honest, it seems pretty extreme,
given the rates at which CAs are capable of operating these days.

In particular, I wonder if this is another example of the pain we have pain
we have undertaken by having a single global Merkle tree instead of some
more flexible structure.

--Richard

> Different, potentially simpler, systems can be built under that assumption
> (and I’ll let proper cryptographers suggest them :)).
>
> Eran
>
>>>> doing this verification (for reasons discussed below), and so CT
>>>> reduces to a countersignature scheme in which

---

From: Paul Wouters <[email-masked]>
Date: Wed, 18 Jan 2017 10:51:47 -0500 (EST)

On Wed, 18 Jan 2017, Richard Barnes wrote:

> Let me again bust this myth that 6962 / 6962-bis do anything to expose rogue logs.  Without some sort of
> consistency checking mechanism, logs can lie without any risk of discovery.  That is true of CT as deployed
> today.  There is no way to detect a rogue log.

6962bis defines a method of logging.

If you want to use that logging to discover bad parties, you need to use
that logging. For example:

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

Also, a description of a Monitor to perform those functions was started here:

https://tools.ietf.org/html/draft-kent-trans-monitor-auditor/

> The problem here is that the document is not clear about what guarantees it provides, and where it tries to
> explain clearly it assumes a mechanism for auditing SCTs exists.  For example:

That got spun of into a separate document:

http://tools.ietf.org/html/draft-ietf-trans-threat-analysis/

> So either we need to block this document on the creation of some auditing mechanism that we all feel
> comfortable with, or we need to put some clear warning labels on this thing in terms of the guarantees it
> provides, and in particular, its vulnerability to rogue logs.

<chair hat on>

It was decided a long time ago not to block the 6962bis document for
these other documents. Do you believe that something in the formats of
6962bis MUST be changed to accomodate its use?

We had hoped that the threat document would have been ready by the
time 6962bis went into LC. While it is close, there seems to be an
unfortunate stalemate with a few people to move this document forward
bundled with 6962bis.

If you wish to offer some text for 6962bis that would satisfy you,
that might be useful for the WG to make a decision on.

<chair hat off>

> In particular, I wonder if this is another example of the pain we have pain we have undertaken by having a
> single global Merkle tree instead of some more flexible structure.

Something like TLSA records? :)

Paul

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Jan 2017 16:08:32 +0000

> Let me again bust this myth that 6962 / 6962-bis do anything to expose rogue logs.  Without some sort of consistency checking mechanism, logs can lie without any risk of discovery.  That is true of CT as deployed today.  There is no way to detect a rogue log.

It's necessary, but not sufficient.  Just like TCP is necessary but not sufficient to enable the Web. ...

One can compare three logs and if they differ you know who and where the rogue is, right?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Jan 2017 11:57:03 -0800

> One can compare three logs and if they differ you know who and where the

Hmm.... Not unless all logs are required to have every certificate (at
least within a given scope).
Otherwise, the fact that a certificate is in log A but not log B doesn't
tell you anything about log B.

However, if all you're doing is comparing logs for consistency about a
given certificate, then you
can dispense with the entire Merkle tree structure and just have the logs
countersign certificates
they have seen.

-Ekr

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 18 Jan 2017 20:00:42 +0000

> Hmm.... Not unless all logs are required to have every certificate (at least within a given scope).
> Otherwise, the fact that a certificate is in log A but not log B doesn't tell you anything about log B.

So far the Chrome policies requires two or more, and the draft Moz policy is three or more IIRC.

So for a given CA, a disagreement identifies that *one* of the logs is wrong, right?

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 18 Jan 2017 12:14:30 -0800

> So for a given CA, a disagreement identifies that *one* of the logs is

It's quite sensitive to what the precise requirement is. So consider a
requirement
that site provide an SCT from N logs out of a set of M. Without loss of
generality,
the site gets SCTs from L_1, L_2, ... L_N but not L_N+1, ... L_M. The fact
that
the site's cert appears in L_1 but not L_M is normal and doesn't tell you
that
either one of them is wrong. (This is just the basic non-adversarial case).

Now, consider the adversarial case, where an attacker as corrupted a CA and
N logs out of M. Similarly, they will get N SCTs from those corrupt logs
(which
might not be the ones that the actual legitimate site used for their SCTs,
but the
client doesn't know that [0]. And again, the lack of an SCT from the
non-corrupt
log doesn't tell you anything.

Now, in the special case where N==M, then inconsistencies are meaningful,
and this is the case with Chrome's "one of the logs must be Google" policy,
but
as far as I can tell that's not something that's true in the general case.

-Ekr

[0] Modulo some sort of log pinning.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 19 Jan 2017 18:09:28 +0000

> can see scenerios where they can have a very badly off clock though.

So, machines in that position should not try to enjoy the full protection of CT.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 19 Jan 2017 18:13:41 +0000

On 18 January 2017 at 12:43, Rob Stradling <[email-masked]> wrote:
> whether or not it has a reliable time source?  If so, then TLS clients could
> just ignore "minimum SCT ages" when they're insufficiently confident of when
> "now" is.

Exactly.

> that implement CT could treat any observed SCT timestamp (that corresponds
> to any observed cert) and any observed STH timestamp as trustworthy evidence
> that these timestamps are in the past rather than in the future.  (If
> multiple SCTs/STHs from multiple logs all agree that time X is in the past,
> then the TLS client can have even greater confidence that this is indeed
> so).
>
> --
> Rob Stradling

---

From: Ben Laurie <[email-masked]>
Date: Fri, 20 Jan 2017 14:23:27 +0000

On 18 January 2017 at 15:12, Richard Barnes <[email-masked]> wrote:
> Let me again bust this myth that 6962 / 6962-bis do anything to expose rogue
> logs.  Without some sort of consistency checking mechanism, logs can lie
> without any risk of discovery.  That is true of CT as deployed today.  There
> is no way to detect a rogue log.
>

I have two problems with this statement:

1. A 95% chance of getting away with a particular lie rapidly erodes
to effectively no chance of getting away with multiple lies (for
example, getting away with 100 lies is about .5% chance).

2. To get coverage better than 5% surely only requires a tiny fraction
of all browsers (which vastly outnumber certificates), not "at scale".

I do not disagree that it is necessary to do consistency checking, however.

---

From: Tom Ritter <[email-masked]>
Date: Fri, 20 Jan 2017 09:28:02 -0600

> example, getting away with 100 lies is about .5% chance).

In a perfectly random distribution, yes. But I expect that the
attacker could choose the lie so the distribution is perfect or
grossly in their favor - either because the website does not deploy
some mechanism they need to participate (e.g. SCT Feedback) or because
the attacker filters DNS from the clients they attack or they choose
to attack clients they know do not enable consistency checking or by
selectively blocking connections...

All depends on deployment details of course.

-tom