Re: [cicm] comments on CICM

["David A. McGrew" <[e-mail]>]

On Aug 3, 2011, at 7:49 AM, Cottrell Jr., James R. wrote:

> David McGrew,
>
> In your email you stated " 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"
>
> Can you please provide an authoritative document stating this  
> requirement?
>

Let me use TLS as an example.  The AEAD facility in TLS 1.2 is based  
on RFC 5116.  For Suite B, RFC 5430 requires RFC 5289, which requires  
RFC 5288, which has RFC 5116 as a normative reference.

In the quote above, I said "all".  I may have been wrong on that; I  
was rushing to get my comments out before the CICM BoF.  But I stand  
by the broader point, which is that support for AEAD would be essential.

David


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