Subject: [therightkey] Revised Draft Charter for Transparency WG

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Jan 2014 16:14:24 +0000

Problem statement: many Internet protocols require a mapping between
some kind of identifier and some kind of key, for example, HTTPS,
SMTPS, IPSec, DNSSEC and OpenPGP.

These protocols rely on either ad-hoc mappings, or on authorities
which attest to the mappings.

History shows that neither of these mechanisms is entirely
satisfactory. Ad-hoc mappings are difficult to discover and maintain,
and authorities make mistakes or are subverted.

Cryptographically verifiable logs[1] can help to ameliorate the
problems by making it possible to discover and rectify errors before
they can cause harm.

These logs can also assist with other interesting problems, such as
how to assure end users that software they are running is, indeed, the
software they intend to run.

Work items: Specify a standards-track mechanism to apply verifiable
logs to HTTP/TLS (i.e. RFC 6962-bis).

Discuss mechanisms and techniques that allow cryptographically
verifiable logs to be deployed to improve the security of protocols
and software distribution. Where such mechanisms appear sufficiently
useful, the WG will re-charter to add relevant new work items.

[1] A cryptographically verifiable log is an append-only log of hashes
of more-or-less anything that  is structured in such a way as to
provide efficiently-accessible, cryptographically-supported evidence
of correct log behaviour.

