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: [email protected] [mailto:[email protected]] On Behalf
Of
Novikov, Lev
Sent: Wednesday, August 03, 2011 7:03 AM
To: CICM Discussion List ([email protected])
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:[email protected]]
Sent: Wednesday, July 27, 2011 14:39
To: [email protected]; 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
[email protected]
https://www.ietf.org/mailman/listinfo/cicm
_______________________________________________
cicm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cicm
_______________________________________________
cicm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cicm
