Subject: [therightkey] Transparency BoF - there's a deadline...

From: Stephen Farrell <[email-masked]>
Date: Mon, 10 Sep 2012 23:21:38 +0100

Hiya,

If you want a BoF, then you need to do the required dance;-)

"2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area
Directors at UTC 24:00. To request a BOF, please see instructions on
Requesting a BOF." [1]

Sean and I remain interested in folks' opinions about having this
BoF. So far I've seen about a dozen-ish "I'm interested in
something here" responses, a good chunk from folks who do good
work around the IETF; one negative comment off-list (saying its
not baked), and have seen a just a couple of folks say they'd
do work.

That's not bad, but nowhere near overwhelming either, so more
input would be appreciated, preferably on the list.

S.

[1] https://www.ietf.org/iesg/bof-procedures.html

---

From: Yoav Nir <[email-masked]>
Date: Tue, 11 Sep 2012 07:22:30 +0300

In case I wasn't clear last week, yes, I'm interested, and yes, I'm willing to review/contribute/edit.

I don't think an opinion that the idea is not yet baked should be a bar to meeting. Meetings are a good forum for baking ideas.

Yoav

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: Tuesday, September 11, 2012 1:22 AM
To: Ben Laurie
Cc: [email-masked]
Subject: [therightkey] Transparency BoF - there's a deadline...

Hiya,

"2012-09-24 (Monday): Cutoff date for BOF proposal requests to Area Directors at UTC 24:00. To request a BOF, please see instructions on Requesting a BOF." [1]

Sean and I remain interested in folks' opinions about having this BoF. So far I've seen about a dozen-ish "I'm interested in something here" responses, a good chunk from folks who do good work around the IETF; one negative comment off-list (saying its not baked), and have seen a just a couple of folks say they'd do work.

That's not bad, but nowhere near overwhelming either, so more input would be appreciated, preferably on the list.

S.

[1] https://www.ietf.org/iesg/bof-procedures.html
_______________________________________________
therightkey mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/therightkey

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 11 Sep 2012 08:02:49 -0400

I am willing to work on a transparency scheme, edit and review documents.

I do have a different approach to the question to the Google scheme, but I
think they are both worth doing.

On Tue, Sep 11, 2012 at 12:22 AM, Yoav Nir <[email-masked]> wrote:

> I don't think an opinion that the idea is not yet baked should be a bar to
> meeting. Meetings are a good forum for baking ideas.
>
> Yoav
>
> Sean and I remain interested in folks' opinions about having this BoF. So
> far I've seen about a dozen-ish "I'm interested in something here"
> responses, a good chunk from folks who do good work around the IETF; one
> negative comment off-list (saying its not baked), and have seen a just a
> couple of folks say they'd do work.
>

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

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 11 Sep 2012 17:11:30 +0100

And the deadline's been met early:-) Thanks Ben.

I've put up some info on the BoF wiki. [1]

Note: this means that this BoF will be considered
for scheduling. It does not yet mean that it is
approved. That decision happens on Sep 24th.

If folks can post Internet-Drafts describing their
scheme(s) before the 24th then that's all to the
good - it shows people are willing to make the
effort and buy into the IETF's processes which can
help a lot.

If there are other non security area WGs that this
ought not collide with, please let me know. (It
won't collide with any other BoF or area meeting
unless we slip up in scheduling so no need to
tell me about those.)

We can sort out other details (e.g. remote access)
after the BoF approval call on the 24th.

We have a BoF chair volunteer who'll be able to
help start organising agenda slots etc after the
BoF approval call. More on that after the 24th.

Thanks,
S.

[1] http://trac.tools.ietf.org/bof/trac/wiki/WikiStart

---

From: Jon Callas <[email-masked]>
Date: Tue, 11 Sep 2012 17:14:46 -0700

> input would be appreciated, preferably on the list.

Stephen,

I am very supportive of the BoF.

Certificate Transparency addresses a real problem that no other public key infrastructure tweaks do. It permits any party to survey the landscape of public certificates and do meaningful security analysis. It is also a modest protocol that doesn't interfere with existing operations.