For example, from RFC 6962: “The append-only property of each log is
technically achieved using Merkle Trees, which can be used to show
that any particular version of the log is a superset of any particular
previous version. Likewise, Merkle Trees avoid the need to blindly
trust logs: if a log attempts to show different things to different
people, this can be efficiently detected by comparing tree roots and
consistency proofs. Similarly, other misbehaviors of any log (e.g.,
issuing signed timestamps for certificates they then don't log) can be
efficiently detected and proved to the world at large.”

See RFC 6962, http://www.links.org/files/CertificateTransparencyVersion2.1a.pdf
and http://www.links.org/files/RevocationTransparency.pdf for
background.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 7 Jan 2014 08:35:16 -0800

I support the formation of this WG with basically this charter. However, having footnote in a charter make it harder to read. Having URLs that are not somewhat guaranteed to be available forever (such as those run by the IETF) make the charter unstable. A proposed editorial-only cleanup:

Problem statement:

Many Internet protocols require a mapping between some kind of identifier and some kind of
key, for example, HTTPS, SMTPS, IPSec, DNSSEC and OpenPGP.

These protocols rely on either ad-hoc mappings, or on authorities which attest to the
mappings.

History shows that neither of these mechanisms is entirely satisfactory. Ad-hoc mappings are
difficult to discover and maintain, and authorities make mistakes or are subverted.

Cryptographically verifiable logs can help to ameliorate the problems by making it possible
to discover and rectify errors before they can cause harm. A cryptographically verifiable
log is an append-only log of hashes of more-or-less anything that  is structured in such a
way as to provide efficiently-accessible, cryptographically-supported evidence of correct
log behaviour. For example, RFC 6962 says: "The append-only property of each log is
technically achieved using Merkle Trees, which can be used to show that any particular
version of the log is a superset of any particular previous version. Likewise, Merkle Trees
avoid the need to blindly trust logs: if a log attempts to show different things to
different people, this can be efficiently detected by comparing tree roots and consistency
proofs. Similarly, other misbehaviors of any log (e.g., issuing signed timestamps for
certificates they then don't log) can be efficiently detected and proved to the world at
large."

These logs can also assist with other interesting problems, such as how to assure end users
that software they are running is, indeed, the software they intend to run.

Work items:

- Publish an update to RFC 6962 as a standards-track mechanism to apply verifiable logs to
HTTP over TLS.

- Discuss mechanisms and techniques that allow cryptographically verifiable logs to be
deployed to improve the security of protocols and software distribution. Where such
mechanisms appear sufficiently useful, the WG will re-charter to add relevant new work items.

---

From: Tim Moses <[email-masked]>
Date: Tue, 7 Jan 2014 16:37:59 +0000

Hi Ben.  Is it explained somewhere how it would be discovered that a log had issued a time stamp for a certificate that it then did not log?

According to my understanding, the time stamp would only be distributed within a certificate or OCSP response, and (therefore) its existence would not necessarily be apparent to an auditor.

Maybe I missed something.

All the best. Tim.

> On Jan 7, 2014, at 11:14 AM, "Ben Laurie" <[email-masked]> wrote:
> 
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Jan 2014 16:51:41 +0000

> mechanisms appear sufficiently useful, the WG will re-charter to add relevant new work items.

OK with me.

Thanks.

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Jan 2014 17:07:48 +0000

> Hi Ben.  Is it explained somewhere how it would be discovered that a log had issued a time stamp for a certificate that it then did not log?

RFC 6962, Section 5.4 "Auditor".

> According to my understanding, the time stamp would only be distributed within a certificate or OCSP response, and (therefore) its existence would not necessarily be apparent to an auditor.

If no-one ever sees the certificate, then whether an SCT was issued or
not is unimportant. This is why recipients of certificates need to at
least audit the certificates they see.

In the RFC "auditor" is a role that may be incorporated in other
things. From the RFC: "An auditor might be an integral component of a
TLS client".

There may be a better way of explaining this.

Possibly something to this effect should've been added to 5.2. I've
added an issue (https://code.google.com/p/certificate-transparency/issues/detail?id=25).

---

From: Tim Moses <[email-masked]>
Date: Tue, 7 Jan 2014 17:26:55 +0000

Ok.  But that's at least one additional round trip, right?

Is it more realistic to say that the protocol fails if ALL of the CA and every timestamp relied upon is untrustworthy?

All the best. Tim.

> On Jan 7, 2014, at 12:07 PM, "Ben Laurie" <[email-masked]> wrote:
>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Jan 2014 17:40:45 +0000

> Ok.  But that's at least one additional round trip, right?

It does not need to be done before accepting the certificate. CT is
designed around responsiveness at the cost of finding out bad things
happened a little late. But this seems like an acceptable trade-off,
since a log still can only misbehave once (or for a short period of
time), which makes the cost of doing so very high.

> Is it more realistic to say that the protocol fails if ALL of the CA and every timestamp relied upon is untrustworthy?

I'm not sure what you mean by this, but perhaps the above makes it irrelevant?

---

From: Tim Moses <[email-masked]>
Date: Tue, 7 Jan 2014 18:04:39 +0000

I see. It seems unfortunate that reliance on one or more time stamps is not sufficient, but that the client also has to consult the log.

All the best. Tim.

> On Jan 7, 2014, at 12:40 PM, "Ben Laurie" <[email-masked]> wrote:
>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 7 Jan 2014 18:08:33 +0000

> I see. It seems unfortunate that reliance on one or more time stamps is not sufficient, but that the client also has to consult the log.

The client audits the log, which is a different thing.

To make a TLS connection, the timestamps are sufficient.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jan 2014 18:02:47 +0000

Thanks Ben, Paul.

I've kicked off the chartering process. [1]

All going smoothly (which it doesn't always;-) this
could be a WG at IETF-89.

I've put in a placeholder BoF request so a slot is
assigned for that when we schedule the meeting.
(That's [2] which you can ignore unless someone
asks why its there.)

Cheers,
S.

[1] https://datatracker.ietf.org/doc/charter-ietf-trans/
[2] https://trac.tools.ietf.org/bof/trac/wiki/WikiStart#Security

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jan 2014 23:12:41 +0000

First and predictable comment: "Transparency WG" is too generic.

Best crappy suggestion I have is "Append-only Transparency Logs"
but to keep the trans abbreviation.

Better suggestions welcome. (Again offlist is fine since its
mostly bikeshedding about which we only care just enough to
irritate ourselves;-)

S.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 21 Jan 2014 00:35:10 +0000

Collected suggestions, in order sent to me:

1. Append-only Transparency Logs (trans)
2. PUblic Notary Transparency (punt)
3. Public Key Transparency (trans)
4. Transparency for public key binding (trans)
5. warnlog
6. canarielog
7. whistle-ledger
8. detection-ledger

My order or preference would be #3, then #2, then #1 and
otherwise don't care.

If nobody objects (Do you really want to object? Is it
important really? :-) I'll let the IESG pick one of those
with that suggested ordering.

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 20 Jan 2014 20:19:45 -0500

Why limit it to public keys? Security Policy statements can be notarized in
the same manner and this has real benefits.

Trust Infrastructure Transparency  or Transparent Infrastructure for Trust

TIT either way.

On Mon, Jan 20, 2014 at 7:35 PM, Stephen Farrell
<[email-masked]>wrote:

> >>> I support the formation of this WG with basically this charter.
> However, having footnote in a charter make it harder to read. Having URLs
> that are not somewhat guaranteed to be available forever (such as those run
> by the IETF) make the charter unstable. A proposed editorial-only cleanup:
> >>>
> >>> Problem statement:
> >>>
> satisfactory. Ad-hoc mappings are
> that any particular
> how to assure end users

-- 
Website: http://hallambaker.com/