Subject: [Trans] The importance of understanding auditing

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Feb 2017 12:50:12 -0800

Dear TRANS,

We had a call between a group of us last week that was helpful in
clarifying my thinking here.  I wanted to follow up to the list with some
more detailed thoughts.

At base, in order to meet this group’s charter deliverables, what we want
to be assured of is that the mechanisms in 6962-bis that are intended to
enable public verifiability can actually do so in practice.  That is, we
need to establish that there is at least one plausible story for how some
substantial fraction of the statements logs provide to clients end up
getting audited.

Part of the issue here is that we don’t have a full story anywhere in the
documents for how auditing works at scale, and there are a couple of
incomplete models floating around that lead to different design
requirements for the public verifiability parts of CT, i.e., the part that
is now the Merkle tree.  So let’s consider two straw-man models and look at
the differences they lead to.  Call them “Option G” and “Option M” :)

In the below, we assume:

- "STH" is a general term for an object that:
  1. represents the state of a log at a given time
  2. is signed by the log
  3. can be verified to fit into a linear sequence with other STHs
- Server cannot be relied upon to take action, so any CT information needs
to come to the client from the CA

Option G: Cache one STH / dynamic inclusion proofs

1. Auditor pulls STHs from logs at some frequency, validates consistency
2. Periodically, the client obtains from the auditor:
  a. The latest validated STH
  b. A proof of consistency from the last STH the client received
3. Client is configured to talk to a log proxy over DNS (for privacy)
4. Client gets SCT from server
5. Client audits by fetching inclusion proof to current STH from log proxy
over DNS

- [PRO] CA can issue immediately due to use of SCTs
- [PRO] Client only has to keep latest SCT
- [PRO] Compatible with existing CA practices w.r.t. SCTs
- [CON] Client has to reveal browsing history to log proxy in queries
- [CON] Audit failure from DNS failure indistinguishable from log
malfeasance
- [CON] Someone needs to operate a log proxy
- [CON] Requirement for audit-time fetches effectively forces audits to be
off-line w.r.t. certificate verification / TLS connection time

Option M: Cache many STHs / static inclusion proofs

1. Auditor pulls STHs from logs at some frequency, validates consistency
2. Periodically, the client obtains from the auditor:
  a. A list of all STHs since the last one the client received
  b. Proofs of consistency along this chain
3. Client caches entire history of STHs that it has received (really just
needs to store tree heads)
4. Client gets inclusion proof to an STH from server (either in the
certificate or in a stapled OCSP response), verifies it
5. Client audits by verifying that the STH provided by the server is in the
validated cache

- [PRO] Client never makes queries that are dependent on browsing history
- [PRO] Auditing can only fail if client state is stale (no live queries)
- [PRO] No need for a log proxy
- [PRO] If inclusion proof is provided at connection / validation time,
then auditing can be done immediately for certificates that are old enough
for their STHs to have propagated
- [CON] CA needs to wait for inclusion proof if inclusion proof is included
in cert
- [CON] Client needs to store entire history of STHs
- [CON] Requires CAs to upgrade to fetch inclusion proofs instead of / in
addition to SCTs

# Requirements for STHs / log structure

Option G requires:

- STHs can be issued relatively infrequently (say daily)
- Inclusion proofs need to be log depth to any STH

Option M requires:

- STHs need to be issued relatively frequently (say ~5-10min)
- Inclusion proofs need to be log depth only to the proximal STH

Option G leads naturally to the current design, with a global Merkle tree.
Option M leads to something like a Haber-Stornetta hash chain of batch
Merkle trees.  And conversely, each of these log structures is unfriendly
to the other operational model.

In general, whatever structure is assigned to the log in 6962-bis will
encode assumptions about the operation of the overall system.  So we need
to discuss the overall system before we decide on the log structure.

# What this means for 6962bis

Whatever we specify in 6962bis will enable some models for auditing and
make other models infeasible.  It’s important that whichever models 6962bis
enables not have other features that make them infeasible to deploy.

It seems to me that the two models above stake out roughly the two ends of
the design space.  I believe Option G is pretty much what Google is
planning to deploy right now, though of course I might be mistaken about
that.

