Subject: [therightkey] Draft charter for a Transparency Working Group

From: Ben Laurie <[email-masked]>
Date: Wed, 11 Dec 2013 16:55:07 +0000

Who's in?

"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.

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."

---

From: Rob Stradling <[email-masked]>
Date: Wed, 11 Dec 2013 17:01:10 +0000

> Who's in?

Me.  :-)

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 11 Dec 2013 17:23:43 +0000

Thanks Ben,

So folks know what we're thinking and in case all the
process gibberish isn't clear to you all...

Sean and I like the idea of doing this, and the more that
it seems to get broader support, the more we'll like it.

Since there was already a BoF on this back at IETF-85 [1]
that concluded this was work that's relevant to do in
the IETF, we're thinking that if a crisp enough charter
can be crafted on this list then this wouldn't need another
BoF but would be ok to just be pushed into the IESG/IETF
approval process.

What that means is that when Sean and I think we have a
good enough charter draft, then we'll put that into the
datatracker and the IESG will do an IESG-internal review
to decide if its ready to be sent out for IETF review.
If/when the IESG are ok with that going for IETF-wide
review then a mail will go to the IETF discuss list so's
anyone can comment on the proposed new WG. Then the IESG
get to look at it again, and any comments we've gotten,
and approve the new WG or not. Charter text tweaks can
be expected at each stage.

All going well, that could result in a new WG for this
being formed early in the new year, before IETF-89
with the WG having a first f2f meeting there presumably.

So please comment on Ben's text and the above with that
in mind. I assume Ben will hold the pen on draft charter
text and update that as comments are received.

And please use this list for now, since this is the
one we used for RFC 6962 so probably has the right
people. When/if we form a WG we can make a new list
or use this one if folks prefer that.

Thanks,
S.

[1] http://www.ietf.org/proceedings/85/certrans.html

On 12/11/2013 04:55 PM, Ben Laurie wrote:
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey
> 
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Dec 2013 12:25:21 -0500

IRTF or IETF?

Do we build on existing legacy proposals or write new stuff?

I think there are two separate or at least separable pieces of
infrastructure needed. One is a transparent timestamp notary infrastructure
and the other is transparency mechanisms that make use of said notary
infrastructure.

The need to revisit the first comes from the expiry of the Harber &
Stornetta patents. I think we should have such a facility as a general Web
facility. We can build an infrastructure that prevents defection without
collusion by every notary and archive using existing technology.

Applying the mechanisms to TLS might be done at different levels with
different deployment impacts. Deploying in EE certs is much harder than
deploying in cert signing certs. But the latter would provide most of the
benefit by blocking MITM certs.

I am looking at SMTP and the approach is very obviously research at this
point.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 11 Dec 2013 12:35:01 -0500

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

I'm interested.  I think this has strong potential for improved
authenticity on the 'net (and improved confidentiality follows from that).

However, I'm also concerned that cryptographically-verifiable global
logs create an enumeration concern for the space that they log.  This is
similar in some ways to the issues raised around DNSSEC's NSEC (and not
particularly effectively addressed by NSEC3).  Enumerability like this
is potentially a major table of metadata that could potentially be abused.

I'd appreciate it if any Transparency Working Group explicitly tries to
address concerns around enumerability.

Thanks for taking point on this, Ben.

Regards,

	--dkg

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 11 Dec 2013 17:44:26 +0000

I totally understand the problem statement. But what concrete things can
you enumerate as goals/output of the WG?

Jason

---

From: Paul Wouters <[email-masked]>
Date: Wed, 11 Dec 2013 12:52:19 -0500 (EST)

> Who's in?

Yes, but...

> SMTPS, IPSec, DNSSEC and OpenPGP.

This is protocol agnostic (good!)

> logs to HTTP/TLS (i.e. RFC 6962-bis).

This is not. I'd prefer to work towards a more generic
method or infrastructure, but I assume the work item is
just an example and not a limitation of the charter.

Paul

---

From: Ben Laurie <[email-masked]>
Date: Wed, 11 Dec 2013 18:23:34 +0000

> I am looking at SMTP and the approach is very obviously research at this

I think this is well covered by "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: Ben Laurie <[email-masked]>
Date: Wed, 11 Dec 2013 18:27:52 +0000

> is potentially a major table of metadata that could potentially be abused.

Agreed, at least for some protocols. I think this area has already
been well thrashed out for HTTPS certificates, the initial target,
which are _mostly_ public. It seems we have good mechanisms in place
for those who want public CAs to issue private certificates, too (that
is, name-constrained intermediates).

> address concerns around enumerability.

This is a _hard problem_, and verifiable logs suffer from the same
limitations that NSEC3 does, at least as currently envisaged.
Mechanisms akin to name constraints can perhaps go some way towards
addressing this issue in general, but the general problem I have no
idea how to solve. But it would seem to be on-topic for the general
case.

