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

Carter Bullard <carter@qosient.com> Fri, 16 August 2013 17:57 UTC

Return-Path: <carter@qosient.com>
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 4242421F9FCA; Fri, 16 Aug 2013 10:57:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1]
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 2PzfUL3FHnV7; Fri, 16 Aug 2013 10:57:23 -0700 (PDT)
Received: from mail1.g1.pair.com (mail1.g1.pair.com [66.39.3.162]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0BD21F9D5F; Fri, 16 Aug 2013 10:57:23 -0700 (PDT)
Received: from thoth.newyork.qosient.com (207-237-36-98.c3-0.avec-ubr1.nyr-avec.ny.static.cable.rcn.com [207.237.36.98]) by mail1.g1.pair.com (Postfix) with ESMTPSA id 242F32BD37; Fri, 16 Aug 2013 13:57:18 -0400 (EDT)
Content-Type: multipart/signed; boundary="Apple-Mail=_69F64EE4-81C0-425F-8C9E-CD3C38D0CCEC"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Carter Bullard <carter@qosient.com>
In-Reply-To: <8D3D17ACE214DC429325B2B98F3AE7129C489288@MX15A.corp.emc.com>
Date: Fri, 16 Aug 2013 13:57:17 -0400
Message-Id: <41E3D887-7FAD-47BA-AEBB-FF65F14F3F88@qosient.com>
References: <8D3D17ACE214DC429325B2B98F3AE7129C2B7440@MX15A.corp.emc.com> <tslvc38cc7p.fsf@mit.edu> <8D3D17ACE214DC429325B2B98F3AE7129C489288@MX15A.corp.emc.com>
To: "Black, David" <david.black@emc.com>
X-Mailer: Apple Mail (2.1508)
Cc: "tim.polk@nist.gov" <tim.polk@nist.gov>, "General Area Review Team \(gen-art@ietf.org\)" <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, Sam Hartman <hartmans-ietfc@mit.edu>, "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: Fri, 16 Aug 2013 17:57:28 -0000

Hey David,
Having been down this path a number of times, I would like to
suggest that one shouldn't attempt to qualify any algorithm,
technique, method or approach that may be submitted to the
registration process.

By suggesting that the registry somehow contains only " good "
strategies, without any consideration regarding a specific
implementation, you're making a claim that is unsupportable.
Bad implementations of " good " strategies can be worst than
plaintext passwords … really.

Let the user decide what mechanisms they want to use, based
on their criteria.

Clear text passwords used over a triple AES encrypted channel
is not "by definition" a bad strategy.  Theoretically, it could
be abstracted as a two-factor system, which has its advantages,
regardless of the perceived " strength ".  Why not ??

Carter

On Aug 16, 2013, at 1:00 PM, "Black, David" <david.black@emc.com> wrote:

> Sam,
> 
> Thanks for picking this up.  Unlike my other two concerns with this draft,
> I think we have a longer discussion ahead of us on this one.
> 
> Your summary of my concern is on the mark:
> 
>> David's main concern is that bad security will get registered.
> 
> I understand the response to be two-fold:
> 
> 1) It doesn't matter; the controlling registry for crypto algorithm usage
> is the protocol-specific registry, not the key table database registry.
> 
> 2) The guidance for the Expert Reviewer will be very difficult to write.
> 
> I'm not convinced by either of these, sorry.
> 
> I'm concerned that the two-registry subtlety in 1) will be lost on
> implementers, especially because (as mentioned in the IESG thread), this
> key table database is likely to see use beyond routing protocols.  Among
> other things, it's being proposed as a general mechanism for keying RSVP,
> not just RSVP-TE (I'm one of the co-chairs of the tsvwg WG that's
> responsible for RSVP).  That key table databases registry is also likely
> to be a place that designers of new protocols look to figure out what to
> use for security.
> 
> As for cleartext passwords:
> 
>> 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.
> 
> I read the first sentence in Section 2 of this draft as excluding
> cleartext passwords:
> 
>   The database is characterized as a table, where each row represents
>   a single long-lived symmetric cryptographic key.
> 
> If someone wants to argue that a cleartext password is a "long-lived
> symmetric cryptographic key", I'll go break out the popcorn and watch
> w/amusement :-).
> 
> Seriously, if the intention is to include cleartext passwords, then I
> think some more rewriting is in order, and I would suggest checking
> directly with the Security ADs before going there.
> 
> As for 2), the fact that it will be difficult (with which I agree)
> doesn't imply that it isn't necessary or shouldn't be done.  IMHO, we
> really should be setting a bar that says that this sort of IETF
> imprimatur of approval of a crypto algorithm actually means something.
> 
> I appreciate that FCFS provides an easier path forward, however I'm
> reminded by analogy of something I learned from my grad school
> software engineering professor:
> 
> 	I can make the code run arbitrarily fast ...
> 	...  if it doesn't have to be correct.
> 
> I'm rather uncomfortable with this use of process expediency as a
> rationale for avoiding a technical concern.
> 
> This may ultimately be an issue that the IESG needs to sort out, as the
> level of security for IETF protocols and concerns about "vanity crypto" 
> extend well beyond the karp WG, but discussion ought to start here.
> 
> Thanks,
> --David
> 
> 
>> -----Original Message-----
>> From: Sam Hartman [mailto:hartmans-ietfc@mit.edu]
>> Sent: Wednesday, August 14, 2013 3:19 PM
>> To: Black, David
>> Cc: housley@vigilsec.com; tim.polk@nist.gov; Dacheng Zhang
>> (zhangdacheng@huawei.com); General Area Review Team (gen-art@ietf.org);
>> karp@ietf.org; ietf@ietf.org
>> Subject: Re: [karp] IANA policy for draft-ietf-karp-crypto-key-table-08
>> 
>> 
>> 
>> 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.
> 
> _______________________________________________
> karp mailing list
> karp@ietf.org
> https://www.ietf.org/mailman/listinfo/karp
>