From pbaker@verisign.com Thu Feb 14 16:12:47 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1ELClhI004054 for ; Thu, 14 Feb 2008 16:12:47 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1ELCduV000685 for ; Thu, 14 Feb 2008 16:12:39 -0500 (EST) Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id B5F9A661053 for ; Thu, 14 Feb 2008 16:12:11 -0500 (EST) Received: from MOU1WNEXCN02.vcorp.ad.vrsn.com (mailer2.verisign.com [65.205.251.35]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id m1EL3T25015669; Thu, 14 Feb 2008 13:03:29 -0800 Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN02.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 14 Feb 2008 13:11:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C86F4E.30468BBD" Date: Thu, 14 Feb 2008 13:11:38 -0800 Message-ID: <2788466ED3E31C418E9ACC5C31661557085054@mou1wnexmb09.vcorp.ad.vrsn.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Managing aglorithms RE: [saag] TCP-AO MAC algorithms Thread-Index: AchPNZnvg3oZINqbR9OlgXOnfhQIpQgFjeCh References: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com><20080101020627.CBFAE5081A@romeo.rtfm.com> <20080105004455.9577F5081A@romeo.rtfm.com> From: "Hallam-Baker, Phillip" To: "Eric Rescorla" , "Brian Weis" X-OriginalArrivalTime: 14 Feb 2008 21:11:39.0106 (UTC) FILETIME=[30736420:01C86F4E] X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: [saag] Managing aglorithms RE: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Feb 2008 21:12:47 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C86F4E.30468BBD Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To tie a number of threads together here I think it would help = enormously if we had some sort of cross IETF statement of the set of = algorithms that are currently the consensus recommendations for support. =20 I don't think that there is a lot of disagreement on the important = points, e.g. : =20 * If you are designing an entirely new protocol that requires block = encryption specify AES-128 and AES-256 as MUST =20 * The use of 3DES, HMAC-SHA1, should be avoided in entirely new = protocols but is not cause for concern in deployed protocols. =20 * Use of SHA1 should be avoided except in deployed protocols where there = has been careful analysis that demonstrates use in that application is = not cause for concern. =20 * Use of MD5, ciphers with a strength of 56 bits or less should be = avoided in almost all circumstances. Use of ciphers with key sizes of 64 = bits or less should be discontinued as soon as is practicable. =20 * If someone wants to specify vanity crypto, give them the necessary URI = or OID and tell them to use it at their own discretion. =20 =20 I don't think we should have this discussion in every individual working = group.=20 =20 I especially don't want to have to have the discussion on how to use ECC = with each individual IETF spec in turn. Or worse have extended = discussions over the optimal choice of group etc. so that we end up with = different choices across the IETF. If the specifications are well = designed we should have all the information necessary to specify how to = use algorithms across the board. =20 As things stand I think we are going to end up with more crypto = configurations in IETF protocols than we have crypto people. And that = would be a bad thing when there is a pretty strong consensus on = preferred algorithms in the field. ________________________________ From: saag-bounces@mit.edu on behalf of Eric Rescorla Sent: Fri 04/01/2008 7:44 PM To: Brian Weis Cc: saag@mit.edu Subject: Re: [saag] TCP-AO MAC algorithms At Fri, 4 Jan 2008 15:06:59 -0800, Brian Weis wrote: > > > On Dec 31, 2007, at 6:06 PM, Eric Rescorla wrote: > > > At Tue, 18 Dec 2007 16:23:51 -0800, > > Brian Weis wrote: > >> > >> Greetings, > >> > >> The TCPM WG seeks advice from SAAG on which MACs to include as > >> required MACs for the TCP Authentication Option = (draft-ietf-tcpm-tcp- > >> auth-opt-00). > > > > I would note that TLS has one MTI MAC (HMAC-SHA1) and based on RFC > > 4835, so does ESP/AH (HMAC-SHA1-96). What's the rationale for why > > TCP-AO should have stricter MTI requirements than we have for > > our dedicated security protocols? > > The rationale is simply that two methods with differing internal=20 > constructions implies that the standard is better prepared for the=20 > future (if one of the two MACs is perceived to be broken). Yes, this strikes me as massive overkill, given that typical MAC constructions are designed with some kind of reduction to the primitive they are based on. If, for instance, SHA-256 is broken badly enough that it implicates HMAC, it seems likely that we're going to have so many other cryptographic problems that the remaining security of TCP-AO will be the least of our worries. > >> Two MACs with differing internal constructions are > >> desired. > > > > I don't understand this either. Most modern MACs are constructed = from > > two pieces: > > > > - An underlying cryptographic function > > - A composition operation > > > > Thus, for instance, HMAC-SHA1 is constructed by using the HMAC > > composition operation with SHA-1. In general, the security = properties > > of the composition operations are well understood (often with some > > kind of reduction proof) where the security properties of the > > underlying function are unproven. So, while it might make sense > > to have two different base cryptographic functions (e.g., > > SHA-1 and SHA-256), it's not at all clear that it's of that > > much value to have two different constructions. > > Agreed that if two RTI MACs are chosen that the MACs must be=20 > significantly different. That's why the proposed set includes one of=20 > SHA-1 using HMAC (a Wegman-Carter MAC), and another of AES using CMAC=20 > (a cipher block chaining mode intended for authentication). I'm not sure why you say "agreed". As I said, I don't agree with this. On the contrary, I don't see much value in using different constructions. There's no reason to believe there's anything wrong with HMAC, the issue (to the extent to which there is any) is purely with the digests used by HMAC. If, for some reason, there is a perceived need to specify two functions HMAC with two different (potentially unrelated) digests seems fine. -Ekr _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag ------_=_NextPart_001_01C86F4E.30468BBD Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [saag] TCP-AO MAC algorithms=0A= =0A= =0A= =0A=
=0A=
To tie a = number of threads together here I think it would help enormously if we = had some sort of cross IETF statement of the set of algorithms that are = currently the consensus recommendations for support.
=0A=
 
=0A=
I don't think that there is a = lot of disagreement on the important points, e.g. :
=0A=
 
=0A=
* If you are designing an = entirely new protocol that requires block encryption specify AES-128 and = AES-256 as MUST
=0A=
 
=0A=
* The use of 3DES, HMAC-SHA1, = should be avoided in entirely new protocols but is not cause for concern = in deployed protocols.
=0A=
 
=0A=
* Use of SHA1 should be = avoided except in deployed protocols where there has been careful = analysis that demonstrates use in that application is not cause for = concern.
=0A=
 
=0A=
* Use of MD5, ciphers with a = strength of 56 bits or less should be avoided in almost all = circumstances. Use of ciphers with key sizes of 64 bits or less should = be discontinued as soon as is practicable.
=0A=
 
=0A=
* If someone wants to specify = vanity crypto, give them the necessary URI or OID and tell them to use = it at their own discretion.
=0A=
 
=0A=
 
=0A=
I don't think we should have = this discussion in every individual working group.
=0A=
 
=0A=
I especially don't want to = have to have the discussion on how to use ECC with each individual IETF = spec in turn. Or worse have extended discussions over the optimal choice = of group etc. so that we end up with different choices across the IETF. = If the specifications are well designed we should have all the = information necessary to specify how to use algorithms across the = board.
=0A=
 
=0A=
As things stand I think we = are going to end up with more crypto configurations in IETF protocols = than we have crypto people. And that would be a bad thing when there is = a pretty strong consensus on preferred algorithms in the = field.
=0A=

=0A=
=0A= From: saag-bounces@mit.edu on behalf = of Eric Rescorla
Sent: Fri 04/01/2008 7:44 PM
To: = Brian Weis
Cc: saag@mit.edu
Subject: Re: [saag] = TCP-AO MAC algorithms

=0A=
=0A=

At Fri, 4 Jan 2008 15:06:59 -0800,
Brian Weis = wrote:
>
>
> On Dec 31, 2007, at 6:06 PM, Eric = Rescorla wrote:
>
> > At Tue, 18 Dec 2007 16:23:51 = -0800,
> > Brian Weis wrote:
> >>
> >> = Greetings,
> >>
> >> The TCPM WG seeks advice = from SAAG on which MACs to include as
> >> required MACs for = the TCP Authentication Option (draft-ietf-tcpm-tcp-
> >> = auth-opt-00).
> >
> > I would note that TLS has one = MTI MAC (HMAC-SHA1) and based on RFC
> > 4835, so does ESP/AH = (HMAC-SHA1-96). What's the rationale for why
> > TCP-AO should = have stricter MTI requirements than we have for
> > our = dedicated security protocols?
>
> The rationale is simply = that two methods with differing internal 
> constructions = implies that the standard is better prepared for the 
> = future (if one of the two MACs is perceived to be broken).

Yes, = this strikes me as massive overkill, given that typical
MAC = constructions are designed with some kind of reduction
to the = primitive they are based on. If, for instance, SHA-256
is broken = badly enough that it implicates HMAC, it seems
likely that we're = going to have so many other cryptographic
problems that the remaining = security of TCP-AO will be the
least of our worries.


> = >> Two MACs with differing internal constructions are
> = >> desired.
> >
> > I don't understand this = either. Most modern MACs are constructed from
> > two = pieces:
> >
> > - An underlying cryptographic = function
> > - A composition operation
> >
> = > Thus, for instance, HMAC-SHA1 is constructed by using the = HMAC
> > composition operation with SHA-1. In general, the = security properties
> > of the composition operations are well = understood (often with some
> > kind of reduction proof) where = the security properties of the
> > underlying function are = unproven. So, while it might make sense
> > to have two = different base cryptographic functions (e.g.,
> > SHA-1 and = SHA-256), it's not at all clear that it's of that
> > much = value to have two different constructions.
>
> Agreed that = if two RTI MACs are chosen that the MACs must be 
> = significantly different. That's why the proposed set includes one = of 
> SHA-1 using HMAC (a Wegman-Carter MAC), and another of = AES using CMAC 
> (a cipher block chaining mode intended for = authentication).

I'm not sure why you say "agreed". As I said, I = don't agree with this.

On the contrary, I don't see much value in = using different
constructions. There's no reason to believe there's = anything wrong
with HMAC, the issue (to the extent to which there is = any) is purely
with the digests used by HMAC. If, for some reason, = there is a perceived
need to specify two functions HMAC with two = different (potentially
unrelated) digests seems = fine.

-Ekr



________________________________________= _______
saag mailing list
saag@mit.edu
http://mailman.mit.= edu/mailman/listinfo/saag

------_=_NextPart_001_01C86F4E.30468BBD-- From vishwas.ietf@gmail.com Fri Feb 15 12:49:55 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1FHntHw025083 for ; Fri, 15 Feb 2008 12:49:55 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1FHnjVP001470 for ; Fri, 15 Feb 2008 12:49:45 -0500 (EST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mit.edu (Spam Firewall) with ESMTP id C8100D595F0 for ; Fri, 15 Feb 2008 12:49:44 -0500 (EST) Received: by ug-out-1314.google.com with SMTP id e2so1249597ugf.36 for ; Fri, 15 Feb 2008 09:49:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=Rtw2BtQBU/gq+k/9p8cgpfpl0ZGE7br6yZLM9uBVsxE=; b=PNBGMFz0V3/YWrjKsUyL4MzlWwj84lAAjjWvaMp0hma2cLiic3UJEhwKfD24RQCDpQahXeYEMx85atc8qgXnHWbJGBk3D2ng7iAhGYwL4sNchBsb7/p6vGdBTwWcDM1ZyOHUFIDW7NbyK/JIW+XXs9rzG8WOeo1MwZB/JygNoU0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=aiF03cH+D9Bq46IxjBFJyPf6SKmLyoNUMsuNyYcpJYfN/j4YINPrQQwZ++A8NAdMn/YV0SjKDy3WpOG3arianv6VR7uKmNPg1T1tQmez5MUy9MrpYLu86P/pOoHNIpV/Ov9GcdEDmWiVOFgJ3hqnbW89foWr4/sKuW7I4w65wS8= Received: by 10.142.141.21 with SMTP id o21mr2516935wfd.84.1203097782998; Fri, 15 Feb 2008 09:49:42 -0800 (PST) Received: by 10.143.164.14 with HTTP; Fri, 15 Feb 2008 09:49:42 -0800 (PST) Message-ID: <77ead0ec0802150949j5e6c9a70kde201d667362ce2c@mail.gmail.com> Date: Fri, 15 Feb 2008 09:49:42 -0800 From: "Vishwas Manral" To: "Hallam-Baker, Phillip" In-Reply-To: <2788466ED3E31C418E9ACC5C31661557085054@mou1wnexmb09.vcorp.ad.vrsn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <98FA6BE8-0825-41F6-8DAA-1A5706D974A9@cisco.com> <20080101020627.CBFAE5081A@romeo.rtfm.com> <20080105004455.9577F5081A@romeo.rtfm.com> <2788466ED3E31C418E9ACC5C31661557085054@mou1wnexmb09.vcorp.ad.vrsn.com> X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Managing aglorithms RE: TCP-AO MAC algorithms X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2008 17:49:55 -0000 Hi Phillip, I agree we probably could have some document talking about generic recommendations like those you suggest. However I would feel every application may have its own set of requirements which may overlap but not necessarily be the same. Not all applications require the same level of security. That said I would think the TCP-AO draft should follow the recommendations of RFC4835 like Eric mentioned earlier. Thanks, Vishwas 2008/2/14 Hallam-Baker, Phillip : > > > > To tie a number of threads together here I think it would help enormously if > we had some sort of cross IETF statement of the set of algorithms that are > currently the consensus recommendations for support. > > I don't think that there is a lot of disagreement on the important points, > e.g. : > > * If you are designing an entirely new protocol that requires block > encryption specify AES-128 and AES-256 as MUST > > * The use of 3DES, HMAC-SHA1, should be avoided in entirely new protocols > but is not cause for concern in deployed protocols. > > * Use of SHA1 should be avoided except in deployed protocols where there has > been careful analysis that demonstrates use in that application is not cause > for concern. > > * Use of MD5, ciphers with a strength of 56 bits or less should be avoided > in almost all circumstances. Use of ciphers with key sizes of 64 bits or > less should be discontinued as soon as is practicable. > > * If someone wants to specify vanity crypto, give them the necessary URI or > OID and tell them to use it at their own discretion. > > > I don't think we should have this discussion in every individual working > group. > > I especially don't want to have to have the discussion on how to use ECC > with each individual IETF spec in turn. Or worse have extended discussions > over the optimal choice of group etc. so that we end up with different > choices across the IETF. If the specifications are well designed we should > have all the information necessary to specify how to use algorithms across > the board. > > As things stand I think we are going to end up with more crypto > configurations in IETF protocols than we have crypto people. And that would > be a bad thing when there is a pretty strong consensus on preferred > algorithms in the field. > > ________________________________ > From: saag-bounces@mit.edu on behalf of Eric Rescorla > Sent: Fri 04/01/2008 7:44 PM > To: Brian Weis > Cc: saag@mit.edu > Subject: Re: [saag] TCP-AO MAC algorithms > > > > > At Fri, 4 Jan 2008 15:06:59 -0800, > Brian Weis wrote: > > > > > > On Dec 31, 2007, at 6:06 PM, Eric Rescorla wrote: > > > > > At Tue, 18 Dec 2007 16:23:51 -0800, > > > Brian Weis wrote: > > >> > > >> Greetings, > > >> > > >> The TCPM WG seeks advice from SAAG on which MACs to include as > > >> required MACs for the TCP Authentication Option (draft-ietf-tcpm-tcp- > > >> auth-opt-00). > > > > > > I would note that TLS has one MTI MAC (HMAC-SHA1) and based on RFC > > > 4835, so does ESP/AH (HMAC-SHA1-96). What's the rationale for why > > > TCP-AO should have stricter MTI requirements than we have for > > > our dedicated security protocols? > > > > The rationale is simply that two methods with differing internal > > constructions implies that the standard is better prepared for the > > future (if one of the two MACs is perceived to be broken). > > Yes, this strikes me as massive overkill, given that typical > MAC constructions are designed with some kind of reduction > to the primitive they are based on. If, for instance, SHA-256 > is broken badly enough that it implicates HMAC, it seems > likely that we're going to have so many other cryptographic > problems that the remaining security of TCP-AO will be the > least of our worries. > > > > >> Two MACs with differing internal constructions are > > >> desired. > > > > > > I don't understand this either. Most modern MACs are constructed from > > > two pieces: > > > > > > - An underlying cryptographic function > > > - A composition operation > > > > > > Thus, for instance, HMAC-SHA1 is constructed by using the HMAC > > > composition operation with SHA-1. In general, the security properties > > > of the composition operations are well understood (often with some > > > kind of reduction proof) where the security properties of the > > > underlying function are unproven. So, while it might make sense > > > to have two different base cryptographic functions (e.g., > > > SHA-1 and SHA-256), it's not at all clear that it's of that > > > much value to have two different constructions. > > > > Agreed that if two RTI MACs are chosen that the MACs must be > > significantly different. That's why the proposed set includes one of > > SHA-1 using HMAC (a Wegman-Carter MAC), and another of AES using CMAC > > (a cipher block chaining mode intended for authentication). > > I'm not sure why you say "agreed". As I said, I don't agree with this. > > On the contrary, I don't see much value in using different > constructions. There's no reason to believe there's anything wrong > with HMAC, the issue (to the extent to which there is any) is purely > with the digests used by HMAC. If, for some reason, there is a perceived > need to specify two functions HMAC with two different (potentially > unrelated) digests seems fine. > > -Ekr > > > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > > From rja@extremenetworks.com Sat Feb 16 18:43:27 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1GNhRlg009443 for ; Sat, 16 Feb 2008 18:43:27 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1GNhKeq021111 for ; Sat, 16 Feb 2008 18:43:20 -0500 (EST) Received: from ussc-casht-p2.corp.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id C8B9CFABA1C for ; Sat, 16 Feb 2008 18:42:59 -0500 (EST) Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Sat, 16 Feb 2008 15:42:58 -0800 From: Randall Atkinson To: "saag@mit.edu" Date: Sat, 16 Feb 2008 15:42:57 -0800 Thread-Topic: Algorithms/modes requested by users/customers Thread-Index: AQHIcPWoS7HEfANh0kyQUz3uBqgcnA== Message-ID: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1GNhRlg009443 Subject: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Feb 2008 23:43:27 -0000 Earlier, someone said: % I think it would help enormously if we had some sort of % cross IETF statement of the set of algorithms that are % currently the consensus recommendations for support. I will answer a slightly different question. For the question: "What algorithms/modes are most paying customers asking for ?" the answers turn out to be: 1) NIST FIPS-140 conforming algorithms/modes. and 2) Suite-B conforming algorithms/modes. Approximately speaking, (2) above is a subset of (1) above. The IETF might make some different decision than those, but equipment vendors will have to implement (1) or (2) to please most commercial users (e.g. banks, insurance firms, stock brokerages/markets, top international commercial firms in other areas). So whether or not these are specified by IETF on the standards-track, there is interoperability value in having open specifications (e.g. Informational RFC would do quite nicely) for (1) and (2) for nearly any Internet-related protocol using cryptography. This seems to be driven externally by insurance firms that tell their customers to only use equipment whose cryptographic subsystems/modules have been (or are going to be) evaluated formally under FIPS-140. And I'll note that this are not really driven particularly by US firms. European, Asia/Pacific, and Latin American firms are making the exact same requests for FIPS-140 of their equipment vendors. Yours, Ran rja@extremenetworks.com From paul.hoffman@vpnc.org Sun Feb 17 12:48:54 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1HHmsSK026239 for ; Sun, 17 Feb 2008 12:48:54 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1HHmimj023096 for ; Sun, 17 Feb 2008 12:48:44 -0500 (EST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 793A4CD3DCC for ; Sun, 17 Feb 2008 12:48:23 -0500 (EST) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1HHmIvk020317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 17 Feb 2008 10:48:19 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> Date: Sun, 17 Feb 2008 09:47:53 -0800 To: Randall Atkinson , "saag@mit.edu" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Feb 2008 17:48:54 -0000 At 3:42 PM -0800 2/16/08, Randall Atkinson wrote: >1) NIST FIPS-140 conforming algorithms/modes. >and >2) Suite-B conforming algorithms/modes. This seems reasonable, and similar to what I hear from VPNC members. (Sadly, these same members ship new equipment defaulting to algorithms not in that list, but that's a different thread...) >This seems to be driven externally by insurance firms that tell >their customers to only use equipment whose cryptographic >subsystems/modules have been (or are going to be) evaluated >formally under FIPS-140. That is unreasonable. The ratio of "number of systems that use crypto" to "number of systems that have been or are going to be evaluated formally under FIPS-140" is incredibly high. The FIPS 140 evaluation process is horribly broken on a number of axes, and all the vendors in the field know it and complain privately about it. If you had instead said "have been (or at least could be) evaluated", I would agree with you. Buyers want to know that, if pressed hard, they can say "well, it is like that other system over there that got certified", and to do that, the uncertified system has to at least support all the right crypto. There is a noticeable but non-quantifiable preference for systems with a FIPS 140 certificate, but (outside the USGovt, of course) nearly no hard demand. >And I'll note that this are not really driven particularly by US firms. >European, Asia/Pacific, and Latin American firms are making the >exact same requests for FIPS-140 of their equipment vendors. I have heard that as well from VPNC members. But note the use of the term "requests". It would be a mistake for the IETF to look like we support the FIPS 140 certification process, even though it makes good sense for us to use the algorithms in that process as the basis for a suggested cross-IETF algorithm suite. --Paul Hoffman, Director --VPN Consortium From rja@extremenetworks.com Sun Feb 17 20:07:54 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1I17qsX030461 for ; Sun, 17 Feb 2008 20:07:52 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1I17gF7026626 for ; Sun, 17 Feb 2008 20:07:42 -0500 (EST) Received: from ussc-casht-p2.corp.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 982ED7773BA for ; Sun, 17 Feb 2008 20:06:56 -0500 (EST) Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Sun, 17 Feb 2008 17:06:45 -0800 From: Randall Atkinson To: "saag@mit.edu" Date: Sun, 17 Feb 2008 17:06:44 -0800 Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: AchxjUlasNZBMgpDR7eptKQLGarIKgAOyiW0 Message-ID: <8329C86009B2F24493D76B486146769A9429B7A9@USEXCHANGE.corp.extremenetworks.com> References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1I17qsX030461 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Feb 2008 01:07:54 -0000 Earlier Paul Hoffman said: % If you had instead said "have been (or at least could be) evaluated", % I would agree with you. Buyers want to know that, if pressed hard, % they can say "well, it is like that other system over there that got % certified", and to do that, the uncertified system has to at least % support all the right crypto. There is a noticeable but % non-quantifiable preference for systems with a FIPS 140 certificate, % but (outside the USGovt, of course) nearly no hard demand. It seems that what you are hearing and what I am hearing differ somewhat in this area. As an example, I've had multiple large non-US commercial firms in the City of London tell me that they require FIPS-140 approvals for cryptographic equipment they will purchase -- and that this was originally the idea of their insurers. These same firms have very substantial networking deployments at present and purchase equipment in large quantities. Separately, several governments other than the USA are requiring FIPS-140 approvals in equipment that they purchase. These other countries include places in Europe and Asia/Pacific and other continents/regions. Again, the volume of such systems is both non-trivial and quantifiable. % It would be a mistake for the IETF to look like we support % the FIPS 140 certification process, So far as I am aware, your comments above are the first suggestion of that. Certainly I did NOT suggest that and don't suggest it now. % even though it makes good sense for us to use the algorithms in % that process as the basis for a suggested cross-IETF algorithm suite. That is farther than I went. I simply suggested that there ought to be open specifications for how to use FIPS-conformant algorithms and modes with Internet protocols. An "open specification" could be an Informational status RFC, for example. That way users who do care about FIPS approvals would have a reasonable shot at being able to purchase interoperable equipment from multiple vendors -- and implementers would have a clear specification to work with. I did not (and do not now) advocate that the IETF standards track ought to do any particular thing with respect to cryptographic algorithms/modes. Yours, Ran Atkinson rja@extremenetworks.com From kent@bbn.com Tue Feb 19 10:16:10 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JFGAv6006937 for ; Tue, 19 Feb 2008 10:16:10 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JFG2hn016246 for ; Tue, 19 Feb 2008 10:16:03 -0500 (EST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu (Spam Firewall) with ESMTP id 776AACCF438 for ; Tue, 19 Feb 2008 10:15:41 -0500 (EST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JRUC4-0002Ch-5y; Tue, 19 Feb 2008 10:15:41 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> Date: Tue, 19 Feb 2008 10:15:42 -0500 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: "saag@mit.edu" , Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 15:16:10 -0000 At 9:47 AM -0800 2/17/08, Paul Hoffman wrote: >... >>This seems to be driven externally by insurance firms that tell >>their customers to only use equipment whose cryptographic >>subsystems/modules have been (or are going to be) evaluated >>formally under FIPS-140. > >That is unreasonable. The ratio of "number of systems that use >crypto" to "number of systems that have been or are going to be >evaluated formally under FIPS-140" is incredibly high. The FIPS 140 >evaluation process is horribly broken on a number of axes, and all >the vendors in the field know it and complain privately about it. > >If you had instead said "have been (or at least could be) evaluated", >I would agree with you. Buyers want to know that, if pressed hard, >they can say "well, it is like that other system over there that got >certified", and to do that, the uncertified system has to at least >support all the right crypto. There is a noticeable but >non-quantifiable preference for systems with a FIPS 140 certificate, >but (outside the USGovt, of course) nearly no hard demand. Paul, Can you share the reasons cited by vendors to support the notion that the FIPS 140 process is broken. Compared to other security evaluation criteria, e.g. CC or the old Organge Book, most security folks I know view the FIPS 140 evaluation program as well managed and not very onerous. Also, if buyers believe that a device that "could be evaluated" is good enough, they are being rather naive. Experience with the FIPS 140 program has shown that a significant fraction of of products submitted for evaluation fail the process. Presumably a vendor submitting a product for evaluation believes that the product is ready, and will pass, otherwise the vendor is wasting money on the evaluation effort. The fact that many products fail evaluation (for good security reasons), tells me that a vendor's claim that a product "could be evaluated" is not much of an assurance. Steve From rja@extremenetworks.com Tue Feb 19 10:35:40 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JFZeXt015205 for ; Tue, 19 Feb 2008 10:35:40 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1JFZVXb008340 for ; Tue, 19 Feb 2008 10:35:32 -0500 (EST) Received: from ussc-casht-p2.corp.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id D06F4DDF61A for ; Tue, 19 Feb 2008 10:35:10 -0500 (EST) Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Tue, 19 Feb 2008 07:35:09 -0800 From: Randall Atkinson To: "saag@mit.edu" Date: Tue, 19 Feb 2008 07:35:08 -0800 Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: AchzCkrWW2rvMNdgR4y9V+Rd88/V4AAADsK4 Message-ID: <8329C86009B2F24493D76B486146769A9429B7C6@USEXCHANGE.corp.extremenetworks.com> References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> , In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1JFZeXt015205 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 15:35:40 -0000 Earlier, Steve Kent wrote: % Also, if buyers believe that a device that "could be evaluated" is % good enough, they are being rather naive. Experience with the % FIPS 140 program has shown that a significant fraction of of % products submitted for evaluation fail the process. The quoted text above is fully consistent with my information (and my very limited personal experience) on this topic. % Presumably a vendor submitting a product for evaluation % believes that the product is ready, and will pass, otherwise the % vendor is wasting money on the evaluation effort. Some purchasers, including some US DoD components, do not require that a product actually be FIPS-140 certified in order for the purchaser to buy the product. Instead, some purchasers, including some US DoD components, only require that a product be "in evaluation" on the NIST web site in order to bid/sell that product. This can incent some vendors to submit products for FIPS-140 evaluation in order to bid/sell the product -- even if the vendor is unsure whether the product will pass that evaluation at that point in time. This last is a business decision based on various business factors, and is not necessarily a technical decision. Separately, there is substantial documentation required to pass a FIPS-140 evaluation, and it is not crystal clear upfront what level of detail on which topics is required to pass the evaluation. So, separate from the question of whether the product itself is ready, there is usually substantial documentation work required of the submitter after the formal FIPS-140 evaluation commences. The one area where I have heard concerns expressed by many implementers is that it can be difficult/time-consuming/expensive to "RAMP" an approved product so that a later version is approved formally under FIPS-140. I don't know if this is an actual process issue or merely a perceived issue. At least one implementer has commented to me that their latest FIPS-approved firmware has known-bugs fixed in subsequent non-FIPS-approved firmware because of (real or perceived) "RAMP" process issues. % The fact that many products fail evaluation (for good security % reasons), tells me that a vendor's claim that a product % "could be evaluated" is not much of an assurance. Agreed. And this point has been made to me by several different commercial/financial firms. It is not a coincidence that the encryptor I use at my home has an actual FIPS-140 certificate, nor that I use that system in FIPS mode. (And at this point, I seem a bit far from the charter of the SAAG list, but I'm not sure where followups should go. My apologies to any who viewed this as excessively off-topic.) Yours, Ran rja@extremenetworks.com DISCLAIMER: I am employed by Extreme Networks, but I am never authorised to speak for my employer. The text from me above is my own personal views/understanding, and must not be taken as a position held by my employer. From paul.hoffman@vpnc.org Tue Feb 19 11:19:18 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JGJIdo001231 for ; Tue, 19 Feb 2008 11:19:18 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1JGJAd0019344 for ; Tue, 19 Feb 2008 11:19:11 -0500 (EST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 76AE5C9E700 for ; Tue, 19 Feb 2008 11:18:49 -0500 (EST) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JGIQhh073200 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 09:18:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks . com> Date: Tue, 19 Feb 2008 08:18:24 -0800 To: Stephen Kent From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: "saag@mit.edu" , Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 16:19:18 -0000 At 10:15 AM -0500 2/19/08, Stephen Kent wrote: >Can you share the reasons cited by vendors to support the notion >that the FIPS 140 process is broken. Sure. - It takes way too long from submission of system to validation, even if no problems are found. - If problems are found during evaluation, the restart time is too long. - Some of the tests are fairly subjective, and it becomes a game of fixing code to please the testing service, not to make the product more secure. - An evaluated product cannot have its core firmware updated without losing the validation. For example, if a customer asks for a new feature that might touch the crypto, the vendor has to choose between losing the validation (and paying for a new one, and waiting for the results) or keeping the customer happy. - The validation doesn't even check for on-the-wire interoperability, which is what the customers care about most. - The test process is too expensive for many low-end devices that would be very useful in USGovt offices. - The system introduces silly modes that make the systems more complicated. These are the top complaints I hear from both large and small vendors. There are certainly others. "Oh, don't get me started" is commonly heard when discussing FIPS 140 testing. > Compared to other security evaluation criteria, e.g. CC or the old >Organge Book, most security folks I know view the FIPS 140 >evaluation program as well managed and not very onerous. "Security folks" are not good evaluators on how some processes affect the market. >Also, if buyers believe that a device that "could be evaluated" is >good enough, they are being rather naive. Maybe. If a buyer cares about "does this box support the needed crypto in an interoperable fashion", then the perception is fine. If they care about all the details that FIPS 140 testing covers, then of course it is naive. >Experience with the FIPS 140 program has shown that a significant >fraction of of products submitted for evaluation fail the process. This statement is usually bandied about without any quantification of what failures were found, as it is here. As someone who creates test suites, I can assure you that I can make a few picky rules for systems that would cause some of those systems to fail, but most end users who understood those few rules would say that those rules were silly. Of course, different end users have different requirements. It is generally felt by vendors that some/many of the rules for FIPS 140 are silly and unneeded; on the other hand, it is likely that at least a few USGovt customers would really want some of those rules for particular reasons. >Presumably a vendor submitting a product for evaluation believes >that the product is ready, and will pass, otherwise the vendor is >wasting money on the evaluation effort. Wrong, very wrong. You cannot tell what the testing agency might try to knock you down on ahead of time. Of course, you cover what you can, but you also know that there is a good chance they'll just whack you a bit because it makes them look good. >The fact that many products fail evaluation (for good security >reasons), tells me that a vendor's claim that a product "could be >evaluated" is not much of an assurance. If you believe in the testing regime, that's fine. Others don't, and I believe for very good reasons in their own use scenarios. --Paul Hoffman, Director --VPN Consortium From paul.hoffman@vpnc.org Tue Feb 19 13:05:07 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JI5774017621 for ; Tue, 19 Feb 2008 13:05:07 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JI4uI2023267 for ; Tue, 19 Feb 2008 13:04:57 -0500 (EST) Received: from balder-227.proper.com (Balder-227.Proper.COM [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 7617DDA0F82 for ; Tue, 19 Feb 2008 13:04:35 -0500 (EST) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JI4Fjl086137 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 11:04:18 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> Date: Tue, 19 Feb 2008 10:04:12 -0800 To: "Santosh Chokhani" , "Stephen Kent" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 18:05:07 -0000 At 11:49 AM -0500 2/19/08, Santosh Chokhani wrote: >On the issue of restart, that is misunderstanding on Paul's part. There >is no restart. Ahem. I am reporting what the members of VPNC report to me. They are the vendors in the testing, not me. I have heard this from multiple vendors. If I was not clear that I was reporting what others said, I apologize. >Generally, problem is fixed and you pick up that point. Not to be too picky, but how can you say "generally" without seeing every test that was stopped? Maybe you have not had this problem, but others say they have. >Subjective tests seems to be misunderstanding on Paul's part. Having >been in the Orange Book, CC and FIPS process, I as validator, tester, >and certifier as well as vendor generally rue about rigidness of the >standard and lack of subjective judgment on the part of the tester or >lack of subjective latitude to vendors. If you, as a tester, feel that there are no subjective parts of the test process, that's fine. Some/many people who are being tested disagree with you. >FIPS 140 has specific guidelines on how to deal with minor incremental >changes that helps reduce cost and calendar time. Great! It does not seem to have gotten through to the vendors themselves as "inexpensive enough" or "fast enough". As a tester, you may have a different view. >The standard is NOT a protocol standard. It does verify the algorithm >implementations and thus, FIPS validated algorithms can interoperate. Quite true. >In terms of low end devices, 20-30K for level 1 testing amortized over >devices does not seem too onerous. ...to you. Others disagree, both on the financial cost, and particularly on the cost of elapsed time before customers can use the latest release from a vendor. >I do not understand what Paul refers to as silly modes. The module >being FIPS validated must use FIPS validated or recognized algorithms >for a given crypto service. That seems like a good thing to me. That is a good thing; it is also not what I was talking about. There is disagreement about what needs to be in a "FIPS mode", and whether the shipped product needs to allow "FIPS mode" to be enabled, and if so, how. Again: I am reporting what I hear from many VPNC members over many years. You as a single vendor and/or tester might feel differently; your feeling does not invalidate the views of others. --Paul Hoffman, Director --VPN Consortium From lloyd@randombit.net Tue Feb 19 13:10:45 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JIAjIC019859 for ; Tue, 19 Feb 2008 13:10:45 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JI9iqK002398 for ; Tue, 19 Feb 2008 13:09:44 -0500 (EST) Received: from mail.randombit.net (lain.randombit.net [66.179.181.40]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 90BEAF7263F for ; Tue, 19 Feb 2008 13:09:22 -0500 (EST) Received: by mail.randombit.net (Postfix, from userid 501) id 2BB153B60F7; Tue, 19 Feb 2008 13:09:24 -0500 (EST) Date: Tue, 19 Feb 2008 13:09:24 -0500 From: Jack Lloyd To: saag@mit.edu Message-ID: <20080219180923.GE7163@randombit.net> Mail-Followup-To: saag@mit.edu References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: 3F69 2E64 6D92 3BBE E7AE 9258 5C0F 96E8 4EC1 6D6B X-PGP-Key: http://www.randombit.net/pgpkey.html User-Agent: Mutt/1.5.11 X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 18:10:45 -0000 On Tue, Feb 19, 2008 at 08:18:24AM -0800, Paul Hoffman wrote: > - Some of the tests are fairly subjective, and it becomes a game of > fixing code to please the testing service, not to make the product > more secure. [...] > - The system introduces silly modes that make the systems more complicated. I have no experience with the purchasing side, but in my experience doing FIPS 140 validations, we often had to ask vendors to include hooks for testing that, from any objective standpoint, made the system less secure. And because the tests must be made on the same firmware/software as the as-shipped one (not in a special test/debug mode), that increased the attack surface of some of these devices greatly. I will fondly remember the validation where I found several exploitable buffer overflows in an HSM that had already passed two previous validations - all the holes were found in the hooks used for FIPS-140 testing. The tests that require the RNG be able to seeded with fixed data always seeemed particularly troublesome/dangerous to me. Obvious disclaimer: Anecdotes are not data - I just thought a relatively concrete example might be relevant to the discussion at hand. -Jack From paul.hoffman@vpnc.org Tue Feb 19 13:52:13 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JIqDI1004439 for ; Tue, 19 Feb 2008 13:52:13 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JIq3ck024805 for ; Tue, 19 Feb 2008 13:52:03 -0500 (EST) Received: from balder-227.proper.com (balder-227.proper.com [192.245.12.227]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id BE9D777702A for ; Tue, 19 Feb 2008 13:51:58 -0500 (EST) Received: from [10.20.30.152] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JIpnJm092659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 19 Feb 2008 11:51:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> Date: Tue, 19 Feb 2008 10:51:46 -0800 To: saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 18:52:13 -0000 At 1:13 PM -0500 2/19/08, Santosh Chokhani wrote: >My general observation is that vendors do not assign their engineers to >these efforts and there is a dearth of qualified testers, resulting in >blind leading the blind. That is a fairly damning criticism of the process, of course. It would not be bad if this were a voluntary logo program like VPNC or ICSA Labs has; when it prevents a large customer (many large customers, according to Ran) from buying up-to-date equipment that meets their security needs, it has serious implications for the security of the purchasers. --Paul Hoffman, Director --VPN Consortium From mcgrew@cisco.com Tue Feb 19 14:28:28 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JJSS3R019263 for ; Tue, 19 Feb 2008 14:28:28 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1JJSF01001750 for ; Tue, 19 Feb 2008 14:28:15 -0500 (EST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by mit.edu (Spam Firewall) with ESMTP id C7F2D791B3B for ; Tue, 19 Feb 2008 14:27:51 -0500 (EST) Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2008 14:27:50 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id m1JJRnb6027750; Tue, 19 Feb 2008 14:27:49 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1JJRiSE013583; Tue, 19 Feb 2008 19:27:44 GMT Received: from xmb-rtp-20c.amer.cisco.com ([64.102.31.57]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 19 Feb 2008 14:27:34 -0500 Received: from 10.32.254.212 ([10.32.254.212]) by xmb-rtp-20c.amer.cisco.com ([64.102.31.57]) with Microsoft Exchange Server HTTP-DAV ; Tue, 19 Feb 2008 19:27:34 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Tue, 19 Feb 2008 11:27:32 -0800 From: mcgrew To: Randall Atkinson , "saag@mit.edu" Message-ID: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: AQHIcPWoS7HEfANh0kyQUz3uBqgcnI1VeQZu In-Reply-To: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 19 Feb 2008 19:27:34.0421 (UTC) FILETIME=[7A64D450:01C8732D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2428; t=1203449269; x=1204313269; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20mcgrew=20 |Subject:=20Re=3A=20[saag]=20Algorithms/modes=20requested=2 0by=20users/customers |Sender:=20 |To:=20Randall=20Atkinson=20,=20=2 2saag@mit.edu=22=20; bh=0MBqj5sFQpqZo1/VEcLy6U1y74b27MLKWLdbp1zPFoA=; b=SlaR3FsFzAWRnJLOnLawvYcusMednwmngpsHR299jfhrMPII2in4cMG2sD gsGFT0sV3c4DN5hzm+IH0HRNpPrwY/dd+f/NFbDaV5oNQPQxqEGrZS8rXcRN Xscz7RA7mD; Authentication-Results: rtp-dkim-2; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 19:28:28 -0000 Hi Ran, Winston Churchill said that democracy is the worst form of government, except for all of the others. I think that the same is true for the FIPS-140 cryptomodule validation process ;-) I agree with you that there is good value in having open specs for FIPS-140 and Suite-B versions of Internet protocols (even though I also agree with many of the criticisms of the validation process made on this thread). I expect that the choice of which algorithm(s) should be mandatory-to-implement will continue to be made on the basis of technical (well, mostly technical) discussions in the WGs. Best, David On 2/16/08 3:42 PM, "Randall Atkinson" wrote: > Earlier, someone said: > % I think it would help enormously if we had some sort of > % cross IETF statement of the set of algorithms that are > % currently the consensus recommendations for support. > > I will answer a slightly different question. For the question: > "What algorithms/modes are most paying customers asking for ?" > the answers turn out to be: > > 1) NIST FIPS-140 conforming algorithms/modes. > and > 2) Suite-B conforming algorithms/modes. > > Approximately speaking, (2) above is a subset of (1) above. > > The IETF might make some different decision than those, > but equipment vendors will have to implement (1) or (2) > to please most commercial users (e.g. banks, insurance firms, > stock brokerages/markets, top international commercial > firms in other areas). So whether or not these are specified > by IETF on the standards-track, there is interoperability value > in having open specifications (e.g. Informational RFC would > do quite nicely) for (1) and (2) for nearly any Internet-related > protocol using cryptography. > > This seems to be driven externally by insurance firms that tell > their customers to only use equipment whose cryptographic > subsystems/modules have been (or are going to be) evaluated > formally under FIPS-140. > > And I'll note that this are not really driven particularly by US firms. > European, Asia/Pacific, and Latin American firms are making the > exact same requests for FIPS-140 of their equipment vendors. > > Yours, > > Ran > rja@extremenetworks.com > > > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag From kent@bbn.com Tue Feb 19 17:35:47 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JMZlVo030923 for ; Tue, 19 Feb 2008 17:35:47 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1JMZbm1022094 for ; Tue, 19 Feb 2008 17:35:37 -0500 (EST) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by mit.edu (Spam Firewall) with ESMTP id 32200DDC1FE for ; Tue, 19 Feb 2008 17:35:16 -0500 (EST) Received: from col-dhcp33-244-170.bbn.com ([128.33.244.170]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JRb3T-0000VO-4g; Tue, 19 Feb 2008 17:35:15 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks . com> Date: Tue, 19 Feb 2008 17:35:18 -0500 To: Paul Hoffman From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: "saag@mit.edu" , Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 22:35:48 -0000 At 8:18 AM -0800 2/19/08, Paul Hoffman wrote: >At 10:15 AM -0500 2/19/08, Stephen Kent wrote: >>Can you share the reasons cited by vendors to support the notion >>that the FIPS 140 process is broken. > >Sure. > >- It takes way too long from submission of system to validation, >even if no problems are found. I have gone through a level 3 eval and compared to ALL other security criteria evaluations, the time to perform the eval is much, much better. So, my guess is that anyone complaining about this has no experience with evals for things like CC. >- If problems are found during evaluation, the restart time is too long. ibid. >- Some of the tests are fairly subjective, and it becomes a game of >fixing code to please the testing service, not to make the product >more secure. It is true that some test criteria are not completely cut and dried. That is a problem with every one of these secruity eval criteria. My experience is that FIPS 40 is better i this regard than all the others. >- An evaluated product cannot have its core firmware updated without >losing the validation. For example, if a customer asks for a new >feature that might touch the crypto, the vendor has to choose >between losing the validation (and paying for a new one, and waiting >for the results) or keeping the customer happy. Absolutely right, and it should be that way! To expect otherwise is to fail to understand what a security eval is al about. However, the representation above is silly. The old product with the old feature set is still validated. It's the new version that cannot yet be sold as evaluated. When we had a level 3 device, we also sold a version that was not yet evaluated, but had nifty new features, and explained the situation to clients, some of who opted for the old version until the new version was evaluated. >- The validation doesn't even check for on-the-wire >interoperability, which is what the customers care about most. It's a crypto security eval criteria, not a protocol compliance eval criteria. The labs are not testers of IPsec or TLS; they are testers of crypto module functions, period. a buyer who doesn't understand that is misinformed. >- The test process is too expensive for many low-end devices that >would be very useful in USGovt offices. > >- The system introduces silly modes that make the systems more complicated. e.g., ? >These are the top complaints I hear from both large and small >vendors. There are certainly others. "Oh, don't get me started" is >commonly heard when discussing FIPS 140 testing. Whiners :-). >> Compared to other security evaluation criteria, e.g. CC or the >>old Organge Book, most security folks I know view the FIPS 140 >>evaluation program as well managed and not very onerous. > >"Security folks" are not good evaluators on how some processes >affect the market. But we are experienced with various security eval criteria, and one ought to judge such criteria in context. In that context FIPS 140 is viewed as having a great track record. > >>Also, if buyers believe that a device that "could be evaluated" is >>good enough, they are being rather naive. > >Maybe. If a buyer cares about "does this box support the needed >crypto in an interoperable fashion", then the perception is fine. If >they care about all the details that FIPS 140 testing covers, then >of course it is naive. Your statement seems to conflate two very separate issues. if a buyer is concerned primarily with interoperability or (non-crypto) standards compliance, then FIPS 140 is irrelevant. if they care about whether a product that purports to use crypto for security does so securely, then FIPS 140 eval is a solid prerequisite. I think a client who cares more about interoperability of a crypto-based security product than the security of the product is naive. > >>Experience with the FIPS 140 program has shown that a significant >>fraction of of products submitted for evaluation fail the process. > >This statement is usually bandied about without any quantification >of what failures were found, as it is here. As someone who creates >test suites, I can assure you that I can make a few picky rules for >systems that would cause some of those systems to fail, but most end >users who understood those few rules would say that those rules were >silly. Of course, different end users have different requirements. >It is generally felt by vendors that some/many of the rules for FIPS >140 are silly and unneeded; on the other hand, it is likely that at >least a few USGovt customers would really want some of those rules >for particular reasons. I have served several terms on an committee operated by the National Academy of Sciences that provides an external review for the NIST Security Lab. In our review meetings I have seen the figures for the pas/fail rate, and have seen descriptions of the reasons for failures, some of which are hilariously bad. I is not only US Givernment clients who care about most of the "picky rules." The banking community has mandated FIPS evaluation for years. However, if a client is more concerned about the performance of a VPN appliance than the security of the device, FIPS 140 is not a good criteria for that client. > >>Presumably a vendor submitting a product for evaluation believes >>that the product is ready, and will pass, otherwise the vendor is >>wasting money on the evaluation effort. > >Wrong, very wrong. You cannot tell what the testing agency might try >to knock you down on ahead of time. Of course, you cover what you >can, but you also know that there is a good chance they'll just >whack you a bit because it makes them look good. Nonsense, utter nonsense (says the guy who went trough this process, as opposed to the guy who is relating what he has been told by others). The criteria are complemented by guidelines for eval labs, and these guidelines are available to vendors. So, a smart vendor would study the criteria and the guidelines before designing a product that will be evaluated. A smart vendor will discuss the criteria with the lad it chooses, to minimize uncertainty. >>The fact that many products fail evaluation (for good security >>reasons), tells me that a vendor's claim that a product "could be >>evaluated" is not much of an assurance. > >If you believe in the testing regime, that's fine. Others don't, and >I believe for very good reasons in their own use scenarios. What I said is true, irrespective of whether one believes in the criteria or the testing methodology. The reality is the products fail, and many (not all) of the failures are demonstrably due to serious security problems. So, given this experience, one really ought not believe a vendor (whose goal is to sell products) who says "oh yeah, our product would pass evaluation, but we don't think it's worth the investment." A client who believes this argument should buy a used car without a warranty or an inspection by a mechanic. The likelihood of a good outcome is similar. Steve From jon@callas.org Tue Feb 19 19:10:22 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1K0ALKU001620 for ; Tue, 19 Feb 2008 19:10:21 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1K0ABQ1007001 for ; Tue, 19 Feb 2008 19:10:11 -0500 (EST) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by mit.edu (Spam Firewall) with ESMTP id 5014B77B2AF for ; Tue, 19 Feb 2008 19:10:09 -0500 (EST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id 33D39CCE529 for ; Tue, 19 Feb 2008 16:10:09 -0800 (PST) Received: from [192.168.16.100] ([12.37.185.170]) by keys.merrymeet.com (PGP Universal service); Tue, 19 Feb 2008 16:10:09 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Tue, 19 Feb 2008 16:10:09 -0800 Message-Id: <57147A59-BFAE-4F55-AE28-C653EB7475D1@callas.org> From: Jon Callas To: saag@mit.edu In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Tue, 19 Feb 2008 16:10:06 -0800 References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 00:10:22 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At 1:13 PM -0500 2/19/08, Santosh Chokhani wrote: > My general observation is that vendors do not assign their engineers > to > these efforts and there is a dearth of qualified testers, resulting in > blind leading the blind. I want to agree with Paul Hoffman that FIPS 140 is unnecessarily painful. I think I will also agree with Stephen Kent and say that FIPS is to CC as laparoscopic surgery is to open heart. Santosh also gets a big +1 from me, and I'll tell how even this dark cloud has a silver lining. When PGP first went through FIPS 140, we assigned a dedicated engineer to the process. Shepherding software through FIPS 140 was so painful, so mind-numbing, so annoying that he quit the company, quit cryptography, and quit computer security altogether. He took a job with a company that produced MP3 music software. That company was bought out by Apple, and the software turned into what we now know as iTunes. He is at Apple to this day as the lead of iTunes. So the next time you listen to an iPod, think about FIPS 140, and thank the horrible process. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHu2/hsTedWZOD3gYRAuZbAJ9IFEWuafL6fAB+2MxJvwIEOmLJiACgkJrs eRur6xWa+w6FdH022GobtDg= =ZTOd -----END PGP SIGNATURE----- From pgut001@cs.auckland.ac.nz Wed Feb 20 06:16:38 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KBGc6k013104 for ; Wed, 20 Feb 2008 06:16:38 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1KBGPwa005987 for ; Wed, 20 Feb 2008 06:16:28 -0500 (EST) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by mit.edu (Spam Firewall) with ESMTP id 4DF87CCDCC7 for ; Wed, 20 Feb 2008 06:16:03 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 7D64A4806FF; Thu, 21 Feb 2008 00:16:01 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ-TTEyFaCRj; Thu, 21 Feb 2008 00:16:01 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 1A349480425; Thu, 21 Feb 2008 00:16:00 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id DFF1AE080BD; Thu, 21 Feb 2008 00:15:56 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JRmvc-0007T0-QF; Thu, 21 Feb 2008 00:15:56 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: kent@bbn.com, paul.hoffman@vpnc.org In-Reply-To: Message-Id: Sender: pgut001 Date: Thu, 21 Feb 2008 00:15:56 +1300 X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, rja@extremenetworks.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 11:16:39 -0000 Paul Hoffman writes: Some quick notes on the consequences of three of these which may not be immediately obvious: >- It takes way too long from submission of system to validation, even if no >problems are found. Corollary: Users have the option of running a current, up-to-date non- evaluated version or an obsolete evaluated version. This becomes particularly critical if there's a security advisory issued for the old version, because you can't close the hole without losing the eval. So you get the choice of running an insecure FIPS 140-blessed version or a secure (well, as far as anyone knows) non-FIPS 140-blessed version. For some reason this doesn't seem to go down well with customers. >- Some of the tests are fairly subjective, and it becomes a game of fixing >code to please the testing service, not to make the product more secure. Corollary: You can get completely different results depending on how you submit your product, and who to, and when. I've heard of vendors doing the equivalent of jury-shopping in order to ease the evaluation process. >- The validation doesn't even check for on-the-wire interoperability, which >is what the customers care about most. Corollary: An ability to perform a TLS connect to Amazon (if the product is in this case a TLS crypto system) tells the customer more than the FIPS 140 eval ever can, since much of the TLS functionality is orthogonal to what FIPS 140 tests. >"Oh, don't get me started" is commonly heard when discussing FIPS 140 >testing. That's why I've tried to keep out of this so far :-). Ask enough people and you can get a very long list. This and CC do make for good conversation starters among security geeks though. Peter. From pgut001@cs.auckland.ac.nz Wed Feb 20 06:37:16 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KBbG1G018564 for ; Wed, 20 Feb 2008 06:37:16 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1KBb42v005458 for ; Wed, 20 Feb 2008 06:37:05 -0500 (EST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by mit.edu (Spam Firewall) with ESMTP id 955DCFC05B4 for ; Wed, 20 Feb 2008 06:36:43 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 991349C78D; Thu, 21 Feb 2008 00:36:40 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0dc7iktaQ4nY; Thu, 21 Feb 2008 00:36:40 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id E26249C78B; Thu, 21 Feb 2008 00:36:39 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2A993E080BD; Thu, 21 Feb 2008 00:36:39 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JRnFf-0008Uw-1D; Thu, 21 Feb 2008 00:36:39 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: mcgrew@cisco.com, rja@extremenetworks.com, saag@mit.edu In-Reply-To: Message-Id: Sender: pgut001 Date: Thu, 21 Feb 2008 00:36:39 +1300 X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 11:37:16 -0000 mcgrew writes: >Winston Churchill said that democracy is the worst form of government, except >for all of the others. I think that the same is true for the FIPS-140 >cryptomodule validation process ;-) I think it's more a case of the Politician's Fallacy: 1. Something must be done. 2. This is something. 3. This must be done. It'd be interesting to see a study of the effectiveness in terms of finding security and interop problems of: A. A FIPS 140 eval. B. Running the code through Fortify/Coverity/whatever and completing a crypto exchange with a peer (TLS, S/MIME, PGP, whatever the underlying crypto is that's being used). in particular in terms of return for effort-involved. Peter. From smb@cs.columbia.edu Wed Feb 20 08:13:18 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KDDG8B021254 for ; Wed, 20 Feb 2008 08:13:17 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1KDD5PF015636 for ; Wed, 20 Feb 2008 08:13:05 -0500 (EST) Received: from machshav.com (machshav.com [198.180.150.44]) by mit.edu (Spam Firewall) with ESMTP id F3E836B5DA5 for ; Wed, 20 Feb 2008 08:10:50 -0500 (EST) Received: by machshav.com (Postfix, from userid 512) id 9907F65E; Wed, 20 Feb 2008 13:10:50 +0000 (GMT) Received: from yellowstone.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id ECE1D15F; Wed, 20 Feb 2008 13:10:49 +0000 (GMT) Received: from cs.columbia.edu (localhost [127.0.0.1]) by yellowstone.machshav.com (Postfix) with ESMTP id E7075282CFE; Wed, 20 Feb 2008 08:10:48 -0500 (EST) Date: Wed, 20 Feb 2008 13:10:48 +0000 From: "Steven M. Bellovin" To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Message-ID: <20080220131048.55faab0b@cs.columbia.edu> In-Reply-To: References: Organization: Columbia University X-Mailer: Claws Mail 3.2.0 (GTK+ 2.12.5; x86_64--netbsd) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.41 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, rja@extremenetworks.com, mcgrew@cisco.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 13:13:18 -0000 On Thu, 21 Feb 2008 00:36:39 +1300 pgut001@cs.auckland.ac.nz (Peter Gutmann) wrote: > mcgrew writes: > > >Winston Churchill said that democracy is the worst form of > >government, except for all of the others. I think that the same is > >true for the FIPS-140 cryptomodule validation process ;-) > > I think it's more a case of the Politician's Fallacy: > > 1. Something must be done. > 2. This is something. > 3. This must be done. > > It'd be interesting to see a study of the effectiveness in terms of > finding security and interop problems of: > > A. A FIPS 140 eval. > > B. Running the code through Fortify/Coverity/whatever and completing > a crypto exchange with a peer (TLS, S/MIME, PGP, whatever the > underlying crypto is that's being used). > > in particular in terms of return for effort-involved. Right. But here's the problem with this choice: FIPS-140 is mostly about assurance of security, and not just correctness of the crypto. Given the really bad mistakes we've all seen -- things that would be caught by any decent outside evaluation -- what is the alternative? What is the *assurance* a customer has that the product is adequately secured? --Steve Bellovin, http://www.cs.columbia.edu/~smb From pgut001@cs.auckland.ac.nz Wed Feb 20 08:51:20 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KDpKrF005230 for ; Wed, 20 Feb 2008 08:51:20 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KDp9AR026495 for ; Wed, 20 Feb 2008 08:51:09 -0500 (EST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by mit.edu (Spam Firewall) with ESMTP id 2F3A4D66C28 for ; Wed, 20 Feb 2008 08:50:47 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 508FD9C78E; Thu, 21 Feb 2008 02:50:46 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sClDQVRjcD-U; Thu, 21 Feb 2008 02:50:46 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 4A4CA9C783; Thu, 21 Feb 2008 02:50:45 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C569219EC0B7; Thu, 21 Feb 2008 02:50:42 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JRpLO-0006MQ-Lc; Thu, 21 Feb 2008 02:50:42 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, smb@cs.columbia.edu In-Reply-To: <20080220131048.55faab0b@cs.columbia.edu> Message-Id: Sender: pgut001 Date: Thu, 21 Feb 2008 02:50:42 +1300 X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, rja@extremenetworks.com, mcgrew@cisco.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 13:51:20 -0000 "Steven M. Bellovin" writes: >FIPS-140 is mostly about assurance of security, and not just correctness of >the crypto. Is it about assurance of security, or assurance of production of paperwork showing the certification conditions have been met? There have been plenty of security advisories issued for CC and FIPS-140 evaluated products (and even more not publicised but silently fixed in a certification-voiding manner). >Given the really bad mistakes we've all seen -- things that would be caught >by any decent outside evaluation -- what is the alternative? What is the >*assurance* a customer has that the product is adequately secured? Politician's Fallacy again: Is FIPS 140 really the best way to spend your money? If FIPS 140 is the answer now, why wasn't the Orange Book the answer then? What about giving the money to (picking a random name) Cigital and saying "make sure this code is OK"? What about giving the money to Dan Bernstein and saying "implement this and make it secure"? What about having the code written by Germans and pen-tested by the French? [0]. We have no hard data either way (although I'd put my money on Cigital and Dan to produce the more secure product :-). But simply saying "We must use FIPS 140... just... well, just because!" is hardly a scientific approach to solving the problem. Peter. [0] A very much under-exploited strategy in security evaluation. From SChokhani@cygnacom.com Tue Feb 19 11:50:27 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JGoQrw015899 for ; Tue, 19 Feb 2008 11:50:26 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JGoGki015630 for ; Tue, 19 Feb 2008 11:50:17 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 08DE9CD4D90 for ; Tue, 19 Feb 2008 11:49:55 -0500 (EST) Received: (qmail 2626 invoked from network); 19 Feb 2008 16:42:22 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 19 Feb 2008 16:42:22 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 19 Feb 2008 16:42:22 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 19 Feb 2008 11:49:53 -0500 Message-ID: in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: AchzFO3PhWGkWHRDTSG0q9i/xNMp9gAAJGnw References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> From: "Santosh Chokhani" To: "Paul Hoffman" , "Stephen Kent" X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1JGoQrw015899 X-Mailman-Approved-At: Wed, 20 Feb 2008 10:05:23 -0500 Cc: saag@mit.edu, Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 16:50:27 -0000 On the issue of it takes too long, the FIPS process is the envy of other schemes. One could always be faster. On the issue of restart, that is misunderstanding on Paul's part. There is no restart. Generally, problem is fixed and you pick up that point. This is generally a vendor problem. Depending on the nature of problem/failure, other aspects of the testing can continue without loss of calendar time. Subjective tests seems to be misunderstanding on Paul's part. Having been in the Orange Book, CC and FIPS process, I as validator, tester, and certifier as well as vendor generally rue about rigidness of the standard and lack of subjective judgment on the part of the tester or lack of subjective latitude to vendors. FIPS 140 has specific guidelines on how to deal with minor incremental changes that helps reduce cost and calendar time. The standard is NOT a protocol standard. It does verify the algorithm implementations and thus, FIPS validated algorithms can interoperate. In terms of low end devices, 20-30K for level 1 testing amortized over devices does not seem too onerous. I do not understand what Paul refers to as silly modes. The module being FIPS validated must use FIPS validated or recognized algorithms for a given crypto service. That seems like a good thing to me. -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Paul Hoffman Sent: Tuesday, February 19, 2008 11:18 AM To: Stephen Kent Cc: saag@mit.edu; Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers At 10:15 AM -0500 2/19/08, Stephen Kent wrote: >Can you share the reasons cited by vendors to support the notion >that the FIPS 140 process is broken. Sure. - It takes way too long from submission of system to validation, even if no problems are found. - If problems are found during evaluation, the restart time is too long. - Some of the tests are fairly subjective, and it becomes a game of fixing code to please the testing service, not to make the product more secure. - An evaluated product cannot have its core firmware updated without losing the validation. For example, if a customer asks for a new feature that might touch the crypto, the vendor has to choose between losing the validation (and paying for a new one, and waiting for the results) or keeping the customer happy. - The validation doesn't even check for on-the-wire interoperability, which is what the customers care about most. - The test process is too expensive for many low-end devices that would be very useful in USGovt offices. - The system introduces silly modes that make the systems more complicated. These are the top complaints I hear from both large and small vendors. There are certainly others. "Oh, don't get me started" is commonly heard when discussing FIPS 140 testing. > Compared to other security evaluation criteria, e.g. CC or the old >Organge Book, most security folks I know view the FIPS 140 >evaluation program as well managed and not very onerous. "Security folks" are not good evaluators on how some processes affect the market. >Also, if buyers believe that a device that "could be evaluated" is >good enough, they are being rather naive. Maybe. If a buyer cares about "does this box support the needed crypto in an interoperable fashion", then the perception is fine. If they care about all the details that FIPS 140 testing covers, then of course it is naive. >Experience with the FIPS 140 program has shown that a significant >fraction of of products submitted for evaluation fail the process. This statement is usually bandied about without any quantification of what failures were found, as it is here. As someone who creates test suites, I can assure you that I can make a few picky rules for systems that would cause some of those systems to fail, but most end users who understood those few rules would say that those rules were silly. Of course, different end users have different requirements. It is generally felt by vendors that some/many of the rules for FIPS 140 are silly and unneeded; on the other hand, it is likely that at least a few USGovt customers would really want some of those rules for particular reasons. >Presumably a vendor submitting a product for evaluation believes >that the product is ready, and will pass, otherwise the vendor is >wasting money on the evaluation effort. Wrong, very wrong. You cannot tell what the testing agency might try to knock you down on ahead of time. Of course, you cover what you can, but you also know that there is a good chance they'll just whack you a bit because it makes them look good. >The fact that many products fail evaluation (for good security >reasons), tells me that a vendor's claim that a product "could be >evaluated" is not much of an assurance. If you believe in the testing regime, that's fine. Others don't, and I believe for very good reasons in their own use scenarios. --Paul Hoffman, Director --VPN Consortium _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag From SChokhani@cygnacom.com Tue Feb 19 13:16:27 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1JIGRkf021471 for ; Tue, 19 Feb 2008 13:16:27 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1JIGHED013637 for ; Tue, 19 Feb 2008 13:16:17 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id D68867913AC for ; Tue, 19 Feb 2008 13:13:08 -0500 (EST) Received: (qmail 3499 invoked from network); 19 Feb 2008 18:05:36 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 19 Feb 2008 18:05:36 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 19 Feb 2008 18:05:36 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 19 Feb 2008 13:13:06 -0500 Message-ID: in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: AchzIeEnGWfnkW1lSVWs0LiLJakuowAAGwGw References: <8329C86009B2F24493D76B486146769A9429B7A8@USEXCHANGE.corp.extremenetworks. com> From: "Santosh Chokhani" To: "Paul Hoffman" , "Stephen Kent" X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1JIGRkf021471 X-Mailman-Approved-At: Wed, 20 Feb 2008 10:05:23 -0500 Cc: saag@mit.edu, Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2008 18:16:27 -0000 Paul, These statements are not based on "feelings". They are based on experience of doing third party testing such as TPEP (TCSEC), TTAP (TCSEC and CC), CC testing and FIPS since 1987 and being involved in the FIPS program since its pre-formative days. If there are specific concerns, I would be happy to look into those. My general observation is that vendors do not assign their engineers to these efforts and there is a dearth of qualified testers, resulting in blind leading the blind. If you get a good tester, he/she will force the vendor to provide a good engineering answer and many of the general issues you are mentioning will get tackled right. I would recommend that VPNC members/vendors have good engineers making sound arguments. Most of the times, that works. -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Tuesday, February 19, 2008 1:04 PM To: Santosh Chokhani; Stephen Kent Cc: saag@mit.edu; Randall Atkinson Subject: RE: [saag] Algorithms/modes requested by users/customers At 11:49 AM -0500 2/19/08, Santosh Chokhani wrote: >On the issue of restart, that is misunderstanding on Paul's part. There >is no restart. Ahem. I am reporting what the members of VPNC report to me. They are the vendors in the testing, not me. I have heard this from multiple vendors. If I was not clear that I was reporting what others said, I apologize. >Generally, problem is fixed and you pick up that point. Not to be too picky, but how can you say "generally" without seeing every test that was stopped? Maybe you have not had this problem, but others say they have. >Subjective tests seems to be misunderstanding on Paul's part. Having >been in the Orange Book, CC and FIPS process, I as validator, tester, >and certifier as well as vendor generally rue about rigidness of the >standard and lack of subjective judgment on the part of the tester or >lack of subjective latitude to vendors. If you, as a tester, feel that there are no subjective parts of the test process, that's fine. Some/many people who are being tested disagree with you. >FIPS 140 has specific guidelines on how to deal with minor incremental >changes that helps reduce cost and calendar time. Great! It does not seem to have gotten through to the vendors themselves as "inexpensive enough" or "fast enough". As a tester, you may have a different view. >The standard is NOT a protocol standard. It does verify the algorithm >implementations and thus, FIPS validated algorithms can interoperate. Quite true. >In terms of low end devices, 20-30K for level 1 testing amortized over >devices does not seem too onerous. ...to you. Others disagree, both on the financial cost, and particularly on the cost of elapsed time before customers can use the latest release from a vendor. >I do not understand what Paul refers to as silly modes. The module >being FIPS validated must use FIPS validated or recognized algorithms >for a given crypto service. That seems like a good thing to me. That is a good thing; it is also not what I was talking about. There is disagreement about what needs to be in a "FIPS mode", and whether the shipped product needs to allow "FIPS mode" to be enabled, and if so, how. Again: I am reporting what I hear from many VPNC members over many years. You as a single vendor and/or tester might feel differently; your feeling does not invalidate the views of others. --Paul Hoffman, Director --VPN Consortium From rja@extremenetworks.com Wed Feb 20 10:27:52 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KFRqDS009432 for ; Wed, 20 Feb 2008 10:27:52 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KFRg3e024056 for ; Wed, 20 Feb 2008 10:27:42 -0500 (EST) Received: from ussc-casht-p1.corp.extremenetworks.com (ussc-casht-p2.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 8CDAEFBB7BA for ; Wed, 20 Feb 2008 10:27:21 -0500 (EST) Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p1.corp.extremenetworks.com ([172.16.1.201]) with mapi; Wed, 20 Feb 2008 07:27:20 -0800 From: Randall Atkinson To: Peter Gutmann Date: Wed, 20 Feb 2008 07:27:19 -0800 Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Achzx5t1Z954WaFCTeK7vP5dTSWgTAADDiZ/ Message-ID: <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com> References: <20080220131048.55faab0b@cs.columbia.edu>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1KFRqDS009432 Cc: "saag@mit.edu" Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:27:52 -0000 Earlier, Peter Gutmann wrote: % Politician's Fallacy again: Is FIPS 140 really the best way to spend your % money? If someone has a better proposal, I am very sure that there is a large audience that would love to hear it. (More on this at bottom) % If FIPS 140 is the answer now, why wasn't the Orange Book % the answer then? You are comparing apples to oranges above. FIPS-140 is only about assurance for cryptographic modules. Orange Book (TCSEC) was only about operating system security. The two address different issues. % What about giving the money to (picking a random name) Cigital and % saying "make sure this code is OK"? One needs a process that is as consistent and reproducible as practical -- no human process could ever be 100% consistent and reprodcible -- otherwise implementers will legitimately complain about a non-level playing field. Or were you proposing to setup a monopoly ? FIPS-140 has multiple certification labs in multiple countries evaluating products -- to avoid creating a monopoly. This HAS driven the evaluation costs downwards over time, and it permits implementers the choice to trade more money for less evaluation time. I don't think anyone has claimed FIPS-140 is perfect. The claims (not by me so much as by other folks on the SAAG list) have been that (1) FIPS-140 is better than other extant security evaluations and that (2) so far no serious alternative proposal that looks reasonably better has appeared. If you think that FIPS-140-* is a target-rich environment, then please try to seriously propose something better. I understand NIST and its partners are looking to evolve into FIPS 140-3 from FIPS 140-2. Have you sent them any concrete suggestions for improvement ? I know the folks at NIST are happy to listen to any serious inputs or proposals. Cheers, Ran From SChokhani@cygnacom.com Wed Feb 20 10:33:12 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KFXBhA011504 for ; Wed, 20 Feb 2008 10:33:11 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KFX3aG004148 for ; Wed, 20 Feb 2008 10:33:03 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 374A96D2856 for ; Wed, 20 Feb 2008 10:32:41 -0500 (EST) Received: (qmail 14473 invoked from network); 20 Feb 2008 15:25:07 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 20 Feb 2008 15:25:07 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 20 Feb 2008 15:25:07 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 20 Feb 2008 10:32:39 -0500 Message-ID: in-reply-to: <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Achzx5t1Z954WaFCTeK7vP5dTSWgTAADDiZ/AAB557A= References: <20080220131048.55faab0b@cs.columbia.edu>, <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com> From: "Santosh Chokhani" To: "Randall Atkinson" , "Peter Gutmann" X-Spam-Score: 0.14 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1KFXBhA011504 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:33:12 -0000 Orange Book was not about OS security alone. It was successfully applied to network components and DBMS systems also. -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Randall Atkinson Sent: Wednesday, February 20, 2008 10:27 AM To: Peter Gutmann Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers Earlier, Peter Gutmann wrote: % Politician's Fallacy again: Is FIPS 140 really the best way to spend your % money? If someone has a better proposal, I am very sure that there is a large audience that would love to hear it. (More on this at bottom) % If FIPS 140 is the answer now, why wasn't the Orange Book % the answer then? You are comparing apples to oranges above. FIPS-140 is only about assurance for cryptographic modules. Orange Book (TCSEC) was only about operating system security. The two address different issues. % What about giving the money to (picking a random name) Cigital and % saying "make sure this code is OK"? One needs a process that is as consistent and reproducible as practical -- no human process could ever be 100% consistent and reprodcible -- otherwise implementers will legitimately complain about a non-level playing field. Or were you proposing to setup a monopoly ? FIPS-140 has multiple certification labs in multiple countries evaluating products -- to avoid creating a monopoly. This HAS driven the evaluation costs downwards over time, and it permits implementers the choice to trade more money for less evaluation time. I don't think anyone has claimed FIPS-140 is perfect. The claims (not by me so much as by other folks on the SAAG list) have been that (1) FIPS-140 is better than other extant security evaluations and that (2) so far no serious alternative proposal that looks reasonably better has appeared. If you think that FIPS-140-* is a target-rich environment, then please try to seriously propose something better. I understand NIST and its partners are looking to evolve into FIPS 140-3 from FIPS 140-2. Have you sent them any concrete suggestions for improvement ? I know the folks at NIST are happy to listen to any serious inputs or proposals. Cheers, Ran _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag From rja@extremenetworks.com Wed Feb 20 10:40:32 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KFeWMw014306 for ; Wed, 20 Feb 2008 10:40:32 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KFeMYo017807 for ; Wed, 20 Feb 2008 10:40:22 -0500 (EST) Received: from ussc-casht-p2.corp.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 78297CE1F1E for ; Wed, 20 Feb 2008 10:40:01 -0500 (EST) Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p2.corp.extremenetworks.com ([10.255.181.88]) with mapi; Wed, 20 Feb 2008 07:40:00 -0800 From: Randall Atkinson To: Santosh Chokhani Date: Wed, 20 Feb 2008 07:39:59 -0800 Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Achzx5t1Z954WaFCTeK7vP5dTSWgTAADDiZ/AAB557AAAA5/gw== Message-ID: <8329C86009B2F24493D76B486146769A9596B151@USEXCHANGE.corp.extremenetworks.com> References: <20080220131048.55faab0b@cs.columbia.edu>, <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1KFeWMw014306 Cc: "saag@mit.edu" Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:40:32 -0000 Earlier, Santosh Chokhani wrote: % Orange Book was not about OS security alone. % % It was successfully applied to network components and DBMS systems also. Santosh, I was using terms precisely, not loosely. The network evaluations were done against Red Book (TNI) published as NCSC TG-005, and not against the Orange Book proper. DBMS evals were done against the Purple Book, published as NCSC TG-021, and not against the Orange Book proper. (I have a full set of colouring books to hand from a previous life. :-) Cheers, Ran From SChokhani@cygnacom.com Wed Feb 20 10:42:04 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KFg4T2014652 for ; Wed, 20 Feb 2008 10:42:04 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KFftpp020432 for ; Wed, 20 Feb 2008 10:41:55 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 200D5CC0EF1 for ; Wed, 20 Feb 2008 10:41:35 -0500 (EST) Received: (qmail 14563 invoked from network); 20 Feb 2008 15:34:01 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 20 Feb 2008 15:34:01 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 20 Feb 2008 15:34:01 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 20 Feb 2008 10:41:33 -0500 Message-ID: in-reply-to: <8329C86009B2F24493D76B486146769A9596B151@USEXCHANGE.corp.extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Achzx5t1Z954WaFCTeK7vP5dTSWgTAADDiZ/AAB557AAAA5/gwAAP6Lg References: <20080220131048.55faab0b@cs.columbia.edu>, <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com>, <8329C86009B2F24493D76B486146769A9596B151@USEXCHANGE.corp.extremenetworks.com> From: "Santosh Chokhani" To: "Randall Atkinson" X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1KFg4T2014652 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:42:04 -0000 The other books were no more than the interpretations so that we can reuse the standard. Except for TNI Part 2, the source document and requirement for rainbow series is TCSEC. -----Original Message----- From: Randall Atkinson [mailto:rja@extremenetworks.com] Sent: Wednesday, February 20, 2008 10:40 AM To: Santosh Chokhani Cc: saag@mit.edu Subject: RE: [saag] Algorithms/modes requested by users/customers Earlier, Santosh Chokhani wrote: % Orange Book was not about OS security alone. % % It was successfully applied to network components and DBMS systems also. Santosh, I was using terms precisely, not loosely. The network evaluations were done against Red Book (TNI) published as NCSC TG-005, and not against the Orange Book proper. DBMS evals were done against the Purple Book, published as NCSC TG-021, and not against the Orange Book proper. (I have a full set of colouring books to hand from a previous life. :-) Cheers, Ran From rja@extremenetworks.com Wed Feb 20 10:48:18 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KFmIkp016958 for ; Wed, 20 Feb 2008 10:48:18 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KFm8o5002132 for ; Wed, 20 Feb 2008 10:48:08 -0500 (EST) Received: from ussc-casht-p1.corp.extremenetworks.com (ussc-casht-p1.extremenetworks.com [207.179.9.62]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 3019D785562 for ; Wed, 20 Feb 2008 10:48:06 -0500 (EST) Received: from USEXCHANGE.corp.extremenetworks.com ([172.168.1.2]) by ussc-casht-p1.corp.extremenetworks.com ([172.16.1.201]) with mapi; Wed, 20 Feb 2008 07:48:05 -0800 From: Randall Atkinson To: Santosh Chokhani Date: Wed, 20 Feb 2008 07:45:13 -0800 Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Achzx5t1Z954WaFCTeK7vP5dTSWgTAADDiZ/AAB557AAAA5/gwAAP6LgAAAoK1E= Message-ID: <8329C86009B2F24493D76B486146769A9596B153@USEXCHANGE.corp.extremenetworks.com> References: <20080220131048.55faab0b@cs.columbia.edu>, <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com>, <8329C86009B2F24493D76B486146769A9596B151@USEXCHANGE.corp.extremenetworks.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1KFmIkp016958 Cc: "saag@mit.edu" Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:48:18 -0000 Earlier Santosh wrote: % The other books were no more than the interpretations so that we can % reuse the standard. % % Except for TNI Part 2, the source document and requirement for rainbow % series is TCSEC. So then you do agree with me, Network evals and DBMS evals used the other volumes that I cited, because the Orange book didn't really cover either networking or DBMS topics. I was involved in formal evaluations for the US DoD, while a DoD employee in a prior life, so I've got specific first hand experience with this topic. :-) Cheers, Ran From SChokhani@cygnacom.com Wed Feb 20 10:50:07 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KFo7CI017463 for ; Wed, 20 Feb 2008 10:50:07 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1KFnvWX009342 for ; Wed, 20 Feb 2008 10:49:58 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 6EF1EFA6312 for ; Wed, 20 Feb 2008 10:49:36 -0500 (EST) Received: (qmail 14626 invoked from network); 20 Feb 2008 15:42:03 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 20 Feb 2008 15:42:03 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 20 Feb 2008 15:42:02 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 20 Feb 2008 10:49:32 -0500 Message-ID: in-reply-to: <8329C86009B2F24493D76B486146769A9596B153@USEXCHANGE.corp.extremenetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Achzx5t1Z954WaFCTeK7vP5dTSWgTAADDiZ/AAB557AAAA5/gwAAP6LgAAAoK1EAAB+LoA== References: <20080220131048.55faab0b@cs.columbia.edu>, <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com>, <8329C86009B2F24493D76B486146769A9596B151@USEXCHANGE.corp.extremenetworks.com>, <8329C86009B2F24493D76B486146769A9596B153@USEXCHANGE.corp.extremenetworks.com> From: "Santosh Chokhani" To: "Randall Atkinson" X-Spam-Score: 0.02 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1KFo7CI017463 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 15:50:08 -0000 Folks like me when we had issues, we focused on pragmatics and the TCSEC and not the two interpretations you cite. -----Original Message----- From: Randall Atkinson [mailto:rja@extremenetworks.com] Sent: Wednesday, February 20, 2008 10:45 AM To: Santosh Chokhani Cc: saag@mit.edu Subject: RE: [saag] Algorithms/modes requested by users/customers Earlier Santosh wrote: % The other books were no more than the interpretations so that we can % reuse the standard. % % Except for TNI Part 2, the source document and requirement for rainbow % series is TCSEC. So then you do agree with me, Network evals and DBMS evals used the other volumes that I cited, because the Orange book didn't really cover either networking or DBMS topics. I was involved in formal evaluations for the US DoD, while a DoD employee in a prior life, so I've got specific first hand experience with this topic. :-) Cheers, Ran From jon@callas.org Wed Feb 20 11:54:44 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KGsiJD005324 for ; Wed, 20 Feb 2008 11:54:44 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1KGsY1w015637 for ; Wed, 20 Feb 2008 11:54:34 -0500 (EST) Received: from merrymeet.com (merrymeet.com [66.93.68.160]) by mit.edu (Spam Firewall) with ESMTP id E6230DE6589 for ; Wed, 20 Feb 2008 11:54:06 -0500 (EST) Received: from keys.merrymeet.com (keys.merrymeet.com [66.93.68.161]) (Authenticated sender: jon) by merrymeet.com (Postfix) with ESMTP id C856CCD34EB for ; Wed, 20 Feb 2008 08:54:05 -0800 (PST) Received: from [192.168.5.147] ([12.53.176.4]) by keys.merrymeet.com (PGP Universal service); Wed, 20 Feb 2008 08:54:05 -0800 X-PGP-Universal: processed; by keys.merrymeet.com on Wed, 20 Feb 2008 08:54:05 -0800 Message-Id: <71651A38-58E5-4575-9E05-E57A728623B0@callas.org> From: Jon Callas To: "Santosh Chokhani" In-Reply-To: Mime-Version: 1.0 (Apple Message framework v919.2) Date: Wed, 20 Feb 2008 08:54:00 -0800 References: <20080220131048.55faab0b@cs.columbia.edu>, <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com> X-Mailer: Apple Mail (2.919.2) X-PGP-Encoding-Format: Partitioned X-PGP-Encoding-Version: 2.0.2 X-Content-PGP-Universal-Saved-Content-Transfer-Encoding: 7bit X-Content-PGP-Universal-Saved-Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7BIT X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, Randall Atkinson Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 16:54:45 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I don't think anyone has claimed FIPS-140 is perfect. The claims (not > by > me so much as by other folks on the SAAG list) have been that (1) > FIPS-140 > is better than other extant security evaluations and that (2) so far > no serious alternative proposal that looks reasonably better has > appeared. I agree that both of these are true, but these true statements are not inconsistent with the complaints. A system can be the best available, as well as there being no "serious alternative" and still be inadequate. I think this is the true problem. I hope that we're not saying that FIPS 140 is the best of all possible systems. Jon -----BEGIN PGP SIGNATURE----- Version: PGP Universal 2.6.3 Charset: US-ASCII wj8DBQFHvFstsTedWZOD3gYRArNbAJ4m8Xr8xugA2UAOQ78ONt3Pkzi2QACgv7qR eLBNHoY54jxCur581CX8lgI= =139k -----END PGP SIGNATURE----- From kent@bbn.com Wed Feb 20 17:52:14 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1KMqAfK023292 for ; Wed, 20 Feb 2008 17:52:10 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1KMq0Mv013087 for ; Wed, 20 Feb 2008 17:52:00 -0500 (EST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu (Spam Firewall) with ESMTP id E26FCC4F75F for ; Wed, 20 Feb 2008 17:51:39 -0500 (EST) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JRxmt-0003lI-3R; Wed, 20 Feb 2008 17:51:39 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 20 Feb 2008 17:51:41 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, rja@extremenetworks.com, mcgrew@cisco.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Feb 2008 22:52:15 -0000 At 12:36 AM +1300 2/21/08, Peter Gutmann wrote: >mcgrew writes: > >>Winston Churchill said that democracy is the worst form of government, except >>for all of the others. I think that the same is true for the FIPS-140 >>cryptomodule validation process ;-) > >I think it's more a case of the Politician's Fallacy: > >1. Something must be done. >2. This is something. >3. This must be done. > >It'd be interesting to see a study of the effectiveness in terms of finding >security and interop problems of: since I and others have pointed out several times that FIPS 140 eval has nothing to do with protocol interoperability, the reference to "interoo" above must be viewed purely within the context of crypto algorithms and modes thereof. > >A. A FIPS 140 eval. > >B. Running the code through Fortify/Coverity/whatever and completing a crypto > exchange with a peer (TLS, S/MIME, PGP, whatever the underlying crypto is > that's being used). > >in particular in terms of return for effort-involved. > >Peter. FIPS 140 encompasses both hardware and software implementations of crypto modules. I see its greatest benefits in the context of the former. The process described above does not address hardware security module eval at all. Steve From mcgrew@cisco.com Thu Feb 21 10:01:10 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1LF19hP016915 for ; Thu, 21 Feb 2008 10:01:09 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1LF0wRc026509 for ; Thu, 21 Feb 2008 10:00:58 -0500 (EST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by mit.edu (Spam Firewall) with ESMTP id 7B36ACD6A31 for ; Thu, 21 Feb 2008 10:00:37 -0500 (EST) Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 21 Feb 2008 10:00:37 -0500 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m1LF0be3009783; Thu, 21 Feb 2008 10:00:37 -0500 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id m1LExtVG017362; Thu, 21 Feb 2008 15:00:36 GMT Received: from xmb-rtp-20c.amer.cisco.com ([64.102.31.57]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 10:00:33 -0500 Received: from 10.32.254.210 ([10.32.254.210]) by xmb-rtp-20c.amer.cisco.com ([64.102.31.57]) with Microsoft Exchange Server HTTP-DAV ; Thu, 21 Feb 2008 15:00:33 +0000 User-Agent: Microsoft-Entourage/11.2.4.060510 Date: Thu, 21 Feb 2008 07:00:32 -0800 From: mcgrew To: Peter Gutmann , , Message-ID: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Ach0moEcv2aO4uCNEdyLkQAUUQnMFg== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Feb 2008 15:00:33.0899 (UTC) FILETIME=[823EABB0:01C8749A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1072; t=1203606037; x=1204470037; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mcgrew@cisco.com; z=From:=20mcgrew=20 |Subject:=20Re=3A=20[saag]=20Algorithms/modes=20requested=2 0by=20users/customers |Sender:=20 |To:=20Peter=20Gutmann=20,=20,=0A=20=20=20=20=20=20=20=20; bh=oc51/+WI0v8ooyb5/ZHcG+BZnkqhVvCKGW+8Kl0DZWY=; b=Gnn9mS5kdms5a3pHl+2KN8WjqVdhgwo2VqT+lYSbCSA7+WMyYPGWqoPw4/ BuIX4Ls8Wezbl99zLeRHgjpGpNwwKYdsargwsKPOHJlOWBqL4hc0x087Hjz/ fdomtcKY9d; Authentication-Results: rtp-dkim-1; header.From=mcgrew@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.30 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Feb 2008 15:01:10 -0000 Hi Peter, On 2/20/08 3:36 AM, "Peter Gutmann" wrote: > mcgrew writes: > >> Winston Churchill said that democracy is the worst form of government, except >> for all of the others. I think that the same is true for the FIPS-140 >> cryptomodule validation process ;-) > > I think it's more a case of the Politician's Fallacy: > > 1. Something must be done. > 2. This is something. > 3. This must be done. > I like that. > It'd be interesting to see a study of the effectiveness in terms of finding > security and interop problems of: > > A. A FIPS 140 eval. > > B. Running the code through Fortify/Coverity/whatever and completing a crypto > exchange with a peer (TLS, S/MIME, PGP, whatever the underlying crypto is > that's being used). > > in particular in terms of return for effort-involved. > > Peter. I share you interest in the automation of validation testing; the more that can be automated, the better. It would be great to see more work in this area. David From vishwas.ietf@gmail.com Thu Feb 21 19:59:10 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1M0xAgt017851 for ; Thu, 21 Feb 2008 19:59:10 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1M0x2Z1029949 for ; Thu, 21 Feb 2008 19:59:03 -0500 (EST) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.168]) by mit.edu (Spam Firewall) with ESMTP id 48B17CD653B for ; Thu, 21 Feb 2008 19:59:02 -0500 (EST) Received: by ug-out-1314.google.com with SMTP id e2so1045125ugf.36 for ; Thu, 21 Feb 2008 16:59:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=+ZV8f3svxlezc2j2UlWrCZMKiARSUo9TJxrfDtlpRF8=; b=wmyhVV/koZt7I6VzX7bR73mAWkje9gVW42jnIX9ygvTWTqodywhGodls7Z1BOwZftLzv+AoeCQXq+p9oTOlQzSii4bLSURYG2ih+cfmAnU/PqURx9oLUI24+CDxar/eLRZQdvUPC6KwVW/r3bqK+foEUpwBHoufUxosUDp4wb8Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PEm/8Jp8PP+iw3048gdZTg3mxNd0uRU9n7vjh5rY0KWqw6gfYI1JCbhU3+IHtXTx2LSA597aYua5NzSiMLL6Y2veBAVXJK4VYFEWfGYlwWwIFj9ETHQ3Oz4Ymaogolrn+ZV6NhqXPHZ2E5QZA4RDdnqZKiPyyRd77P9PEhaWiNw= Received: by 10.142.100.1 with SMTP id x1mr8247112wfb.131.1203641940205; Thu, 21 Feb 2008 16:59:00 -0800 (PST) Received: by 10.143.164.14 with HTTP; Thu, 21 Feb 2008 16:59:00 -0800 (PST) Message-ID: <77ead0ec0802211659led5fe3axb7c8a1a27e190c1@mail.gmail.com> Date: Thu, 21 Feb 2008 16:59:00 -0800 From: "Vishwas Manral" To: "Jon Callas" In-Reply-To: <57147A59-BFAE-4F55-AE28-C653EB7475D1@callas.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <57147A59-BFAE-4F55-AE28-C653EB7475D1@callas.org> X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Feb 2008 00:59:10 -0000 Hi Jon, > When PGP first went through FIPS 140, we assigned a dedicated engineer > to the process. Shepherding software through FIPS 140 was so painful, > so mind-numbing, so annoying that he quit the company, quit > cryptography, and quit computer security altogether. He took a job > with a company that produced MP3 music software. That company was > bought out by Apple, and the software turned into what we now know as > iTunes. He is at Apple to this day as the lead of iTunes. > > So the next time you listen to an iPod, think about FIPS 140, and > thank the horrible process. Mind you, iTunes has its own DRM mechanism and that requires cryptography. I have in the past worked on DTCP-IP which is now the content protection mechanism in home devices (after DLNA adopted it) used for content. It uses mechanisms similar to IKE (called AKE) and DTCP (like IPsec). So may be it is not as far away from cryptography as you might assume. Thanks, Vishwas > Jon > > > -----BEGIN PGP SIGNATURE----- > Version: PGP Universal 2.6.3 > Charset: US-ASCII > > wj8DBQFHu2/hsTedWZOD3gYRAuZbAJ9IFEWuafL6fAB+2MxJvwIEOmLJiACgkJrs > eRur6xWa+w6FdH022GobtDg= > =ZTOd > -----END PGP SIGNATURE----- > > > _______________________________________________ > saag mailing list > saag@mit.edu > http://mailman.mit.edu/mailman/listinfo/saag > From pgut001@cs.auckland.ac.nz Mon Feb 25 10:44:46 2008 Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1PFikTL028438 for ; Mon, 25 Feb 2008 10:44:46 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by fort-point-station.mit.edu (8.13.6/8.9.2) with ESMTP id m1PFiUlj020528 for ; Mon, 25 Feb 2008 10:44:35 -0500 (EST) Received: from mailhost.auckland.ac.nz (curly.its.auckland.ac.nz [130.216.12.33]) by mit.edu (Spam Firewall) with ESMTP id 4C308DCE69D for ; Mon, 25 Feb 2008 10:44:02 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 38F5C9C418; Tue, 26 Feb 2008 04:44:01 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (curly.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mgBA08TEH3sX; Tue, 26 Feb 2008 04:44:01 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id D0F779C3FD; Tue, 26 Feb 2008 04:44:00 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 41AED19EC0BE; Tue, 26 Feb 2008 04:44:00 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JTfUm-00089i-3o; Tue, 26 Feb 2008 04:44:00 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, rja@extremenetworks.com In-Reply-To: <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com> Message-Id: Sender: pgut001 Date: Tue, 26 Feb 2008 04:44:00 +1300 X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 15:44:46 -0000 Randall Atkinson writes: >Earlier, Peter Gutmann wrote: >% If FIPS 140 is the answer now, why wasn't the Orange Book >% the answer then? > >You are comparing apples to oranges above. > >FIPS-140 is only about assurance for cryptographic modules. >Orange Book (TCSEC) was only about operating system security. > >The two address different issues. They certainly seem to be addressing them in very similar ways. >Or were you proposing to setup a monopoly ? Ten years ago the rule-of-thumb estimate for a FIPS 140 level 1 eval was $100K and 6-12 months no matter who you went to. In 2006 (last time I checked) the rule-of-thumb estimate for a FIPS 140 level 1 eval was $100K and 6-12 months no matter who you went to. So it looks like we already have a well- established oligopoly with FIPS 140 evals, the only difference is the nomenclature. >One needs a process that is as consistent and reproducible as practical Why? This is the ISO 9000-for-software fallacy, reproducibility is great when you're cranking out lightbulbs, but not much use for software, which isn't a mass production process but instead is based on the cloning of the result of a one-off development effort which is the product of the creativity, skill, and co-operation of developers and users. I can easily get 100% consistency in reproducing an executable on a CDROM, but I don't think that's what's meant here. >If you think that FIPS-140-* is a target-rich environment, then please try to >seriously propose something better. I understand NIST and its partners are >looking to evolve into FIPS 140-3 from FIPS 140-2. It depends on what you want from FIPS 140 (and I'm talking specifically FIPS 140 for software modules here, which is the form that 99.9% of users encounter it in ). Some people have said you get "assurance", but the assurance you're getting here is a high level of assurance that the vendors were desperate enough for government sales that they shelled out a large amount of money in order to get a ticket to ride the gravy train. The problem is that like "religion" or "morals", "assurance" is a loaded term and can be interpreted to mean almost anything. Without some basic definition of what's meant by "assurance", it's not really possible to reason about this. So here's an attempt to nail it down: For me (and I would guess most end users) assurance is being able to sleep at night knowing there's little chance of anyone compromising my system ("things that should happen do happen, things that shouldn't happen don't happen"). Let's see what FIPS 140 gives you to help you sleep at night. It tests some crypto mechanisms, but ignores others. If you're buying an IPsec product it doesn't test all the mechanisms needed for IPsec. If you're buying a TLS product it doesn't test the mechanisms needed for TLS. If you're buying... well, you get the idea. Compare this to the example I gave earlier of performing a TLS exchange with Amazon. This performs an in-depth test of all the crypto algorithms (corresponding to the FIPS algorithm tests, including ones that FIPS ignores), and the crypto mechanisms (many/most of which FIPS again ignores). In other words simply by connecting to Amazon using TLS and ordering a "Scrubs" DVD for $19.95 I'm getting more comprehensive algorithm testing than I can for a five- figure sum with the FIPS algorithm tests. So what else do you get? You get a bit of a code review and some checking that you don't do stupid things with keys. Only some of the code is reviewed (for example that trivial buffer overflow in the client handshake that allows a remote attacker to do whatever they want with your server, including the FIPS 140-evaluated portion, isn't checked because it's outside the scope of what FIPS 140 is interested in), and (from having gone through several of these) the review itself seems to be more coding style nitpicks than looking for potential exploits, and in any case you can often document away any problems without having to fix them. So the assurance a FIPS 140 eval gets you is a tautological "the product vendor was able to pass a FIPS 140 eval". In terms of being able to demonstrate this type of assurance, I agree completely with you that there is no better mechanism for it than FIPS 140. Admittedly there is some value to FIPS 140: You know that a subset of the crypto used is OK, that the code doesn't do anything stupid with its keys (unless the vendor has documented away the stupid things that do happen, e.g. CryptoAPI's plaintext private-key export, you ask it "Give me the user's private key in plaintext form" and it says "Sure, here you go"), and that it's had a bit of a code check (and obviously if you're doing hardware crypto you get a lot more value than this, but the discussion here is about software modules). What you don't get from FIPS 140 is the stuff that customers really care about: Assurance that your IPsec product can actually do IPsec, that your TLS product can do TLS, or that the product really is secure(-ish). Excusing this by saying that a FIPS 140 crypto product eval doesn't have to check half your crypto so this isn't a problem is like saying that your TSA passenger- screening process is OK even though it doesn't bother checking men with beards or anyone under 5'6" tall. If I'm going to spend $100K to feel safe then I can really think of better ways than FIPS 140 (or CC, or ITSEC, or ...). How about the following comparison: You get to spend the cost of a FIPS 140 eval in one of two ways: $100K: FIPS 140 -- or -- $20K: Fortify (or whatever) scan. $20K: Cigital (or whatever) audit/analysis (these are just representative figures/estimates since there don't seem to be any fixed rates for this sort of thing). $5K: Grant to French university to pen-test code "written at a German university". $5K: Grant to British university to pen-test code "written at a French university". $5K: Set up a fake banking site running the code and bring it to the attention of the Russian Business Network. $free: Leak "security code for Windows 7" to Slashdot. $free: Leak "security code for BluRay++" on warez boards. $free: Leak "Diebold voting machine security code" to Cryptome. $45K: 50" plasma TV, home theatre system, and beer to kill time while you wait for the results to come in (and to emphasise how much cheaper this is than FIPS 140 :-). If your life depended on the security of the product that went through those two processes, which one would you trust? FIPS 140 is just not cost-effective in providing assurance - it costs too much, it takes too long, and it doesn't evaluate the stuff that real users care about having evaluated. >The claims (not by me so much as by other folks on the SAAG list) have been >that (1) FIPS-140 is better than other extant security evaluations Thus showing that the politician's fallacy is alive and well :-). There was a long and extremely interesting discussion on the (somewhat misnamed) open-source list recently, thread topic "How can high assurance FLOSS development be encouraged?". The archives are at http://lists.csl.sri.com/mailman/listinfo/open-source, but you have to sign up to the list in order to access them. Peter. From SChokhani@cygnacom.com Mon Feb 25 12:21:25 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1PHLOGA000940 for ; Mon, 25 Feb 2008 12:21:24 -0500 Received: from mit.edu (W92-130-BARRACUDA-1.MIT.EDU [18.7.21.220]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1PHLAps017642 for ; Mon, 25 Feb 2008 12:21:10 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id AC2136E769A for ; Mon, 25 Feb 2008 12:20:45 -0500 (EST) Received: (qmail 13300 invoked from network); 25 Feb 2008 17:13:05 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 25 Feb 2008 17:13:05 -0000 X-EntrustECS-Action: Trigger(Bad Language) X-EntrustECS-Id: (scygmxsecs1.cygnacom.com)1203959583134231027 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 25 Feb 2008 17:13:03 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 25 Feb 2008 12:20:43 -0500 Message-ID: in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Ach3xZ7X0SuZb1t4TBCR8zapsHjpLgADKoSw References: <8329C86009B2F24493D76B486146769A9596B14F@USEXCHANGE.corp.extremenetworks.com> From: "Santosh Chokhani" To: "Peter Gutmann" , X-Spam-Score: 0.42 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1PHLOGA000940 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Feb 2008 17:21:25 -0000 Peter, You are wrong about FIPS 140-1 costs being 100K for Level 1. It is more like 30K. In terms of what FIPS buys is that you ensure that the algorithm is implemented correctly, keys will be generated in accordance with FIPS (meaning that the seed feeding the PRNG will have requisite entropy and PRNG will be FIPS approved). You also get the assurance that the keys are being managed properly in the crypto module. -----Original Message----- From: saag-bounces@mit.edu [mailto:saag-bounces@mit.edu] On Behalf Of Peter Gutmann Sent: Monday, February 25, 2008 10:44 AM To: pgut001@cs.auckland.ac.nz; rja@extremenetworks.com Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers Randall Atkinson writes: >Earlier, Peter Gutmann wrote: >% If FIPS 140 is the answer now, why wasn't the Orange Book >% the answer then? > >You are comparing apples to oranges above. > >FIPS-140 is only about assurance for cryptographic modules. >Orange Book (TCSEC) was only about operating system security. > >The two address different issues. They certainly seem to be addressing them in very similar ways. >Or were you proposing to setup a monopoly ? Ten years ago the rule-of-thumb estimate for a FIPS 140 level 1 eval was $100K and 6-12 months no matter who you went to. In 2006 (last time I checked) the rule-of-thumb estimate for a FIPS 140 level 1 eval was $100K and 6-12 months no matter who you went to. So it looks like we already have a well- established oligopoly with FIPS 140 evals, the only difference is the nomenclature. >One needs a process that is as consistent and reproducible as practical Why? This is the ISO 9000-for-software fallacy, reproducibility is great when you're cranking out lightbulbs, but not much use for software, which isn't a mass production process but instead is based on the cloning of the result of a one-off development effort which is the product of the creativity, skill, and co-operation of developers and users. I can easily get 100% consistency in reproducing an executable on a CDROM, but I don't think that's what's meant here. >If you think that FIPS-140-* is a target-rich environment, then please try to >seriously propose something better. I understand NIST and its partners are >looking to evolve into FIPS 140-3 from FIPS 140-2. It depends on what you want from FIPS 140 (and I'm talking specifically FIPS 140 for software modules here, which is the form that 99.9% of users encounter it in ). Some people have said you get "assurance", but the assurance you're getting here is a high level of assurance that the vendors were desperate enough for government sales that they shelled out a large amount of money in order to get a ticket to ride the gravy train. The problem is that like "religion" or "morals", "assurance" is a loaded term and can be interpreted to mean almost anything. Without some basic definition of what's meant by "assurance", it's not really possible to reason about this. So here's an attempt to nail it down: For me (and I would guess most end users) assurance is being able to sleep at night knowing there's little chance of anyone compromising my system ("things that should happen do happen, things that shouldn't happen don't happen"). Let's see what FIPS 140 gives you to help you sleep at night. It tests some crypto mechanisms, but ignores others. If you're buying an IPsec product it doesn't test all the mechanisms needed for IPsec. If you're buying a TLS product it doesn't test the mechanisms needed for TLS. If you're buying... well, you get the idea. Compare this to the example I gave earlier of performing a TLS exchange with Amazon. This performs an in-depth test of all the crypto algorithms (corresponding to the FIPS algorithm tests, including ones that FIPS ignores), and the crypto mechanisms (many/most of which FIPS again ignores). In other words simply by connecting to Amazon using TLS and ordering a "Scrubs" DVD for $19.95 I'm getting more comprehensive algorithm testing than I can for a five- figure sum with the FIPS algorithm tests. So what else do you get? You get a bit of a code review and some checking that you don't do stupid things with keys. Only some of the code is reviewed (for example that trivial buffer overflow in the client handshake that allows a remote attacker to do whatever they want with your server, including the FIPS 140-evaluated portion, isn't checked because it's outside the scope of what FIPS 140 is interested in), and (from having gone through several of these) the review itself seems to be more coding style nitpicks than looking for potential exploits, and in any case you can often document away any problems without having to fix them. So the assurance a FIPS 140 eval gets you is a tautological "the product vendor was able to pass a FIPS 140 eval". In terms of being able to demonstrate this type of assurance, I agree completely with you that there is no better mechanism for it than FIPS 140. Admittedly there is some value to FIPS 140: You know that a subset of the crypto used is OK, that the code doesn't do anything stupid with its keys (unless the vendor has documented away the stupid things that do happen, e.g. CryptoAPI's plaintext private-key export, you ask it "Give me the user's private key in plaintext form" and it says "Sure, here you go"), and that it's had a bit of a code check (and obviously if you're doing hardware crypto you get a lot more value than this, but the discussion here is about software modules). What you don't get from FIPS 140 is the stuff that customers really care about: Assurance that your IPsec product can actually do IPsec, that your TLS product can do TLS, or that the product really is secure(-ish). Excusing this by saying that a FIPS 140 crypto product eval doesn't have to check half your crypto so this isn't a problem is like saying that your TSA passenger- screening process is OK even though it doesn't bother checking men with beards or anyone under 5'6" tall. If I'm going to spend $100K to feel safe then I can really think of better ways than FIPS 140 (or CC, or ITSEC, or ...). How about the following comparison: You get to spend the cost of a FIPS 140 eval in one of two ways: $100K: FIPS 140 -- or -- $20K: Fortify (or whatever) scan. $20K: Cigital (or whatever) audit/analysis (these are just representative figures/estimates since there don't seem to be any fixed rates for this sort of thing). $5K: Grant to French university to pen-test code "written at a German university". $5K: Grant to British university to pen-test code "written at a French university". $5K: Set up a fake banking site running the code and bring it to the attention of the Russian Business Network. $free: Leak "security code for Windows 7" to Slashdot. $free: Leak "security code for BluRay++" on warez boards. $free: Leak "Diebold voting machine security code" to Cryptome. $45K: 50" plasma TV, home theatre system, and beer to kill time while you wait for the results to come in (and to emphasise how much cheaper this is than FIPS 140 :-). If your life depended on the security of the product that went through those two processes, which one would you trust? FIPS 140 is just not cost-effective in providing assurance - it costs too much, it takes too long, and it doesn't evaluate the stuff that real users care about having evaluated. >The claims (not by me so much as by other folks on the SAAG list) have been >that (1) FIPS-140 is better than other extant security evaluations Thus showing that the politician's fallacy is alive and well :-). There was a long and extremely interesting discussion on the (somewhat misnamed) open-source list recently, thread topic "How can high assurance FLOSS development be encouraged?". The archives are at http://lists.csl.sri.com/mailman/listinfo/open-source, but you have to sign up to the list in order to access them. Peter. _______________________________________________ saag mailing list saag@mit.edu http://mailman.mit.edu/mailman/listinfo/saag From pgut001@cs.auckland.ac.nz Tue Feb 26 01:34:34 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1Q6YYsu012546 for ; Tue, 26 Feb 2008 01:34:34 -0500 Received: from mit.edu (M24-004-BARRACUDA-3.MIT.EDU [18.7.7.114]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1Q6YMZc010113 for ; Tue, 26 Feb 2008 01:34:23 -0500 (EST) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by mit.edu (Spam Firewall) with ESMTP id 4B152DF95F7 for ; Tue, 26 Feb 2008 01:34:01 -0500 (EST) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3E6EB4804F5; Tue, 26 Feb 2008 19:33:58 +1300 (NZDT) Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OAkStm7vxQxC; Tue, 26 Feb 2008 19:33:58 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 2459D4803EC; Tue, 26 Feb 2008 19:33:58 +1300 (NZDT) Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 574CC19EC0F1; Tue, 26 Feb 2008 19:33:57 +1300 (NZDT) Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from ) id 1JTtO1-00080p-6o; Tue, 26 Feb 2008 19:33:57 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, rja@extremenetworks.com, SChokhani@cygnacom.com In-Reply-To: Message-Id: Sender: pgut001 Date: Tue, 26 Feb 2008 19:33:57 +1300 X-Spam-Score: 0 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 06:34:34 -0000 "Santosh Chokhani" writes: >You are wrong about FIPS 140-1 costs being 100K for Level 1. It is more like >30K. The figures I've been given, from numerous vendors going through numerous labs over a number of years, is that their all-up cost for a level 1 software eval was around $100K (give or take a few tens of $K). This isn't just the final cheque they cut to get the coloured piece of paper, this is the all-up cost of getting their product through a FIPS 140 eval. I realise the following may be a bit unfair since you weren't intending to provide a price quote :-), but I'm willing to put my money where my mouth is: If Cygnacom can get me a FIPS 140 level 1 on my code for an all-up cost of $30K I'll send you a cheque and CDROM of the source within 24 hours (I need to get mgt.approval first). Just let me know where to send it and who to make the payment out to. >In terms of what FIPS buys is that you ensure that the algorithm is >implemented correctly, That a *subset* of the algorithms used are impemented correctly, in other words a subset of what you can get for $19.95 via a TLS connect to Amazon. And the actual crypto mechanisms don't get tested at all. >keys will be generated in accordance with FIPS (meaning that the seed feeding >the PRNG will have requisite entropy and PRNG will be FIPS approved). A nice circular definition: "A FIPS evaluation guarantees that keys will be generated as required in order to pass a FIPS evaluation". >You also get the assurance that the keys are being managed properly in the >crypto module. ... unless the vendor has documented away the mismanagement, e.g. CryptoAPIs plaintext private key export. You're not making a very convincing argument here :-). Peter. From SChokhani@cygnacom.com Tue Feb 26 07:40:12 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1QCeBoA025835 for ; Tue, 26 Feb 2008 07:40:11 -0500 Received: from mit.edu (W92-130-BARRACUDA-2.MIT.EDU [18.7.21.223]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1QCe1Kp017202 for ; Tue, 26 Feb 2008 07:40:02 -0500 (EST) Received: from scygmxsecs1.cygnacom.com (scygmxsecs1.cygnacom.com [65.242.48.253]) by mit.edu (Spam Firewall) with SMTP id 1F8F4CF336C for ; Tue, 26 Feb 2008 07:39:41 -0500 (EST) Received: (qmail 24703 invoked from network); 26 Feb 2008 12:31:59 -0000 Received: from SChokhani@cygnacom.com by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4; 26 Feb 2008 12:31:59 -0000 Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 26 Feb 2008 12:31:59 -0000 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 26 Feb 2008 07:39:40 -0500 Message-ID: in-reply-to: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [saag] Algorithms/modes requested by users/customers Thread-Index: Ach4QZI6/TYJ7/uKQPmFL6pYftWfCwAMq+Sw References: From: "Santosh Chokhani" To: "pgut001" , X-Spam-Score: 0.30 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by pch.mit.edu id m1QCeBoA025835 Cc: saag@mit.edu Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 12:40:12 -0000 Peter, I do not think this is a forum for negotiations. But, we will be happy to do FIPS testing for your product for Level 1 for quoted price. As to algorithms, all FIPS approved algorithms need to be tested. As to key generation there are standards that come out of NIST and ANSI X9 that IETF also takes its cue from, and FIPS process ensures that the keys are generated in accordance with those standards. Have you yourself participated in a FIPS evaluation or have you looked at the NIST FIPS 140-2 DTR and FIPS 140-2 IG (i.e. Implementation Guidance) available on the Web? -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] Sent: Tuesday, February 26, 2008 1:34 AM To: pgut001@cs.auckland.ac.nz; rja@extremenetworks.com; Santosh Chokhani Cc: saag@mit.edu Subject: RE: [saag] Algorithms/modes requested by users/customers "Santosh Chokhani" writes: >You are wrong about FIPS 140-1 costs being 100K for Level 1. It is more like >30K. The figures I've been given, from numerous vendors going through numerous labs over a number of years, is that their all-up cost for a level 1 software eval was around $100K (give or take a few tens of $K). This isn't just the final cheque they cut to get the coloured piece of paper, this is the all-up cost of getting their product through a FIPS 140 eval. I realise the following may be a bit unfair since you weren't intending to provide a price quote :-), but I'm willing to put my money where my mouth is: If Cygnacom can get me a FIPS 140 level 1 on my code for an all-up cost of $30K I'll send you a cheque and CDROM of the source within 24 hours (I need to get mgt.approval first). Just let me know where to send it and who to make the payment out to. >In terms of what FIPS buys is that you ensure that the algorithm is >implemented correctly, That a *subset* of the algorithms used are impemented correctly, in other words a subset of what you can get for $19.95 via a TLS connect to Amazon. And the actual crypto mechanisms don't get tested at all. >keys will be generated in accordance with FIPS (meaning that the seed feeding >the PRNG will have requisite entropy and PRNG will be FIPS approved). A nice circular definition: "A FIPS evaluation guarantees that keys will be generated as required in order to pass a FIPS evaluation". >You also get the assurance that the keys are being managed properly in the >crypto module. ... unless the vendor has documented away the mismanagement, e.g. CryptoAPIs plaintext private key export. You're not making a very convincing argument here :-). Peter. From amamsaad@hotmail.com Sat Feb 23 04:17:21 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1N9HLN7028209 for ; Sat, 23 Feb 2008 04:17:21 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1N9H95m011867 for ; Sat, 23 Feb 2008 04:17:09 -0500 (EST) Received: from bay0-omc3-s3.bay0.hotmail.com (bay0-omc3-s3.bay0.hotmail.com [65.54.246.203]) by mit.edu (Spam Firewall) with ESMTP id E08AD79EBA1 for ; Sat, 23 Feb 2008 04:17:07 -0500 (EST) Received: from BAY126-W47 ([65.55.131.82]) by bay0-omc3-s3.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 23 Feb 2008 01:17:06 -0800 Message-ID: Content-Type: multipart/alternative; boundary="_3fb6503a-cb93-4732-b6ee-22ccfd01385c_" X-Originating-IP: [62.150.226.151] From: AHMED Abdallah To: Date: Sat, 23 Feb 2008 09:17:06 +0000 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 23 Feb 2008 09:17:06.0548 (UTC) FILETIME=[DC21F340:01C875FC] X-Spam-Score: 0.12 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 X-Mailman-Approved-At: Tue, 26 Feb 2008 09:52:38 -0500 Subject: [saag] Manet security group X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Feb 2008 09:17:21 -0000 --_3fb6503a-cb93-4732-b6ee-22ccfd01385c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Daer sir, =20 Why i can't find any group for manet security. if there please iform me how= to access it. =20 best regards, =20 Ahmed M. Abdullah =20 _________________________________________________________________ Climb to the top of the charts!=A0Play the word scramble challenge with sta= r power. http://club.live.com/star_shuffle.aspx?icid=3Dstarshuffle_wlmailtextlink_ja= n= --_3fb6503a-cb93-4732-b6ee-22ccfd01385c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Daer sir,
 