Possibly we have to admit we have no such mechanism for namespaces we
want to be non-enumerable.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 11 Dec 2013 18:29:09 +0000

> you enumerate as goals/output of the WG?

I already did enumerate the one current output: RFC 6962-bis.

Other interesting targets include DNSSEC transparency, email-to-key
mappings and binary transparency. All implicitly already in the
charter.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 11 Dec 2013 18:30:18 +0000

> just an example and not a limitation of the charter.

As the charter suggests, we will re-charter to include such things, as
they appear to become viable.

I am _very_ keen to come up with more generic mechanisms.

But I also have an urgent problem to solve.

They are not mutually exclusive.

---

From: Leif Johansson <[email-masked]>
Date: Wed, 11 Dec 2013 21:39:31 +0100

> Who's in?
yep

---

From: Leif Johansson <[email-masked]>
Date: Wed, 11 Dec 2013 21:59:32 +0100

> They are not mutually exclusive.
So there are various other "public ledger" projects out there, all based
on organic, locally sourced Merkle trees. We should probably make some
effort to reach out to these communities.

        Cheers Leif

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 11 Dec 2013 16:43:34 -0500

> mappings and binary transparency. All implicitly already in the

I am currently working on an email scheme that is intended to consume such
a service.

The big difference as I see it is that with TLS we only have the
transparency issue to work on. In email we have a big functionality gap in
S/MIME which is the lack of a viable key discovery infrastructure. We have
plenty of proposals but nothing got done.

If we are going to do transparency in that sphere we should look at the two
problems together since any transparency infrastructure is potentially a
solution to the discovery problem.

If I can ask the transparency infrastructure if someone else has registered
a key for [email-masked] to see if someone is impersonating me, then
someone who is trying to send me an email can ask the same infrastructure
what keys are registered for me.

The other big difference is in latency. Email is store and forward. The
issues that motivate putting transparency statements inside the certs in
SSL do not apply.

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

---

From: Warren Kumari <[email-masked]>
Date: Wed, 11 Dec 2013 17:09:51 -0500

> mappings and binary transparency. All implicitly already in the

I’m in — I think that there is still much work / firming up the “charter” needed, but the effort seems useful and needed.
W

-- 
Do not meddle in the affairs of wizards, for they are subtle and quick to anger.  
    -- J.R.R. Tolkien

---

From: Lucy Lynch <[email-masked]>
Date: Wed, 11 Dec 2013 14:18:22 -0800 (PST)

> I’m in — I think that there is still much work / firming up the “charter” needed, but the effort seems useful and needed.

Count me in as well -

Lucy

---

From: Lucy Lynch <[email-masked]>
Date: Wed, 11 Dec 2013 14:27:42 -0800 (PST)

On Wed, 11 Dec 2013, Warren Kumari wrote:

> I’m in — I think that there is still much work / firming up the 
> “charter” needed, but the effort seems useful and needed.

count me in as well

- Lucy

---

From: Paul Lambert <[email-masked]>
Date: Wed, 11 Dec 2013 17:32:18 -0800

>Who's in?
Very cool concept Š very broad possible applications.
Less interested in HTTPS/TLS, but many applications.

Paul

---

From: Ben Laurie <[email-masked]>
Date: Thu, 12 Dec 2013 11:09:19 +0000

> effort to reach out to these communities.

Sure. Do you have a list?

---

From: Ben Laurie <[email-masked]>
Date: Thu, 12 Dec 2013 11:10:29 +0000

> Less interested in HTTPS/TLS, but many applications.

Great - can you be more specific what interests you?

---

From: Leif Johansson <[email-masked]>
Date: Thu, 12 Dec 2013 13:11:23 +0100

> Sure. Do you have a list?
I'll dig

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Dec 2013 12:26:44 +0000

Hi Ben,

I've a question.

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

I'd like to get a feel for how these work items
might be sequenced.

For the 2nd one, I assume the modus-operandi would
be for folks interested in transparency-for-X to
write up a personal draft, have that discussed on
the WG list and for stuff for which the WG achieve
consensus to re-charter to add new work items to
tackle transparency-for-X to the charter. That
seems fine to me. (And people can starting writing
those today - the more that exists before the WG
would be chartered, the easier it'll all be.)

For the first one, I'm not clear as to whether
you intend to 1) first consider a set of
transparency-for-X proposals, re-charter and
to only then figure out how to re-factor 6962
into a set of standards-track RFCs, or

2) if you want to do the work of generating a
standards-track set of RFCs based on 6962 for
HTTP/TLS before the WG have considered a set
of transparency-for-X proposals.

Or maybe 3) you wanted that to emerge from
this chartering discussion.

