Re: [cicm] FW: comments on CICM
"Davidson, John A." <JOHN.A.DAVIDSON@saic.com> Thu, 04 August 2011 14:36 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 B996E21F8AE6 for <cicm@ietfa.amsl.com>; Thu, 4 Aug 2011 07:36:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.515
X-Spam-Level:
X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 zTF1dd4TbFgW for <cicm@ietfa.amsl.com>; Thu, 4 Aug 2011 07:36:01 -0700 (PDT)
Received: from cpmx2.mail.saic.com (cpmx2.mail.saic.com [139.121.17.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E37421F8AF3 for <cicm@ietf.org>; Thu, 4 Aug 2011 07:36:01 -0700 (PDT)
Received: from 0599-its-sbg03.saic.com ([139.121.20.253] [139.121.20.253]) by cpmx2.mail.saic.com with ESMTP id BT-MMP-5244907 for cicm@ietf.org; Thu, 4 Aug 2011 07:36:06 -0700
X-AuditID: 8b79132a-b7b62ae0000020af-35-4e3aae5665cb
Received: from 0599-its-exbh01.us.saic.com (cpe-z7-si-srcnat.sw.saic.com [139.121.20.253]) by 0599-its-sbg03.saic.com (Symantec Brightmail Gateway) with SMTP id 26.FD.08367.65EAA3E4; Thu, 4 Aug 2011 07:36:06 -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); Thu, 4 Aug 2011 07:36:06 -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: Thu, 04 Aug 2011 07:36:06 -0700
Message-Id: <7EDDD87A9A1D7F4DB6F78BC55AA4955002085E42@0461-its-exmb09.us.saic.com>
In-Reply-To: <BEA087FC-AA12-4412-B97D-F4643BA491DA@mindspring.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [cicm] FW: comments on CICM
Thread-Index: AcxSo0TWDjeXOGBYSoKQIJQ+rewJ9AAD0l9g
References: <99256CA4-47EB-444A-9D5C-29EEEF3C81D5@mindspring.com><F9AB58FA72BAE7449E7723791F6993ED0630B95AAF@IMCMBX3.MITRE.ORG><7EDDD87A9A1D7F4DB6F78BC55AA4955002085E39@0461-its-exmb09.us.saic.com> <BEA087FC-AA12-4412-B97D-F4643BA491DA@mindspring.com>
From: "Davidson, John A." <JOHN.A.DAVIDSON@saic.com>
To: CICM Discussion List <cicm@ietf.org>
X-OriginalArrivalTime: 04 Aug 2011 14:36:06.0815 (UTC) FILETIME=[D8486AF0:01CC52B3]
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: Thu, 04 Aug 2011 14:36:02 -0000
Wow, what insightful questions, David. The short answer is I don't know. But that won't deter me from rambling about it. I wish I knew how to approach some of your questions with high assurance IA solutions. I have never seen a formal definition of high assurance (HA), so when we talk about that we sometimes talk past each other. To me, from a formal methods perspective, high assurance means a near certainty that SOME IA security policy is successfully enforced. Less than HA may be good enough to protect from casual threats but it takes HA to protect against determined subversion. We have figured out the constraints we must impose on stuff to enforce some IA policies, like Bell-LaPadula [BLP] for example. Other policies (integrity and availability) we haven't even figured out how to express the policy formally, let alone enforce that with HA. But we have even figured out how to impose those constraints on SW by using HW mechanisms in the microprocessor. We still have not figured out how to make SW high assurance though. So from my perspective, approaches (such as guards and SW imposed domains) that rely (at all) on SW to behave or work correctly in some way are not going to be HA today. That means they should not be relied on to protect military classified data. I am involved with enforcing military security policies, namely BLP-like, or "don't disclose classified data", because it is the only thing we know how to do with HA. But BLP has little or no applicability to the non-military, commercial, internet world, where we lack security classification levels and formal employee clearance levels. Without giving it enough thought, my knee-jerk approach might be to try to define the security policies we wish we could enforce, then try to express them formally. This is hard. Then try to figure out how to enforce those with HW if we want HA. Short of that SW enforcement is likely to fall to subversion eventually. >From a real system IA standpoint, the kind of strategies that enforce "don't disclose military classified" is first defining security domain properties. Then we hook up the crypto to those domains securely, keeping connections and flows separated with HW-backed mechanisms, and controlling the data flow with HW-backed mechanisms to and from the crypto module so that nothing can physically flow that we do not allow. Then we have to control the crypto module such that it physically cannot do something illegal, maybe using some kind of HW-backed mechanisms that "know" the domain properties and rules, having them "wired in". We have been this rigorous on a few systems but we have kinda strayed from that kind of rigor recently. Not sure why, because it is really more expensive and harder to use to do it the way we now try to do it, with SW only. Seems like if we could figure out some rules at a low enough level that we can impose to imply whatever policy we want to enforce, we might find a similar way to apply HA more broadly. That too is hard. Now I am concerned that I should have thought a little longer and harder about my response. Oh well, Im not erasing it now. Kindest regards, John -----Original Message----- From: cicm-bounces@ietf.org [mailto:cicm-bounces@ietf.org] On Behalf Of David A. McGrew Sent: Thursday, August 04, 2011 5:37 AM To: CICM Discussion List Subject: Re: [cicm] FW: comments on CICM Hi John, On Aug 3, 2011, at 7:40 AM, Davidson, John A. wrote: > 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 didn't have any specific ideas in mind. > > 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. > I was wondering how we can make this work have a positive impact on Internet practice. I think this is one of CICM two goals, the other being to impact non-Internet practice that I'm not familiar with and can't comment on (I don't have any experience with HAIPE myself). On the goal of improving the state of the art of IETF security protocol implementation, there are a lot of open questions, and it would be essential to investigate the details of how the CICM model could work with Internet protocols. The CICM model (in which there is a secure side, and insecure side, and a crypto module between, and there are two messages queues that connect the module to each side, and don't pass any information back) is far from current practice for IETF security protocols. I assume that the goal for using a queue as an interface is to prevent side channels that could pass information from one side to the other. This could prevent a subliminal channel that could potentially be exploited by an untrustworthy application on the secure side to slowly leak information out to the insecure side, I suppose, which would be good in an implementation environment that already has strong separation between secure/insecure sides. But how many implementations of IETF protocols support such strong separations? This raises the question: what benefit does the CICM model provide in cases where there is no such separation? For improving current Internet practice, there are some other problem areas that in my opinion deserve to be addressed first, including reducing implementation flaws and the possibilty of remote timing attacks. Perhaps a message queue could be used to defeat timing attacks (like those against exponentiation algorithms or typing patterns in text-oriented protocols), though I am not sure if that is an explicit goal. But increased implementation complexity would likely increase the number of implementation flaws. At any rate, defeating a timing attack doesn't require hiding return codes from a calling application. Perhaps there is another class of attacks being addressed by that approach, though I'm not quite sure what it protects against. The idea of having a queue (or two?) in between the plaintext and ciphertext sides raises some interesting questions about networking, such as: what is the impact on latency, jitter, retransmission timers, TCP startup time? how bad is the impact on bufferbloat? what protocols can run over these queues without impact, and what ones could not? The practice of not providing return codes to a secure-side application sending a packet, even when that packet couldn't be sent, would also have an impact. What about "no route to host" and MTUs? A secure-side application can get information back through messages that it receives from its peer in the cryptographic protocol. Thus, if it is a goal to prevent information from the insecure side from getting into the secure side, it would appear that it would be a requirement in this security model to have both sides of the crypto protocol use the same model. That is, some of the security properties that would accrue from using the CICM model would be voided if only one of the communicating parties used that model. It seems to me that the protocol that best matches the CICM model is IPsec, but there are still many open questions about how it could work, such as: how would this map onto the idea of an IPsec Security Association Database? Where would the different parts of the IPsec architecture reside? What would happen to information that needs to be copied from one side to the other, such as a ToS byte? what happens to how ICMP gets handled in IPsec? I personally feel that work on improving the practice of security protocol implementations would be valuable, but that the best approach would be to identify the most significant threats and vulnerabilities, then work on mitigating them. For instance, it would be worthwhile to develop an interface to cryptography that kept details about initialization vectors inside the crypto module, since it is widely regarded that IVs can be a problem area. But if there is interest in applying the CICM model to Internet practice, I would suggest starting with the applicability questions that other people and I have raised (Paul Hoffman had some good suggestions in the BoF), and I would be willing to participate at least as a reviewer. Apologies for the somewhat rambling email. David > 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 mailing list > cicm@ietf.org > https://www.ietf.org/mailman/listinfo/cicm _______________________________________________ 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