Re: [cicm] comments on CICM

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

Hi Jim,

http://tools.ietf.org/html/draft-peck-suiteb-dtls-srtp-00 requires AES- 
GCM, and is presumably intended for VoIP, though it does not  
specifically mention VoIP.

Suite B RFCs have shown a clear preference for GCM, though some other  
modes are allowed (as transitional in TLS, and within IKE but not ESP).

David

On Aug 3, 2011, at 2:05 PM, Cottrell Jr., James R. wrote:

> Hema,
>
> Thanks.
>
> Not all Suite B products will be IPsec.  I believe Harris has a  
> Suite B tactical radio.  For protection of voice traffic, I wouldn't  
> think that they used AES-GCM.
>
> Jim Cottrell
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf  
> Of Krishnamurthy, Hema - ES
> Sent: Wednesday, August 03, 2011 10:52 AM
> To: CICM Discussion List
> Subject: Re: [cicm] comments on CICM
>
> http://tools.ietf.org/html/rfc4869 lists AES-GCM as part of Suite B.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf  
> Of Cottrell Jr., James R.
> Sent: Wednesday, August 03, 2011 7:49 AM
> To: CICM Discussion List
> Subject: Re: [cicm] comments on CICM
>
> 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?
>
> 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
>
> This e-mail and any files transmitted with it may be proprietary and  
> are intended solely for the use of the individual or entity to whom  
> they are addressed. If you have received this e-mail in error please  
> notify the sender.
> Please note that any views or opinions presented in this e-mail are  
> solely those of the author and do not necessarily represent those of  
> ITT Corporation. The recipient should check this e-mail and any  
> attachments for the presence of viruses. ITT accepts no liability  
> for any damage caused by any virus transmitted by this e-mail.
> _______________________________________________
> cicm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cicm
> _______________________________________________
> cicm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/cicm