Can you clarify? If (1) or (2) apply then it'd
probably be useful to include that explicitly
in the charter text. If (3) applies then I guess
you'd want to actively lead the discussion down
that path, which sort of seems to be happening
already.

And note I'm not asking here about the specific
set of RFCs as deliverables nor the timing of
those deliverables, just how the ordering of
HTTP/TLS vs. other stuff would happen at a
coarse-grained level. (Separately, it'd be good
to chat about what RFC deliverables are likely
to be wanted, but probably only after the
above is clear.)

Thanks,
S.

---

From: Paul Lambert <[email-masked]>
Date: Thu, 12 Dec 2013 06:39:06 -0800

>Great - can you be more specific what interests you?

1) Basic logs and the ability to have assurance on time and order
2) Distributed authorization systems with an ability to demonstrate the
existence
   and ordering of authorization statements
3) Time stamps and time synchronization
4) Group membership / enrollment
5) 'key centric' identity (mappings using hashes of keys as identity)
6) Service description and discovery without central registration

Paul

---

From: Ben Laurie <[email-masked]>
Date: Thu, 12 Dec 2013 15:23:10 +0000

> that path, which sort of seems to be happening

None of the above?

I want to generate standards-track RFC(s) for 6962-bis, but other
stuff could proceed in parallel. I don't want to hold up 6962-bis for
that other stuff, though.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 12 Dec 2013 10:24:02 -0500

> 6) Service description and discovery without central registration

I am very interested in 5, in fact my strong email addresses are really
just a convenient notation for key centric identity.

But there are two questions here:

1) What should we do?
2) What should we do in the transparency WG?

A draft of the paper I wrote for the IAB/W3C workshop is attached. It
describes the scheme I am currently writing code to support.

The part of the scheme described in the paper is what I consider
'plumbing'. I don't think that I have foreclosed any options by taking the
decisions I did. Most of the design is constrained by previous
specifications and by legacy infrastructure. The decision to use JSON to
encode the 'Prism Hardening Bit' is driven by fashion but I think that is a
good one in this case and I can support it with a use case that JSON meets
but not ASN.1.

But what I don't describe in the paper is the much bigger part of the
scheme that has to do with a next generation PKI model for individual users
built on a synthesis of the PKIX, PGP and CT models.

I could propose that as a WG item but I get the feeling that Stephen is
going to respond that it is research or it should be an experimental or
whatever.

I really want to fix end-to-end email security. But right now the problem
with end-to-end security is not a lack of trust in the key distribution
model. The problem that is killing deployment is that the products are too
difficult to use.

So even though I am building my alternative key distribution infrastructure
on the assumption that there is a CT like infrastructure in place, the
motivation for building that infrastructure is to solve a different problem.

Another area that I have considered and written code for but not yet
described is how to use key centric crypto to secure a Web service.

For example, let us say that we have some infrastructure that lets us
resolve either a hash alone or a hash plus a domain name to a blob of data
that is a policy signed under the corresponding key (a PHingerprint Blob,
fb was already taken).

I am currently using this mechanism to resolve strong email addresses:

<fingerprint>?[email-masked]

We can use just a Web server and the .well-known convention to resolve
(<fingerprint>, example.com) to a policy file.

But while I was writing the proxy I suddenly realized that even though my
email client lets me check the box that says 'use SSL', the client does not
actually check the certificate chain, nor does it let me install my own
root of trust to check the chain against. Which is a pretty big hole. So
what I would like to be able to do to configure my email client is to
specify the mail service connection in a form such as:

phb://example.com/_submit._tcp/<fingerprint>

The corresponding policy would then contain the port and service DNS name
data for connecting to the submit service at example.com.

We can further use this as a discovery mechanism for the phingerprint as
follows:

Let us assume that all the user tells the client is their email address (
[email-masked]) and the client is to work out everything else for
themselves. So the client knows that it wants to talk the SUBMIT protocol
(_submit._tcp) and it knows the domain (example.com). It can now form a
.well-known query for the phingerprint of the corresponding domain:

https://example.com/.well-known/phb/
http://example.com/.well-known/phb/

As a short term measure the user would have to enter a one-time passphrase
to provide initial authentication. But in the longer term this should be
replaced by an out of band confirmation service. When I buy a new device I
want to be able to configure it for use with all my applications through a
one time process in which I tell the device which account(s) to use and
then I get an out of band request for confirmation that this is what I want
to do on an already configured and trusted device.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 12 Dec 2013 15:24:49 +0000

> 1) Basic logs and the ability to have assurance on time and order

Not sure how you do time without some notion of trust. But order is a
basic property of the log, yes.

> 6) Service description and discovery without central registration

These all sound interesting, indeed.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 12 Dec 2013 15:33:38 +0000

> that other stuff, though.

What requirements are there to be able to also
use a 6962bis log instance or piece of s/w for
another transparency-for-X thing?