Many of us doubt the public web certificate infrastructure runs without someone cheating. We take as an article of faith that someone somewhere is issuing bogus certificates for whatever nefarious purpose. Usually that is some vague surveillance, if not outright espionage. (For what it's worth, I subscribe to that faith.)

CT has the value that CAs, relying parties, end users, and interested third parties can look at the landscape of certificates and catch inconsistencies. It allows us put some actual faith into trust. It allows us to see what is going on in a system that we all use. We need CT. It would be good to have it develop under the aegis of the IETF.

	Jon

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 11 Sep 2012 21:37:40 -0400

Thinking through some baby steps here. Perhaps one of the first steps might
be to apply transparency to intermediate certs since those are the ones
that have the highest risk associated?

In particular I really hope that there is nobody out there issuing
intercept certs on public roots.

On Tue, Sep 11, 2012 at 8:14 PM, Jon Callas <[email-masked]> wrote:

> Certificate Transparency addresses a real problem that no other public key
> infrastructure tweaks do. It permits any party to survey the landscape of
> public certificates and do meaningful security analysis. It is also a
> modest protocol that doesn't interfere with existing operations.
>
> Many of us doubt the public web certificate infrastructure runs without
> someone cheating. We take as an article of faith that someone somewhere is
> issuing bogus certificates for whatever nefarious purpose. Usually that is
> some vague surveillance, if not outright espionage. (For what it's worth, I
> subscribe to that faith.)
>
> CT has the value that CAs, relying parties, end users, and interested
> third parties can look at the landscape of certificates and catch
> inconsistencies. It allows us put some actual faith into trust. It allows
> us to see what is going on in a system that we all use. We need CT. It
> would be good to have it develop under the aegis of the IETF.
>
>         Jon
>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 12 Sep 2012 15:22:24 +0100

On 12 September 2012 02:37, Phillip Hallam-Baker <[email-masked]> wrote:
> be to apply transparency to intermediate certs since those are the ones that
> have the highest risk associated?

You'd have to either re-issue them all, or upgrade all the servers
using certs chained from them...

> In particular I really hope that there is nobody out there issuing intercept
> certs on public roots.
>
>
>
>> public certificates and do meaningful security analysis. It is also a modest
>> protocol that doesn't interfere with existing operations.
>>
>> inconsistencies. It allows us put some actual faith into trust. It allows us
>> to see what is going on in a system that we all use. We need CT. It would be
>> good to have it develop under the aegis of the IETF.
>>
>>         Jon
>>

---

From: Ben Laurie <[email-masked]>
Date: Wed, 12 Sep 2012 15:30:13 +0100

> In particular I really hope that there is nobody out there issuing intercept

What do you mean by an "intercept cert"?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Sep 2012 10:33:39 -0400

Issuing a cert on a public root for the purpose of enabling transparent
intercept of SSL on a Bluecoat like device.

Anyone doing so would be in direct contravention of the Mozilla
requirements (and probably everyone else) of course.

On Wed, Sep 12, 2012 at 10:30 AM, Ben Laurie <[email-masked]> wrote:

> modest

---

From: Ben Laurie <[email-masked]>
Date: Wed, 12 Sep 2012 15:34:52 +0100

> intercept of SSL on a Bluecoat like device.

OK. So how would one tell what the purpose was?

For example: http://cdp.disney.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Sep 2012 10:35:04 -0400

I don't see why that would be the case. The requirement could be applied to
new certs going forward. Or the proofs could be embedded in OCSP tokens
rather than the certs themselves.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 12 Sep 2012 15:37:28 +0100

> rather than the certs themselves.

I think I've said before that I would welcome a move to embedding in
OCSP. Presumably they'd have to be stapled...

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Sep 2012 10:37:39 -0400

> For example: http://cdp.disney.com/

I don't think you can and I don't think you need to.

Transparency is pretty robust. If people have a good explanation for the
reason they are doing something then it isn't an intercept cert. If they
don't have an explanation then it is a problem even if the specific problem
isn't intercept.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 12 Sep 2012 15:38:31 +0100

> don't have an explanation then it is a problem even if the specific problem

I'd say name constraints were the right mechanism, not a plausible
explanation :-)

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Sep 2012 10:38:40 -0400

Or we can use something like Omnibroker.

There are lots of ways to boil this bunny.

On Wed, Sep 12, 2012 at 10:37 AM, Ben Laurie <[email-masked]> wrote:

> >> >> Certificate Transparency addresses a real problem that no other
> public
> >> >> key
> >> >> infrastructure tweaks do. It permits any party to survey the
> landscape
> >> >> of
> >> >> someone cheating. We take as an article of faith that someone
> somewhere
> >> >> is
> >> >> issuing bogus certificates for whatever nefarious purpose. Usually
> that
> >> >> is

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Sep 2012 10:39:37 -0400

> I'd say name constraints were the right mechanism, not a plausible

Which is what got me thinking about doing it there first, we want to do NC
there so it makes sense to start there.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 12 Sep 2012 10:40:24 -0400

Perhaps we need both a BOF and a Bar BOF on this.

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Sep 2012 15:53:10 +0100

> Perhaps we need both a BOF and a Bar BOF on this.

Going straight to the bar after a BoF is a fine
plan :-)

S.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 12 Sep 2012 07:55:24 -0700

> BoF approval call. More on that after the 24th.

Delurking: that would be me. I didn't want to say anything until I had caught up on the list, and I still haven't, but then again it's not urgent because we don't know whether we will even get a slot. More later when we do.

FWIW, I'm the one who proposed 90 minutes instead of the typical 60. My view is that there should be no more than 30-45 minutes of presentations followed by lots of mic talk. I will probably enforce a "presentations must be ready the Monday before the meeting" requirement and will encourage people to start reading and commenting on them then.

The value of mic time is not "I like this and don't like that", but rather "that one idea on slide 3 makes me think of this other thing that hasn't been discussed yet". Proclamations of "this is great" and "this will never work" are more appropriate on the list; proposals of "if you add this" or "if you change that" are better uses of mic time.

The fact that we might meet f2f should have little effect on the current discussion.

--Paul Hoffman

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 12 Sep 2012 16:23:12 +0100

On 09/12/2012 03:55 PM, Paul Hoffman wrote:
> Delurking: that would be me. 

And thanks Paul for taking it on.

> I didn't want to say anything until I had caught up on the list, and I
still haven't, but then again it's not urgent because we don't know
whether we will even get a slot. More later when we do.
> The fact that we might meet f2f should have little effect on the current discussion.

Right. A number of people have also said "something like this
might be good, not sure what" so if those folks can write up
Internet-drafts too that'd be great since we could discuss 'em
on the list and make better use of f2f time if we get it.

S.