Personally, between the two, I find Option M much more appealing, largely
because the failings of Option G seem much more intractable.  Log proxies
seem like a significant addition to the required infrastructure here, and
the analysis required to separate mundane failures in queries to the log
proxy from attacks on auditing seems likely to go awry.   And I have a lot
of difficulty imagining any mechanism for client queries that I would be
comfortable with from a privacy point of view.

Option M is not without problems.  We’ll need to find some way to address
the issuance delay problem, whether that entails some OCSP magic to bridge
the gap or just getting the merge delays down to where the delay is
acceptable to CAs.  We’ll need to work out some migration question about
how

But in any case, we need to get more alignment among the stakeholders here
on what models for auditing are acceptable before we finalize the public
verification mechanisms in 6962bis.

Obviously, the countersignature-related parts of the document are not tied
up in this discussion at all, so if someone wants to pull those out into a
separate document, I would have no problem advancing that to PS straight
away.

—Richard

---

From: Tom Ritter <[email-masked]>
Date: Wed, 15 Feb 2017 16:35:31 -0600

On 15 February 2017 at 14:50, Richard Barnes <[email-masked]> wrote:
> Dear TRANS,
>
> We had a call between a group of us last week that was helpful in clarifying
> my thinking here.  I wanted to follow up to the list with some more detailed
> thoughts.
>
> At base, in order to meet this group’s charter deliverables, what we want to
> be assured of is that the mechanisms in 6962-bis that are intended to enable
> public verifiability can actually do so in practice.  That is, we need to
> establish that there is at least one plausible story for how some
> incomplete models floating around that lead to different design requirements
> for the public verifiability parts of CT, i.e., the part that is now the
> Merkle tree.  So let’s consider two straw-man models and look at the
> differences they lead to.  Call them “Option G” and “Option M” :)
>
> In the below, we assume:
>
> - [PRO] If inclusion proof is provided at connection / validation time, then
> auditing can be done immediately for certificates that are old enough for
> their STHs to have propagated

