Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08

Sam Hartman <hartmans-ietfc@mit.edu> Wed, 14 August 2013 19:19 UTC

Return-Path: <hartmans@mit.edu>
X-Original-To: karp@ietfa.amsl.com
Delivered-To: karp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AE911E81F0; Wed, 14 Aug 2013 12:19:21 -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 ZCuz8wprUAt7; Wed, 14 Aug 2013 12:19:15 -0700 (PDT)
Received: from mail.painless-security.com (mail.painless-security.com [23.30.188.241]) by ietfa.amsl.com (Postfix) with ESMTP id D417411E81D3; Wed, 14 Aug 2013 12:19:09 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.painless-security.com (Postfix) with ESMTP id 5681420288; Wed, 14 Aug 2013 15:17:58 -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 Ad05Q-xHOkXP; Wed, 14 Aug 2013 15:17:57 -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; Wed, 14 Aug 2013 15:17:57 -0400 (EDT)
Received: by carter-zimmerman.suchdamage.org (Postfix, from userid 8042) id 0E4688051A; Wed, 14 Aug 2013 15:19:06 -0400 (EDT)
From: Sam Hartman <hartmans-ietfc@mit.edu>
Newsgroups:
To: "Black\, David" <david.black@emc.com>
References: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com>
Date: Wed, 14 Aug 2013 15:19:06 -0400
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com> (David Black's message of "Fri, 9 Aug 2013 10:47:05 -0400")
Message-ID: <tslvc38cc7p.fsf@mit.edu>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailman-Approved-At: Thu, 15 Aug 2013 09:24:45 -0700
Cc: "ietf@ietf.org" <ietf@ietf.org>, "tim.polk@nist.gov" <tim.polk@nist.gov>, "General Area Review Team \(gen-art@ietf.org\)" <gen-art@ietf.org>, "karp@ietf.org" <karp@ietf.org>
Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08
X-BeenThere: karp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Discussion list for key management for routing and transport protocols <karp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/karp>, <mailto:karp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/karp>
List-Post: <mailto:karp@ietf.org>
List-Help: <mailto:karp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/karp>, <mailto:karp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 14 Aug 2013 19:19:21 -0000

David, as we mentioned in the IESG thread, we seem to have dropped the
response to your comments about IANA actions.

WG:
>From the genart review:

[9] I suggest Expert Review for the new IANA registries, not just 
First Come First Served, so that someone with a security "clue" can
check that the proposed registrations are reasonable.


Stephen has filed a related DISCUSS position.  He's confused why we need
a registry for  KDFs or algorithms.
He argues that the protocols should already have such a registry.  He
argues that it would be non-sensical to register a value in this
registry but not the protocol registry.

In a somewhat related discussion, multiple people have asked what the
scope of this document is.  Are we defining something for routing
protocols?  Any security protocol in the world?  Something in-between?


IU'm going to make two responses:

1)
I think FCFS is not harmful for these registries.

David's main concern is that bad security will get registered.

I'll point out that these registries are not about what security you can
use with a routing protocol, but about what security you can configure
from a management standpoint.
Registering rot13 or similarly questionable security here wouldn't mean
I could use it with a routing protocol, only that I could ask a system
to do so.  If ROT13 was not actually in the security-specific registries
for the protocols in question there'd be no way to send a
rot13-transformed message.

I think people wanting to use bad security in routing protocols will
focus on specifying how to use the security for the protocols, and
that's the appropriate place to do any gateway review.
Yeah, I guess with FCFS it's possible someone could register here and
then later realize they cannot get their md4 security approved in the
actual protocol registry document.

That might be confusing but doesn't seem very harmful.

Also, some routing protocols are protected by cleartext passwords sent
over the network.  We want to be able to manage that, so we will be
registering plaintext password in these registries.
I don't think anyone will come up with anything worse than that.

Finally, I think a lot of us have begun to question the value in
security review for codepoint assignment.  Some security WGs care a lot;
some don't seem to care much at all.

2)  Why I prefer FCFS or at least would object strongly to expert
review.

If we're going to say we want expert review I want us to give  expert
instructions at least good enough that I believe I could answer the
question of what registrations to approve if I were appointed the
expert.

I don't think we could come to consensus on those instructions very
easily.
In particular, I think it would be challenging for us to describe what
security protocols the protocol registry applies to and which ones it
does not.

I'm totally fine publishing this document knowing it will be used for
routing protocols but not knowing what beyond routing protocols it will
be used for.
If we do that FCFS makes a lot of sense.

So, my recommendation is that we keep our current registration policy.