Why i can't find any group for manet security. if there please iform me how= to access it.
 
best regards,
 
Ahmed M. Abdullah
 

Climb to the top of the charts!=A0Play the word scram= ble challenge with star power. Play now!<= /body> = --_3fb6503a-cb93-4732-b6ee-22ccfd01385c_-- From tim.polk@nist.gov Tue Feb 26 10:01:49 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1QF1m9v008910 for ; Tue, 26 Feb 2008 10:01:49 -0500 Received: from mit.edu (M24-004-BARRACUDA-1.MIT.EDU [18.7.7.111]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1QF1XXI018892 for ; Tue, 26 Feb 2008 10:01:35 -0500 (EST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 38A597AB6BD for ; Tue, 26 Feb 2008 10:01:00 -0500 (EST) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m1QF0uq7005255; Tue, 26 Feb 2008 10:00:56 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Tim Polk Date: Tue, 26 Feb 2008 10:01:01 -0500 To: saag@mit.edu X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 0.01 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Subject: [saag] Call for presentation topics X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 15:01:49 -0000 Folks, Sam, Pasi, and I are putting together the SAAG agenda for Philadelphia. The agenda traditionally includes one or two invited presentations after the working group reports. We would appreciate submission of presentation topics that you believe would be of interest to the community. If you can identify an appropriate presenter (not necessarily yourself) that would be helpful. Note: If you previously submitted a topic or presentation request, I missed it or it got filtered accidentally. Please resubmit! Thanks, Tim Polk From tim.polk@nist.gov Tue Feb 26 10:52:10 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1QFq9Mn027375 for ; Tue, 26 Feb 2008 10:52:10 -0500 Received: from mit.edu (W92-130-BARRACUDA-3.MIT.EDU [18.7.21.224]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1QFq0VV028053 for ; Tue, 26 Feb 2008 10:52:00 -0500 (EST) Received: from smtp.nist.gov (rimp1.nist.gov [129.6.16.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mit.edu (Spam Firewall) with ESMTP id 21DECDEBF5F; Tue, 26 Feb 2008 10:51:38 -0500 (EST) Received: from [192.168.15.166] (bethany.ncsl.nist.gov [129.6.52.15]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m1QFpVps021585; Tue, 26 Feb 2008 10:51:31 -0500 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <454FA23D-9DC9-4F2B-BD69-53181E998178@nist.gov> Content-Transfer-Encoding: 7bit From: Tim Polk Date: Tue, 26 Feb 2008 10:51:36 -0500 To: saag@mit.edu X-Mailer: Apple Mail (2.752.2) X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: tim.polk@nist.gov X-Spam-Score: 3.5 X-Spam-Level: *** (3.5) X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: Sam Hartman Subject: Re: [saag] Call for presentation topics, again... X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 15:52:10 -0000 One final note - please direct your presentation topics to Pasi, Sam, and I. Unfortunately, I forgot to CC them on the last message, so a reply would only go to me... On Feb 26, 2008, at 10:01 AM, Tim Polk wrote: > Folks, > > Sam, Pasi, and I are putting together the SAAG agenda for > Philadelphia. > > The agenda traditionally includes one or two invited presentations > after the > working group reports. We would appreciate submission of > presentation topics > that you believe would be of interest to the community. > > If you can identify an appropriate presenter (not necessarily > yourself) that would > be helpful. > > Note: If you previously submitted a topic or presentation request, > I missed it or it > got filtered accidentally. Please resubmit! > > Thanks, > > Tim Polk From kent@bbn.com Tue Feb 26 21:10:31 2008 Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by pch.mit.edu (8.13.6/8.12.8) with ESMTP id m1R2AQxJ016576 for ; Tue, 26 Feb 2008 21:10:26 -0500 Received: from mit.edu (M24-004-BARRACUDA-2.MIT.EDU [18.7.7.112]) by pacific-carrier-annex.mit.edu (8.13.6/8.9.2) with ESMTP id m1R2AGLS001954 for ; Tue, 26 Feb 2008 21:10:16 -0500 (EST) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by mit.edu (Spam Firewall) with ESMTP id 2BC75F96588 for ; Tue, 26 Feb 2008 21:09:55 -0500 (EST) Received: from dommiel.bbn.com ([192.1.122.15] helo=[169.223.13.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1JUBjz-00068K-4J; Tue, 26 Feb 2008 21:09:54 -0500 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 26 Feb 2008 21:09:51 -0500 To: pgut001@cs.auckland.ac.nz (Peter Gutmann) From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.00 X-Spam-Flag: NO X-Scanned-By: MIMEDefang 2.42 Cc: saag@mit.edu, rja@extremenetworks.com Subject: Re: [saag] Algorithms/modes requested by users/customers X-BeenThere: saag@mit.edu X-Mailman-Version: 2.1.6 Precedence: list List-Id: IETF Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Feb 2008 02:10:31 -0000 At 4:44 AM +1300 2/26/08, Peter Gutmann wrote: >... > >Ten years ago the rule-of-thumb estimate for a FIPS 140 level 1 eval was $100K >and 6-12 months no matter who you went to. In 2006 (last time I checked) the >rule-of-thumb estimate for a FIPS 140 level 1 eval was $100K and 6-12 months >no matter who you went to. So it looks like we already have a well- >established oligopoly with FIPS 140 evals, the only difference is the >nomenclature. BBN developed the first crypto module evaluated at level 3 under FIPS 140-1. The fee we paid to the eval lab was about $40K, and the elapsed time was about 6 months. That was more than ten years ago, but we're also talking about a much more thorough eval. The cost to a developer is, of course, higher, when you add in the time required to prepare the necessary documentation. Also, if the developer is not experienced in secure development practices, the likelihood increases that the eval will not go smoothly, and thus the costs will be higher. Maybe what you're reporting is the result of more developers, with less experience secure crypto module development experience submitting products that are "not quite ready." ... > >If you think that FIPS-140-* is a target-rich environment, then >please try to >>seriously propose something better. I understand NIST and its partners are >>looking to evolve into FIPS 140-3 from FIPS 140-2. > >It depends on what you want from FIPS 140 (and I'm talking specifically FIPS >140 for software modules here, which is the form that 99.9% of users encounter >it in ). Some people have said you get "assurance", but the assurance you're >getting here is a high level of assurance that the vendors were desperate >enough for government sales that they shelled out a large amount of money in >order to get a ticket to ride the gravy train. Sotware modules are easier for a developer to create and submit, and this too may cause more submissions that are less well thought out. If you're building hardware there may be more of an effort to "get it right" in the planning stages, because the costs of redesign are potentially higher. >The problem is that like "religion" or "morals", "assurance" is a loaded term >and can be interpreted to mean almost anything. Without some basic definition >of what's meant by "assurance", it's not really possible to reason about this. >So here's an attempt to nail it down: For me (and I would guess most end >users) assurance is being able to sleep at night knowing there's little chance >of anyone compromising my system ("things that should happen do happen, things >that shouldn't happen don't happen"). Assurance (in the security context) is not as squishy a term as your suggest. Security assurance is generally characterized as confidence that an implementation meet certain objective security-relevant criteria. These are not interoperability criteria. It is distinguished from security functionality, which refers to the set of functions (features) ascribed to a product (without confidence that these features operate as promised). >Let's see what FIPS 140 gives you to help you sleep at night. It tests some >crypto mechanisms, but ignores others. If you're buying an IPsec product it >doesn't test all the mechanisms needed for IPsec. If you're buying a TLS >product it doesn't test the mechanisms needed for TLS. If you're buying... >well, you get the idea. For a protocol such as TLS or IPsec, crypto module security assurance does not encompass most aspects of what a users sees as "correct" operation. It makes sense to look for both functionality testing and security assurance evaluation, if you care about both functionality and security. >Compare this to the example I gave earlier of performing a TLS exchange with >Amazon. This performs an in-depth test of all the crypto algorithms >(corresponding to the FIPS algorithm tests, including ones that FIPS ignores), >and the crypto mechanisms (many/most of which FIPS again ignores). In other >words simply by connecting to Amazon using TLS and ordering a "Scrubs" DVD for >$19.95 I'm getting more comprehensive algorithm testing than I can for a five- >figure sum with the FIPS algorithm tests. nonsense! what you get is confidence that the SSL/TLS implementation at Amazon and in your browser work compatibly, even if both happen to be "wrong." In fact, the test you propose checks only a small subset of the SSL/TLS spec, as it verifies only that the RSA key transport method of key management works, none of the other key management methods defined by the RFCs. So, maybe what you meant to say was that the proposed test regimen verifies that a protocol and associated crypto work compatibility with an implementation of the most common subset of the crypto modes and protocol features deployed. That's a useful finding, but let's not confuse it with protocol standard conformance or security assurance. I won't bother to respond to the rest of your observations, since they repeat many of the themes I touched upon above. It is silly to ask FIPS 140 to address protocol interop issues; that is simply not in scope for a generic crypto security eval criteria. So let's forgo all the arguments along those lines. Vendor claims about security sometimes (often?) prove to be wrong. Thus is makes sense to seek external, independent assurances about security, if you care. The fact that FIPS 140 addresses only a subset of those claims is also not a basis for criticizing a generic crypto module evaluation criteria like FIPS 140. Common Criteria eval of products is more encompassing, but also MUCH more expensive. So, IF one cares about crypto security, THEN FIPS 140 eval is the best option for now. That does not make it ideal, but it also does not make it as bad as some comments have suggested, and it is unfair to criticize it for not doing something that it has never promised to do. Steve