Neither option specifies what the client does when it finds some data
suspicious or how it shared said data with an auditor. I'm not sure
you can leave this unspecified while trying to decide the rest of
things. For example, in Option G do you report SCTs you can't resolve
inclusion proofs for after N tries? In Option M what do you do about
STHs you don't have in your verified cache? I'm also unclear if the
log proxy is also an auditor (it seems like it implies it is, but that
doesn't seem right.)

That Option M problem is an additional con I think:
[CON] Client must cache or otherwise handle the situation when the
inclusion proof is to a STH is doesn't know about. This could be
either an attack or just a newly issued certificate. This devolves to
the case of off-line verification in G.

-tom

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 15 Feb 2017 15:38:08 -0800

On Wed, 15 Feb 2017 12:50:12 -0800
Richard Barnes <[email-masked]> wrote:
> [...]
> [...]
> - [PRO] If inclusion proof is provided at connection / validation
> time, then auditing can be done immediately for certificates that are
> old enough for their STHs to have propagated

Since a client cannot distinguish between a rogue STH and a legitimate
STH that it doesn't know about yet, it has no choice but to accept the
connection if it doesn't know about an STH and audit it later.  Therefore,
option M is no better than option G in this regard: both provide post-hoc
detection rather than prevention.  You can't call this a "pro" for option
M while simultaneously calling it a "con" for Option G.

> [...]
>
> Option M leads to something like a Haber-Stornetta hash chain
> of batch Merkle trees.

Why?  The only justification provided so far is that a client would
need to download 4MB of data a month, which is a "pretty big chunk of
data."[1]  This is a rather extraordinary claim.  Can you explain your
reasoning why 4MB a month is too much?

Even if 4MB/month is deemed excessive, there are other options which
avoid reliance on SCTs, but can be implemented on top of 6962bis'
current design without requiring clients to download 4MB a month.
Let's call them Options A1 and A2.

Option A1: Fetch consistency proofs on demand

1. Client gets an STH and an inclusion proof to the STH from server,
verifies the proof, and adds STH to a cache if not already present.

2. In the background, client audits unverified STHs in the cache
by requesting a consistency proof between the unverified STH and some
other verified STH.

- [PRO] No need to audit SCTs.
- [PRO] Although client makes queries (consistency proofs) that are triggered by
  browsing, the queries do not reveal browsing history because many certificates
  use inclusion proofs to the same STH.
- [PRO] No need for a log proxy.
- [PRO] Client only needs to fetch consistency proofs for STHs it actually sees.
- [PRO] Client only needs to store STHs it actually sees.
- [CON] CA needs to wait for inclusion proof if inclusion proof is included in cert.
- [CON] Requires CA to upgrade to fetch inclusion proofs instead of / in addition to SCTs.

I asked you on-list two weeks ago why this wouldn't work[2], but you
have not replied.

Option A2: Publicly-logged STH batches

1. Auditor pulls STHs from logs at some frequency, validates consistency.

2. Periodically, auditor logs batches of STHs to CT logs.

3. Periodically, the client obtains from the auditor:
  a. Batches of STHs since the last one the client received
  b. Inclusion proofs for each STH batch up to the log's latest STH
  c. Consistency proof between the last STH received by the client and the latest STH

4. The client verifies all proofs received from auditor, but assumes
that the STHs in the batches are legitimate.

5. Client caches entire history of STHs that it has received (really
just needs to store tree heads).

6. Client gets inclusion proof to an STH from server (either in the
certificate or in a stapled OCSP response), verifies it.

7. Client audits by verifying that the STH provided by the server is in
the cache.

8. An ecosystem of auditors monitors logs for STH batches and audits
all contained STHs by requesting consistency proofs. This saves the
client from having to verify every single STH itself.

- [PRO] No need to audit SCTs.
- [PRO] Client never makes queries in response to browsing.
- [PRO] No need for a log proxy.
- [CON] CA needs to wait for inclusion proof if inclusion proof is included in cert.
- [CON] Client needs to store entire history of STHs.
- [CON] Requires CA to upgrade to fetch inclusion proofs instead of / in addition to SCTs.

Option A2 is very similar to Option M, but avoids the need for clients
to do their own STH auditing (except for STHs related to the STH
batches). If you're happy with Option M you should be happy with Option
A2, even when implemented on top of the current Merkle Tree design.

I agree with many of your concerns about SCT auditing, but considering
that Options A1 and A2 can be implemented on top of 6962bis (plus Option
M if 4MB/month can be tolerated), I don't see why these concerns should
hold up publication.

Regards,
Andrew

[1] https://mailarchive.ietf.org/arch/msg/trans/gO_DFW3v9FmBCOek_hifZ6KL368

[2] https://mailarchive.ietf.org/arch/msg/trans/sA7ZrHIsuqWvIkF0B4I8dv8nKsY

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Feb 2017 16:01:18 -0800

On Wed, Feb 15, 2017 at 2:35 PM, Tom Ritter <[email-masked]> wrote:

> clarifying
> requirements
> then

I agree that this is important, but I don't really see a connection to log
structure.  In either case, at this stage, the client has in hand the data
it needs to claim a violation; the only question is how it get reported.

> the case of off-line verification in G.

It's true that if you get a proof to an STH you don't have, then you have
to cache it and see if you get one in a reasonable amount of time.  I
didn't count this as a CON for M because it's the same as G -- the point of
the PRO there was that M can do immediate validation in many cases, but G
never can.

--Richard

---

From: Richard Barnes <[email-masked]>
Date: Wed, 15 Feb 2017 16:33:40 -0800

> reasoning why 4MB a month is too much?

To be a bit glib -- the folks who manage syncing state out to Firefox
balked when I mentioned it to them.

Basically, that amount might not sound scary from the client side, but if
you're thinking about syncing that data out to 100s of millions of clients,
that's an extra few 100MBps of capacity you have to provision, and it's
only kinda cacheable.

> Let's call them Options A1 and A2.

To be clear, I did not mean to imply that these were the only options.  On
the contrary, I would like to have some discussion about the options here
so we can understand what requirements we should be holding 6962bis to.

Can you explain why being implemented on top of the current system is a
requirement?  I can see why it's desireable, e.g., to avoid further delay.
But in general, I would be inclined to change the spec to the web's needs
rather than the other way around.

> I asked you on-list two weeks ago why this wouldn't work[2], but you

Sorry, that's my fault.  Trying to be more responsible on this thread :)

I think this is better than option G, but there are still a couple of
concerns.  The one that's most critical to me is that you're relying on the
structure of STHs for a privacy property -- if there are too few new certs
under an STH, then your consistency query reveals your browsing history.
That seems like a very fragile assumption to be making, especially given
that we have no STH discipline / schedule in the current system.  And
making logs explicitly trusted for this privacy property seems counter to
the idea that logs are not to be trusted.

> A2, even when implemented on top of the current Merkle Tree design.

What you lose in this design relative to both G and M is the clients direct
assurance that the STHs it's relying on are a valid sequence, as opposed to
something the auditor made up.  That is, the assurance here is like if you
took G or M and removed the part where the auditor sends down the
consistency proofs.

That's not the biggest tragedy in the world, but if that's the best we can
do, we'll need to be clear about this constraint in the document ("Most
clients will need to delegate consistency checking to an auditor, which
means that they will be at risk of the auditor lying to them in the
following ways...").  But given that there are options on the table that
get us to a stranger guarantee at the cost of a spec change and some
adaptation by the small number of logs that exist, I'm not sure why we
should settle here.

> M if 4MB/month can be tolerated), I don't see why these concerns should

