Subject: Re: [therightkey] Paris too soon for a meeting...

From: =JeffH <[email-masked]>
Date: Tue, 07 Feb 2012 08:01:22 -0800

Excellent summary Steve, thanks.

I'm up for a bar-BoF/side-meeting in Paris.

 > There are specific (if not that well documented)
 > proposals out there and I'd love to see their proponents
 > arguing their relative merits in detail so's we
 > could see if there are things that the IETF could/should
 > be doing.

Agreed. I think that those folks having not spoken up or dived into this 
discussion is telling wrt how early all this is. AFAIK there will be some 
in-the-wild experiments run by various folk and that should further inform 
discussions such as this.

=JeffH

---

From: Eric Burger <[email-masked]>
Date: Sat, 11 Feb 2012 09:50:48 -0500

I would offer that I agree with Stephen that it is too soon for a work group forming BOF.  However, I would also offer that given the list traffic, we have more than enough for a high-bandwidth discussion.  I would be up for a bar BOF or, if it makes more sense, a workshop outside the constraints of the more-than-packed IETF week.

On Feb 7, 2012, at 11:01 AM, =JeffH wrote:

> Agreed. I think that those folks having not spoken up or dived into this discussion is telling wrt how early all this is. AFAIK there will be some in-the-wild experiments run by various folk and that should further inform discussions such as this.
> 
> =JeffH
> 
> _______________________________________________
> therightkey mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/therightkey

---

From: Kai Engert <[email-masked]>
Date: Sat, 11 Feb 2012 16:53:02 +0100

If you decided to meet outside of the main IETF event, then I'd be able 
to join you.

If the bar-BOF would either take place from 6 pm on March 29, or anytime 
on March 30/31, then I'd be able to join you.

Best Regards
Kai

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 12 Feb 2012 00:57:22 +0000

If folks wanna meet during IETF week then I'd suggest a doodle
poll to pick a time slot. The someone can find a bar.

If you get really boring and want a meeting room I can probably
arrange that, but offer no guarantees about any particular time
slot. (In any case a smallish group in a bar is better than 50
in a room ppt-gazing, really:-)

S

---

From: Kai Engert <[email-masked]>
Date: Sun, 12 Feb 2012 21:19:03 +0100

On 12.02.2012 01:57, Stephen Farrell wrote:
> poll to pick a time slot.

How about this?
http://www.doodle.com/8c5s43ayqbrft5rm

Kai

---

From: Yoav Nir <[email-masked]>
Date: Sun, 12 Feb 2012 22:40:54 +0200

> http://www.doodle.com/8c5s43ayqbrft5rm

That's about it, but usually we do this after the preliminary agenda has been posted. Also, Friday after 18:00 is a non-starter.

---

From: Kai Engert <[email-masked]>
Date: Sun, 12 Feb 2012 23:30:48 +0100

On 12.02.2012 21:40, Yoav Nir wrote:
> That's about it, but usually we do this after the preliminary agenda has been posted.

I have no eperience with IETF BoF meetings, so I apologize if my 
proposals don't match the expectations for agenda items.
However, in order to get started, here are some questions that we could 
discuss.

(a)
Can we incrementally improve today's PKI trust model, or is a complete 
replacement necessary?

(b)
We heard proposals that require that all trust assertions (certificates) 
are made public, thereby creating public records of all certified entities.
Is such a requirement acceptable?
If not, is parallel deployment of public and private trust logs possible?

(c)
We heard proposals that domain owners shall be required to protect 
themselves from hijacking by permanently watching public logs for 
fraudulent actions.
Is this requirement realistic and acceptable?

(d)
Consider the scenario "attacker controls all routes from hijacked 
server" and can thereby manipulate validation of domain ownership.
Is this a problem a new/improved trust model should/can solve, or should 
this rather be solved at an organizational level, using out-of-band 
communication between assurer, registry and domain owner?

(e)
Make assessments for each of the proposed solutions, how close is each 
of them to a complete protocol specification?

(f)
Can we create a trust system that makes it completely impossible to 
create false trust assertions, or is quick detection of false trust 
assertions the best we can get?

(g)
Should better and quicker revocation of trust assertions be a mandatory, 
integral part of any new trust solutions, or are trust and revocation 
separate problems?

> Also, Friday after 18:00 is a non-starter.

I've removed the Friday-after-18 choice.

Kai