Subject: [Trans] Future work

From: Melinda Shore <[email-masked]>
Date: Wed, 16 Aug 2017 11:25:20 -0800

Hi, all:

With our major deliverable now pushed out towards IETF
last call, it's time to start considering whether or not
there's additional work to do, or if we're done.  As
we've talked about before, we know that there's at least
some interest in:

. a client behavior document
. logging DNSSEC records
. logging binaries

Plus, I'm somewhat concerned about lack of gossip implementation
and deployment, and it's worth considering whether that's because
of lack of interest or because people running logs don't think
that what's in the gossip spec is suitable for their needs.

So, we're looking for feedback on future work, and particularly
on whether or not there are people working on drafts relevant to
this working group, or people with plans to work on drafts.

Melinda

---

From: Andrew Ayer <[email-masked]>
Date: Wed, 16 Aug 2017 13:09:21 -0700

On Wed, 16 Aug 2017 11:25:20 -0800

> . a client behavior document

I've also seen interest expressed on the mailing list for:

* A monitor API
* A strict version of CT

> that what's in the gossip spec is suitable for their needs.

Note that logs don't participate in gossip, so your question is one
for TLS clients and monitors/auditors.

The biggest problem is that the gossip spec only works with CTv2,
and there are no CTv2 logs in existence, let alone implementations.

Nevertheless, there's a fairly obvious and minor modification to make
STH pollination work with CTv1, and I know of 7 different
monitor/auditor implementations which are using this variation of the
spec to exchange STHs from publicly-trusted CTv1 logs.

That said, I know of no implementations of SCT feedback, nor of any plans
by TLS clients to implement any part of gossip.

Regards,
Andrew

---

From: Tom Ritter <[email-masked]>
Date: Wed, 16 Aug 2017 16:25:21 -0500

> by TLS clients to implement any part of gossip.

Well, there's Google's thing, which I talked about here:
https://www.ietf.org/mail-archive/web/trans/current/msg02626.html

There was Richard Barnes interest in changing the ways logs operate
(maybe that's what Andrew means by Strict CT?).

I am interested in several of these things, but I do not think I am a
good candidate to be an author.

-tom

---

From: Ben Laurie <[email-masked]>
Date: Thu, 17 Aug 2017 10:32:56 +0100

> I've also seen interest expressed on the mailing list for:

Since we now know how to build verifiable monitors, perhaps that is part of
an API?

> * A strict version of CT

What do you mean by this?

> by TLS clients to implement any part of gossip.

IMO "gossipless gossip", i.e. cross-logging of STHs is the way to go.

>
> Regards,
> Andrew
>
> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Al Cutter <[email-masked]>
Date: Thu, 17 Aug 2017 11:35:26 +0100

On Thu, Aug 17, 2017 at 10:32 AM, Ben Laurie <[email-masked]> wrote:

> Since we now know how to build verifiable monitors, perhaps that is part
> of an API?
>

> IMO "gossipless gossip", i.e. cross-logging of STHs is the way to go.

I agree, but you knew that already :)

To the broader, original, question - I do think there's plenty more work to
do, but I'd prefer to see any document work happening in parallel with
experimentation and implementations (and again I admit I'm not familiar
with IETF process, so feel free to tell me that's now how it's supposed to
work).
With that in mind, my team intends to start some experimental work on the
verifiable monitor and gossip topics soon (probably Q4 time-frame), once
we've dealt with getting Trillian based CT Logs into service, and related
existing-ecosystem work; and if there's interest we'd welcome discussion
and collaboration either here or over on the CT list.

Cheers,
Al.

---

From: Rob Stradling <[email-masked]>
Date: Thu, 17 Aug 2017 11:45:11 +0100

On 16/08/17 20:25, Melinda Shore wrote:
<snip>
> this working group, or people with plans to work on drafts.

Hi Melinda.

I've started work on a draft entitled Private Key Compromise 
Transparency (PKCT).  The idea is to enable anyone who finds a 
compromised private key to submit a "proof of compromise" to one or more 
public log(s).  It'll build on top of 6962-bis, defining a new 
VersionedTransType value, etc.

Providers of certificate revocation services (CAs and browser vendors) 
will be able to monitor these PKCT logs and take appropriate action. 
Since the "proofs of compromise" will be programmatically verifiable, it 
will become possible to automate existing, error-prone, manual processes 
(e.g., see [1]).

[1] 
https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html

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

---

From: Ben Laurie <[email-masked]>
Date: Thu, 17 Aug 2017 12:21:35 +0100

On 17 August 2017 at 11:45, Rob Stradling <[email-masked]> wrote:

> I've started work on a draft entitled Private Key Compromise Transparency
> (PKCT).  The idea is to enable anyone who finds a compromised private key
> to submit a "proof of compromise" to one or more public log(s).  It'll
> build on top of 6962-bis, defining a new VersionedTransType value, etc.
>
> will be able to monitor these PKCT logs and take appropriate action. Since
> the "proofs of compromise" will be programmatically verifiable, it will
> become possible to automate existing, error-prone, manual processes (e.g.,
> see [1]).
>

Nice idea.

>
>
> [1] https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-
> with-a-Fake-Private-Key.html
>
> --
> Rob Stradling

---

From: Melinda Shore <[email-masked]>
Date: Thu, 17 Aug 2017 11:44:33 -0800

Hi, all:

It sounds as if there's some interesting work going on, and work
that's relevant to this working group.  Work in the IETF proceeds
through the draft editing/revision process, so it would be excellent
to see some drafts starting to be posted on these topics.  Definitely
feel free to put out requests for collaboration and review!

Thanks,

Melinda