As I've noted above, A1 and A2 aren't really meeting my requirements.
(Maybe we should go through a requirements exercise here?)

"It's in the document" is a reason to persist in standardizing a design,
much less implementing it.  If we want to keep the current design, let's
get consensus that there's a plausible auditing story for it.  Otherwise,
let's pick another one.

--Richard

---

From: Ryan Sleevi <[email-masked]>
Date: Wed, 15 Feb 2017 17:19:07 -0800

> substantial fraction of the statements logs provide to clients end up

If I may, it seems like you're stating two (different) goals as equivalent;
the subtlety here at least deserves calling out. For recap, the charter is
https://datatracker.ietf.org/wg/trans/charter/ , with the work item being
"Publish an update to RFC 6962 as a standards-track mechanism to apply
verifiable logs to HTTP over TLS."

The subtlety here I'm calling out is that you're implicitly treating
"clients" to mean "common Web browsers". While I certainly agree that's an
important use case to consider (and certainly one we at Google have been
considering), your interpretation is much more narrower than what's
chartered, and your concerns much more specific to individual products (on
particular platforms), rather than to either the general case of "Web
browsers" or even "TLS clients".

The danger in this approach is that it bleeds dangerously close to
specifying implementation policy, when the current draft provides
infrastructure to support a variety of policies for a variety of consumers
and clients. Notable here is that you can have CT clients that may decide
to 'hard-fail' - whether browser or otherwise - and so some of the
'pragmatic' cons you highlight aren't exactly relevant to the chartered
objective, or refer to implementation details and product decisions rather
than generalized problems.

I think perhaps if we can agree on the scope and its relevance to the
charter - which you're highlighting as the key concern - we can better work
through these issues. For example, if you imagine a command-line TLS client
(such as wget or curl), neither Option M nor Option G, as you've defined
them, may be suitable. Does that mean it's necessarily to fundamentally
alter how 6962-bis works? Maybe, maybe not. Does that mean it's necessary
for such a "guidance document" to consider wget and curl's needs as
equivalent to the presumed consumers of Option M or Option G? Maybe, maybe
not.

---

From: Andrew Ayer <[email-masked]>
Date: Thu, 16 Feb 2017 11:38:01 -0800

On Wed, 15 Feb 2017 16:33:40 -0800
Richard Barnes <[email-masked]> wrote:

> > need to download 4MB of data a month, which is a "pretty big chunk
> > of data."[1]  This is a rather extraordinary claim.  Can you
> > explain your reasoning why 4MB a month is too much?
> >
> 
> Basically, that amount might not sound scary from the client side,
> but if you're thinking about syncing that data out to 100s of
> millions of clients, that's an extra few 100MBps of capacity you have
> to provision, and it's only kinda cacheable.

Ah, it's a server-side constraint. Thanks for clarifying.

Would an effective caching strategy make this implementable by Mozilla?
What if every STH and its consistency proof to the previous STH was
a separate resource?  That's trivially cacheable, and HTTP/2 makes
it cheap for the client to request lots of resources at once.

> To be clear, I did not mean to imply that these were the only
> options.  On the contrary, I would like to have some discussion about
> the options here so we can understand what requirements we should be
> holding 6962bis to.
> 
> Can you explain why being implemented on top of the current system is
> a requirement?  I can see why it's desireable, e.g., to avoid further
> delay. But in general, I would be inclined to change the spec to the
> web's needs rather than the other way around.

