Re: [cicm] FW: comments on CICM
"Davidson, John A." <JOHN.A.DAVIDSON@saic.com> Wed, 03 August 2011 14:39 UTC
Return-Path: <JOHN.A.DAVIDSON@saic.com>
X-Original-To: cicm@ietfa.amsl.com
Delivered-To: cicm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8D521F86C1 for <cicm@ietfa.amsl.com>; Wed, 3 Aug 2011 07:39:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.474
X-Spam-Level:
X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1iEcv6dGYaG6 for <cicm@ietfa.amsl.com>; Wed, 3 Aug 2011 07:39:55 -0700 (PDT)
Received: from cpmx.mail.saic.com (cpmx.mail.saic.com [139.121.17.160]) by ietfa.amsl.com (Postfix) with ESMTP id C20A721F867F for <cicm@ietf.org>; Wed, 3 Aug 2011 07:39:55 -0700 (PDT)
Received: from 0599-its-sbg02.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx.mail.saic.com with ESMTP id BT-MMP-5675930 for cicm@ietf.org; Wed, 3 Aug 2011 07:40:01 -0700
X-AuditID: 8b7911db-b7bb6ae000000974-5c-4e395dc1264e
Received: from 0599-its-exbh01.us.saic.com (cpe-z7-si-srcnat.sw.saic.com [139.121.20.253]) by 0599-its-sbg02.saic.com (Symantec Brightmail Gateway) with SMTP id 7D.08.02420.1CD593E4; Wed, 3 Aug 2011 07:40:01 -0700 (PDT)
Received: from 0461-its-exmb09.us.saic.com ([10.8.67.20]) by 0599-its-exbh01.us.saic.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Aug 2011 07:40:01 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Wed, 03 Aug 2011 07:40:00 -0700
Message-Id: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085E39@0461-its-exmb09.us.saic.com>
In-Reply-To: <F9AB58FA72BAE7449E7723791F6993ED0630B95AAF@IMCMBX3.MITRE.ORG>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [cicm] FW: comments on CICM
Thread-Index: AcxMjG9q3Na+ogFKR3Slh/gLrxXr8wFWUHrAAADFFnA=
References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com> <F9AB58FA72BAE7449E7723791F6993ED0630B95AAF@IMCMBX3.MITRE.ORG>
From: "Davidson, John A." <JOHN.A.DAVIDSON@saic.com>
To: CICM Discussion List <cicm@ietf.org>
X-OriginalArrivalTime: 03 Aug 2011 14:40:01.0627 (UTC) FILETIME=[39D422B0:01CC51EB]
X-Brightmail-Tracker: AAAAAA==
Subject: Re: [cicm] FW: comments on CICM
X-BeenThere: cicm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: CICM Discussion List <cicm@ietf.org>
List-Id: CICM Discussion List <cicm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cicm>, <mailto:cicm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/cicm>
List-Post: <mailto:cicm@ietf.org>
List-Help: <mailto:cicm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cicm>, <mailto:cicm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Aug 2011 14:39:56 -0000
Interesting, Dave. Could you expand on your comment: "On the other hand, if there is a document that shows how a high assurance design approach can be used in an IETF standard like TLS or IPsec, that could be valuable." I was pondering whether there was a distinction underlying that comment? Like did you mean an approach that allows TLS or IPsec to terminate in a high assurance domain, or did you mean how to implement the protocols in a high assurance OE, or did you mean how to make protocol software be trustworthy? Or how to hook them up to the crypto? Or something else? I too see the HAIPE influence on this. As I have said, I frankly have a quibble with the way HAIPE is structured, its assumed domains are structured to need crypto bypass to work, that seems to be so widely assumed to be a fundamental need for secure comms (from the HW crypto legacy). I just don't see it that way. Thanks, John -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of Novikov, Lev Sent: Wednesday, August 03, 2011 7:03 AM To: CICM Discussion List (cicm@ietf.org) Subject: [cicm] FW: comments on CICM FYI: Below is an insightful email from David McGrew that does not appear to have made it to the mailing list nor was it held for moderation so the list never saw it. Lev -----Original Message----- From: David A. McGrew [mailto:david.a.mcgrew@mindspring.com] Sent: Wednesday, July 27, 2011 14:39 To: cicm@ietf.org; Lanz, Dan; Novikov, Lev Subject: comments on CICM Hi Lev and Daniel, I skimmed the CICM documents and have several comments. It seems that the major goal for CICM is multi-vendor support. Worthwhile goal, but what crypto hardware vendors whose products support IETF standards are participating in this effort? RFC 5116 defines a standard interface to Authenticated Encryption with Associated Data (AEAD) algorithms, which is used by TLS 1.2, SSH, SRTP, IKE, and SMIME, and is backwards compatible with ESP. The AEAD interface is simple (two defined messages, four inputs and one output each), and AEAD is widely regarded as the state of the art in security and efficiency (including both OCB and GCM, for instance). It appears that CICM is not compatible with this interface, in which case it would be a real step backwards. (If CICM does support AEAD, it is not clear to me how it does. Am I missing something?) CICM is intended for use in a high assurance crypto module. Considering that AES-GCM is required for Suite B, and the Suite B RFCs all cite RFC 5116, the lack of AEAD support appears problematic. The use cases for which CICM is intended are those where "cryptographic transformation of data initiated in one security domain with the result made available in another security domain"; three cases are given, two of which are HAIPE. So clearly the CICM design has been driven by high assurance requirements that are highly security conscious and not publicly available. My question here is: how will the CICM design make implementations of IETF security protocols better? If CICM is tightly bound to non-public protocols, it will not have much relevance to the IETF. On the other hand, if there is a document that shows how a high assurance design approach can be used in an IETF standard like TLS or IPsec, that could be valuable. It could be a good contribution to the IETF to provide implementation criteria or design approaches that are applicable to internet standards. I think there would be a good amount of interest in this sort of work, and in fact I would be very happy to see that sort of document show up in IRTF CFRG. An important nit: MD5 is used as an example on pg 24 of draft-lanz- cicm-02. It has been deprecated by RFC 6151; I encourage that a different hash be used as an example. regards, David _______________________________________________ cicm mailing list cicm@ietf.org https://www.ietf.org/mailman/listinfo/cicm
- [cicm] FW: comments on CICM Novikov, Lev
- Re: [cicm] FW: comments on CICM Davidson, John A.
- Re: [cicm] comments on CICM Cottrell Jr., James R.
- Re: [cicm] comments on CICM Krishnamurthy, Hema - ES
- Re: [cicm] comments on CICM David A. McGrew
- Re: [cicm] comments on CICM Cottrell Jr., James R.
- Re: [cicm] comments on CICM David A. McGrew
- Re: [cicm] FW: comments on CICM David A. McGrew
- Re: [cicm] FW: comments on CICM Davidson, John A.
- Re: [cicm] FW: comments on CICM jmitola
- Re: [cicm] FW: comments on CICM Alfonso De Gregorio