If there are none or its ok as a best-effort
thing then working in parallel seems ok, but if
there's a strong desire to be able to use the
same log instance or s/w for more than one
thing, aren't there dangers there?

I've no particular opinion as to what's right
here btw, but its a fairly typical way in which
a WG might trip up and can lead to the WG
convincing themselves to step back to start
from use-cases, blah, requirements, blah,
architecture, blah etc. after a big and non-fun
argument.

Better to figure it out and have some sort of
consensus on that kind of thing up front if
possible.

S.

---

From: Ben Laurie <[email-masked]>
Date: Thu, 12 Dec 2013 15:46:54 +0000

> thing, aren't there dangers there?

CT is tightly linked to CAs as an anti-spam measure, and so I don't
think it can be used for other things.

I think it is possible to define a more generic mechanism, with some
parameter choices (e.g. do you have the logs issue signatures on
timestamps and later order the log, as in CT, or do you order before
issuing a signature on a Merkle proof?), for other things, but that's
a distraction from progress on CT, which is urgent.

Spam is a particularly thorny issue, and I suspect anti-spam measures
are tightly linked to the log's purpose. I have ideas for DNSSEC and
binaries, but they are not completely generic. A log with no mechanism
to control ingress of loggable things is trivial to DoS into
uselessness.

---

From: Warren Kumari <[email-masked]>
Date: Fri, 13 Dec 2013 16:50:28 -0500

> to control ingress of loggable things is trivial to DoS into

Yup, but I think you should be able to mitigate some of the spam issues by forcing the inserter to do some work — for example, when I input a DNSSEC record I have to solve a CAPTCHA….
Yes, there are many weaknesses with captchas (automated solvers, mules, etc), but (AFAICT) all you need to do is raise the cost enough that this is not an attractive attack. DoSing the log doesn’t *provide access*, it simply denies service to those wanting to insert information, so, unless I’m very mistaken, the main incentive to DoS is giggles / being an ass…

Or am I completely missing something?

W

--
For every complex problem, there is a solution that is simple, neat, and wrong.
                -- H. L. Mencken

---

From: Ralph Holz <[email-masked]>
Date: Sat, 14 Dec 2013 12:08:41 +0100

> Who's in?

I'd like to be part of it.

> by making it possible to discover and rectify errors before they can

Correct me if I am wrong, but the following comes to mind. I'd probably
say "too much harm" or "significant harm": the public log concept allows
for a short time window for successful attack. Much depends on the
number of logs a CA pushes their certs to, and how many monitors watch
these logs for suspicious changes. I am less concerned about the
consistency proofs and audit paths here, and more about what monitors
actually do. I.e., deployment issues.

> logs to HTTP/TLS (i.e. RFC 6962-bis).

One thing that I was wondering about is whether the work can be taken
further at some point to include that mechanism from Sovereign Keys that
allows to give, say, an alternate Tor routing (or hidden service), for a
given domain, in order to avoid censorship. I'd agree that's not a
primary topic for CT, but a worthwhile goal to keep in mind for later.

Ralph

-- 
Ralph Holz
I8 - Network Architectures and Services
Technische Universität München
http://www.net.in.tum.de/de/mitarbeiter/holz/
Phone +49.89.289.18043
PGP: A805 D19C E23E 6BBB E0C4  86DC 520E 0C83 69B0 03EF

---

From: Ben Laurie <[email-masked]>
Date: Sat, 14 Dec 2013 12:39:54 +0000

On 14 December 2013 11:08, Ralph Holz <[email-masked]> wrote:
> for a short time window for successful attack.

That's not actually generally true. There's really a spectrum where
"responsive log/immediate availability of certs (or whatever)" as at
one end and "slow log/certs delayed until everyone's happy" is at the
other.

The original CT proposal delayed cert issuance to reduce the window.
CAs didn't like it. So, we exchanged more attack window for happier
CAs. That's a needle we might want to move over time.

> Much depends on the

In the Revocation Transparency paper, we describe two mechanisms that
could be sued to remove the trusted components from Sovereign Keys. So
... yes.

---

From: Tom Fitzhenry <[email-masked]>
Date: Sun, 15 Dec 2013 20:36:40 +0000

> Who's in?

I'd like to be involved.

I'm interested in:
    * applications
        * trusted timestamping
        * E2E email encryption
        * binary transparency
    * infrastructure/generalisations to make applications more coherent or easier to
deploy

As evidence there is wider interest in Transparency solutions, Mark Ryan wrote
"Enhanced certificate transparency (how Johnny could encrypt)"[0], a proposal to use
Revocation Transparency to provide E2E email encryption.

-- 
Tom Fitzhenry
https://tom-fitzhenry.me.uk/

0. http://eprint.iacr.org/2013/595.pdf