Does the desirability of a new design outweigh the desirability of moving
forward with the current one?  Tradeoffs always have to be made, or one
could spend forever in quest of the perfect solution.  Consider:

1. The delay would likely be significant.  RFC6962bis would need major
changes.  The gossip and threat analysis documents would need revision.
This would hold up other work.

2. We'd forgo much of the running code and implementation experience
from RFC6962.

3. There's no guarantee that a Haber-Stornetta chain is the right
solution - what if we uncover unforeseen problems in a year?

> > by requesting a consistency proof between the unverified STH and
> > some other verified STH.
> >
> concerns.  The one that's most critical to me is that you're relying
> on the structure of STHs for a privacy property -- if there are too
> few new certs under an STH, then your consistency query reveals your
> browsing history. That seems like a very fragile assumption to be
> making, especially given that we have no STH discipline / schedule in
> the current system.  And making logs explicitly trusted for this
> privacy property seems counter to the idea that logs are not to be
> trusted.

6962bis could require a minimum number of log entries between STHs,
much like it requires a minimum amount of time.  Monitors could
detect it if logs violated this requirement.

However, one could stuff the log with certificates that it knows will
never be used on the public Internet, so you're right that this option
has privacy problems which makes it inferior to options M and A2.

> > 7. Client audits by verifying that the STH provided by the server
> > is in the cache.
> >
> > Option A2 is very similar to Option M, but avoids the need for
> > clients to do their own STH auditing (except for STHs related to
> > the STH batches). If you're happy with Option M you should be happy
> > with Option A2, even when implemented on top of the current Merkle
> > Tree design.
> >
> 
> What you lose in this design relative to both G and M is the clients
> direct assurance that the STHs it's relying on are a valid sequence,
> as opposed to something the auditor made up.  That is, the assurance
> here is like if you took G or M and removed the part where the
> auditor sends down the consistency proofs.

Not quite, because in option A2, the client has assurance that every
STH it relies upon has been published for the world to see.  If a
log misbehaves and signs an inconsistent STH, and the auditor passes
that STH through to the client, someone is certain to notice and detect
the log's misbehavior.

