Re: [cicm] FW: comments on CICM

Alfonso De Gregorio <adg@crypto.lo.gy> Thu, 04 August 2011 16:36 UTC

Return-Path: <adg@crypto.lo.gy>
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 A55FF21F8BAC for <cicm@ietfa.amsl.com>; Thu, 4 Aug 2011 09:36:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.977
X-Spam-Level:
X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 1b9PpQFujlcD for <cicm@ietfa.amsl.com>; Thu, 4 Aug 2011 09:36:12 -0700 (PDT)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 1E4AA21F8888 for <cicm@ietf.org>; Thu, 4 Aug 2011 09:36:12 -0700 (PDT)
Received: by gxk19 with SMTP id 19so1348125gxk.31 for <cicm@ietf.org>; Thu, 04 Aug 2011 09:36:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.142.217.3 with SMTP id p3mr952953wfg.166.1312475786233; Thu, 04 Aug 2011 09:36:26 -0700 (PDT)
Received: by 10.142.99.16 with HTTP; Thu, 4 Aug 2011 09:36:26 -0700 (PDT)
X-Originating-IP: [195.32.92.139]
In-Reply-To: <BEA087FC-AA12-4412-B97D-F4643BA491DA@mindspring.com>
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>
Date: Thu, 04 Aug 2011 18:36:26 +0200
Message-ID: <CAEk7eQQj-HvzDF4tM0NadG_2gVPr3YV1BSnAWWGEv4xgePY6vA@mail.gmail.com>
From: Alfonso De Gregorio <adg@crypto.lo.gy>
To: CICM Discussion List <cicm@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
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 16:36:17 -0000

Hi all,

On Thu, Aug 4, 2011 at 2:36 PM, David A. McGrew
<david.a.mcgrew@mindspring.com> wrote:
> 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.

David, I believe your post raises a number of relevant questions.
Investigating them can really help us in describing -- maybe a topic
for a new ID? -- how the CICM model could work with Internet
protocols.

While the CICM model can be beneficial in enforcing the star-property
(therefore, mitigating the information leak and contributing towards
the overall confidentiality), it can help us in providing also
stronger integrity guarantees.

Let's consider, for example, systems implementing strong isolation
between different security domains or even system-level components
(e.g., networking, or storage), so that their compromise don't affect
the integrity of the rest of the system. In the open-source world,
this is the case of Qubes, where security domains are lightweight
virtual machines (VM) and the networking code, including drivers and
protocol stacks, has been confined  (using IOMMU/VT-d) to an
unpriviledged VM, called the Network Domain.

The CICM model would fit well into this class of architectures, where:
- the "Network Domain" (or the communication channel) is the insecure side;
- the crypto module can be run in a separate domain (*), isolated from
the world-facing networking code that might be exploited, sooner or
later;
- security protocols (e.g, VPN protocols) are also implemented in
separate domains, exposing their services (e.g., virtual network
interfaces) to the other privileged domains.

(*) far from suggesting that isolation mechanisms based on IOMMU/VT-d
are sufficient per se in achieving high assurance.

Hence, from a security architecture perspective, CICM may have a
positive impact in both the confidentiality and integrity guarantees
provided by IETF protocol implementations.

Which protocols?

> 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?

Agreed. IPsec looks to be the best match, as well all cryptographic
protocols supporting the establishment of VPN connections.

I'm thinking also about domain security services, such as those
described by RFC 3183 (Domain Security Services using S/MIME).


> 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

I'd be super happy to join the CICM activities, in the way the group
believes to be best.

alfonso


-- 
 tweets @secYOUre      blog. http://Plaintext.crypto.lo.gy/