Re: [Trust-router] Considering delaying BOF Request

Sam Hartman <hartmans@painless-security.com> Fri, 17 May 2013 04:54 UTC

Return-Path: <hartmans@painless-security.com>
X-Original-To: trust-router@ietfa.amsl.com
Delivered-To: trust-router@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46B5E21F8717 for <trust-router@ietfa.amsl.com>; Thu, 16 May 2013 21:54:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QzKoS8H21qR5 for <trust-router@ietfa.amsl.com>; Thu, 16 May 2013 21:54:04 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id 51D8621F8F2C for <trust-router@ietf.org>; Thu, 16 May 2013 21:54:03 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 6FE1520584; Fri, 17 May 2013 00:51:16 -0400 (EDT)
Received: from mail.painless-security.com ([127.0.0.1]) by localhost (mail.suchdamage.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3mlLzqkMolOu; Fri, 17 May 2013 00:51:16 -0400 (EDT)
Received: from carter-zimmerman.suchdamage.org (c-98-216-0-82.hsd1.ma.comcast.net [98.216.0.82]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) by mail.painless-security.com (Postfix) with ESMTPS; Fri, 17 May 2013 00:51:16 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 477B3440A; Fri, 17 May 2013 00:54:01 -0400 (EDT)
From: Sam Hartman <hartmans@painless-security.com>
To: David Chadwick <d.w.chadwick@kent.ac.uk>
References: <CDBA7A25.23081%josh.howlett@ja.net> <5194F38F.2050906@kent.ac.uk> <tsltxm3c5tl.fsf@mit.edu> <51950119.1080600@kent.ac.uk>
Date: Fri, 17 May 2013 00:54:01 -0400
In-Reply-To: <51950119.1080600@kent.ac.uk> (David Chadwick's message of "Thu, 16 May 2013 16:54:01 +0100")
Message-ID: <tslhai2b40m.fsf@mit.edu>
User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.3 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: Josh Howlett <Josh.Howlett@ja.net>, "trust-router@ietf.org" <trust-router@ietf.org>
Subject: Re: [Trust-router] Considering delaying BOF Request
X-BeenThere: trust-router@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "ABFAB Trust Router discussion list." <trust-router.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trust-router>, <mailto:trust-router-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/trust-router>
List-Post: <mailto:trust-router@ietf.org>
List-Help: <mailto:trust-router-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trust-router>, <mailto:trust-router-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 May 2013 04:54:10 -0000

david, thanks for bringing up these issues.
Some of them have been discussed and I'll try to summarize our
thinking.  Others are new and I'm delighted to get a discussion started
here.

We assume communities will be named by DNS names.

In the Janet pilot, there is going to be software that will make it easy
for anyone to run their own Janet-hosted community even if their local
IT department does not have a good way to make that easy.
I don't know if Janet plans to allow individual sites to advertize their
own COIs or not; that's a matter of how they configure filters and I
believe that the protocol can be made to support either approach.


The question of how the end-site trust routers get access to new COIs
has received some internal disagreement.  I think the current plan is to
flood all COIs everywhere and to make sure that in general only the
admin for a COI can inject routes for that COI.

I think we'll need more and have put forward some proposals for that.  I
think others agree we may some day need more than that but so far it has
not made it onto our implementation or design priority lists.


Why do you think that it's important that Painless's trust router
believe that it's in a COI?  What's wrong with Painless being co-opted
into a COI?  It seems reasonably harmless to me provided that Painless
does not use an attribute release policy  more liberal than what it
would use with an unknown service.

It might be really bad for the COI admin to add Painless without for
example receiving a signed contract from Painless.  However provided
that the COI admin takes on the liability for incorrectly adding
Painless, that seems fine.  (we certainly don't want to write an APC
policy under which Painless would take on responsibility for COI rules
if Painless has never agreed to those rules.)



I do agree with you that we'll need a trust model as part of security
considerations for any protocol.

--Sam