> That's not the biggest tragedy in the world, but if that's the best
> we can do, we'll need to be clear about this constraint in the
> document ("Most clients will need to delegate consistency checking to
> an auditor, which means that they will be at risk of the auditor
> lying to them in the following ways...").

It's true that clients have to assume that someone else does the
auditing faithfully, but since the STHs are logged for anyone to
audit, this is a very safe assumption.

> But given that there are
> options on the table that get us to a stranger guarantee at the cost
> of a spec change and some adaptation by the small number of logs that
> exist, I'm not sure why we should settle here.
> 
> > I agree with many of your concerns about SCT auditing, but
> > considering that Options A1 and A2 can be implemented on top of
> > 6962bis (plus Option M if 4MB/month can be tolerated), I don't see
> > why these concerns should hold up publication.
> >
> 

I would like to convince you that A2 meets your requirements.  I contend
that its auditing guarantees are as strong as M's.  In particular, having
proof that the STHs are publicly-logged is just as good as the client
auditing them itself.  If you disagree, I'm curious why.

Regards,
Andrew

---

From: Steve KENT <[email-masked]>
Date: Thu, 16 Feb 2017 20:02:07 +0000

Ryan,

I agree that the charter for TRANS refers to TLS client in general, but the WG has long focused primarily (if not exclusively) on browsers as the TLS clients of interest for CT. For example, the gossip document talks extensively in terms of browsers and HTTPS clients, not generic TLS clients. The threat model also talks in terms of browsers as clients of TLS servers, and has done so for a very long time. For browsers we have a model of how trust anchor stores are managed and thus how info about logs could be promulgated (even though these mechanisms are not IETF standards.) For generic TLS clients I don't believe there are similar models, which would suggest gaps in the architecture.

Steve

________________________________
From: Trans <[email-masked]> on behalf of Ryan Sleevi <[email-masked]>
Sent: Wednesday, February 15, 2017 8:19:07 PM
To: Richard Barnes
Cc: [email-masked]
Subject: Re: [Trans] The importance of understanding auditing

On Wed, Feb 15, 2017 at 12:50 PM, Richard Barnes <[email-masked]<mailto:[email-masked]>> wrote:
At base, in order to meet this group's charter deliverables, what we want to be assured of is that the mechanisms in 6962-bis that are intended to enable public verifiability can actually do so in practice.  That is, we need to establish that there is at least one plausible story for how some substantial fraction of the statements logs provide to clients end up getting audited.

If I may, it seems like you're stating two (different) goals as equivalent; the subtlety here at least deserves calling out. For recap, the charter is https://datatracker.ietf.org/wg/trans/charter/ , with the work item being "Publish an update to RFC 6962 as a standards-track mechanism to apply verifiable logs to HTTP over TLS."

The subtlety here I'm calling out is that you're implicitly treating "clients" to mean "common Web browsers". While I certainly agree that's an important use case to consider (and certainly one we at Google have been considering), your interpretation is much more narrower than what's chartered, and your concerns much more specific to individual products (on particular platforms), rather than to either the general case of "Web browsers" or even "TLS clients".

The danger in this approach is that it bleeds dangerously close to specifying implementation policy, when the current draft provides infrastructure to support a variety of policies for a variety of consumers and clients. Notable here is that you can have CT clients that may decide to 'hard-fail' - whether browser or otherwise - and so some of the 'pragmatic' cons you highlight aren't exactly relevant to the chartered objective, or refer to implementation details and product decisions rather than generalized problems.

I think perhaps if we can agree on the scope and its relevance to the charter - which you're highlighting as the key concern - we can better work through these issues. For example, if you imagine a command-line TLS client (such as wget or curl), neither Option M nor Option G, as you've defined them, may be suitable. Does that mean it's necessarily to fundamentally alter how 6962-bis works? Maybe, maybe not. Does that mean it's necessary for such a "guidance document" to consider wget and curl's needs as equivalent to the presumed consumers of Option M or Option G? Maybe, maybe not.

---

From: Ryan Sleevi <[email-masked]>
Date: Thu, 16 Feb 2017 12:41:45 -0800

On Thu, Feb 16, 2017 at 12:02 PM, Steve KENT <[email-masked]>
wrote:

> Ryan,
>
>
> I agree that the charter for TRANS refers to TLS client in general, but
> the WG has long focused primarily (if not exclusively) on browsers as the
> TLS clients of interest for CT. For example, the gossip document talks
> extensively in terms of browsers and HTTPS clients, not generic TLS
> clients. The threat model also talks in terms of browsers as clients of TLS
> servers, and has done so for a very long time. For browsers we have a model
> of how trust anchor stores are managed and thus how info about logs could
> be promulgated (even though these mechanisms are not IETF standards.) For
> generic TLS clients I don't believe there are similar models, which would
> suggest gaps in the architecture.
>
Thanks for clarifying Steve.

I highlight this concern/divergence because I think it's important to
understand whether the disagreements are architectural or political. I
think the good comparison here is OCSP, OCSP Stapling, and client policy.
For a number of TLS clients (including S2S scenarios or automated tooling),
OCSP (with hardfail) is a totally viable scenario. However, we know
browsers have raised a variety of concerns with OCSP's deployment in that
model, which is where OCSP Stapling serves as a useful bridge for that.
However, even with OCSP Stapling, we cannot suggest that it's addressed the
revocation threat model unless and until OCSP stapling is mandatory for
connections - otherwise, we're back to the same problem. OCSP Stapling
being mandatory for connections is more a question of policy than of
technology.

Similarly, I think it's important to understand where our disagreements
exist on technology and whether the perspectives of concerns are things
that are true and generic, or if they are specific to certain deployment
and trust scenarios. For example, it's quite trivial and easy to imagine a
CT deployment scenario in which the client directly communicated with an
Auditor/Monitor who could fulfill all the roles necessary for the
assurances here - at a certain cost of client privacy (in their
communications with the Auditor/Monitor).

Richard's discussion highlights things in terms of "pros" and "cons", but
evaluating whether something is a pro, con, or neutral implies with it a
specific set of requirements and objectives, and I believe those
requirements and objectives may differ between potential clients - those
both active in TRANS and those absent. That's why I wanted to get a better
clarification here about the particular objective set as the WG sees it (vs
as Google, Mozilla, or other implementors may see it), and then better
articulate the requirements.

As an example, imagine a proposal which proposed that for clients, after
some period of time, an OCSP response MUST be stapled and the OCSP response
MUST include an inclusion proof to an STH within some delta of the OCSP
responses' validity period. That is a solution which is effectively coupled
to policy - such as whether OCSP responses must be stapled - and to
implementation - such as whether OCSP stapled responses should be preferred.

---

From: Steve KENT <[email-masked]>
Date: Fri, 17 Feb 2017 17:19:16 +0000

Ryan,

Thanks for the thoughtful reply and further explanation of your concerns. I agree that what constitutes a pro or con is very much a function of the perceived use context, which is why IETF WGs often (but not always) develop a set of requirements before pursuing the design of solutions. Unfortunately, that was not the case for TRANS. The charter asserts that verifiable logs are the solution for the problem of mis-issuance in the context of HTTP over TLS, but mis-issuance is not defined in the charter or in 6962-bis (although the threat doc does define the term).

If we adopt the very general context of any use of HTTP/TLS then it's harder to establish firm requirements based on uniform assumptions, because of the wide range of scenarios that are encompassed. Your discussion of OCSP stapling illustrates the problem, I believe. I support Richard's assumption that browser use of CT is a useful scope for the current doc. Also, as I noted, that context has been the focus of WG discussions since the beginning, as reflected in the two other active WG docs.

Steve

________________________________
From: Trans <[email-masked]> on behalf of Ryan Sleevi <[email-masked]>
Sent: Thursday, February 16, 2017 3:41:45 PM
To: Steve KENT
Cc: Ryan Sleevi; Richard Barnes; [email-masked]
Subject: Re: [Trans] The importance of understanding auditing

On Thu, Feb 16, 2017 at 12:02 PM, Steve KENT <[email-masked]<mailto:[email-masked]>> wrote:

Ryan,

I highlight this concern/divergence because I think it's important to understand whether the disagreements are architectural or political. I think the good comparison here is OCSP, OCSP Stapling, and client policy. For a number of TLS clients (including S2S scenarios or automated tooling), OCSP (with hardfail) is a totally viable scenario. However, we know browsers have raised a variety of concerns with OCSP's deployment in that model, which is where OCSP Stapling serves as a useful bridge for that. However, even with OCSP Stapling, we cannot suggest that it's addressed the revocation threat model unless and until OCSP stapling is mandatory for connections - otherwise, we're back to the same problem. OCSP Stapling being mandatory for connections is more a question of policy than of technology.

Similarly, I think it's important to understand where our disagreements exist on technology and whether the perspectives of concerns are things that are true and generic, or if they are specific to certain deployment and trust scenarios. For example, it's quite trivial and easy to imagine a CT deployment scenario in which the client directly communicated with an Auditor/Monitor who could fulfill all the roles necessary for the assurances here - at a certain cost of client privacy (in their communications with the Auditor/Monitor).

Richard's discussion highlights things in terms of "pros" and "cons", but evaluating whether something is a pro, con, or neutral implies with it a specific set of requirements and objectives, and I believe those requirements and objectives may differ between potential clients - those both active in TRANS and those absent. That's why I wanted to get a better clarification here about the particular objective set as the WG sees it (vs as Google, Mozilla, or other implementors may see it), and then better articulate the requirements.

As an example, imagine a proposal which proposed that for clients, after some period of time, an OCSP response MUST be stapled and the OCSP response MUST include an inclusion proof to an STH within some delta of the OCSP responses' validity period. That is a solution which is effectively coupled to policy - such as whether OCSP responses must be stapled - and to implementation - such as whether OCSP stapled responses should be preferred.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 23 Feb 2017 10:18:42 -0900

Hi, all:

The discussion seems to have settled out, and this is a
check to see where we stand.  First, in general it sounds
like there's a need for a client behavior document regardless,
and we'll take the mechanics of that to a separate discussion.
Second, Richard proposed two auditing models (one STH and
dynamic inclusion proofs, and many STHs and static inclusion
proofs), which in turn led to a discussion of what sort of
TLS client we're targeting, in the first place.  That we're
covering browsers seems uncontroversial but there's not
agreement on clients beyond that (for example, command-line
or batching tools like curl and wget).  I think this is where
I need to point out that our current deliverables specify
HTTP over TLS but not browsers, even though our documents
tend to focus on browsers, and the charter discusses the
possibility of addressing other, non-HTTP applications.

I think it would be probably be useful to have another call.
Would people involved in this discussion be up for a call
next week?

Melinda