From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp73.iad3a.emailsrvr.com (smtp73.iad3a.emailsrvr.com [173.203.187.73]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id 159D421F0D3 for ; Mon, 14 Apr 2014 16:22:42 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp18.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id C6DD33300A1; Mon, 14 Apr 2014 19:22:40 -0400 (EDT) X-Virus-Scanned: OK Received: from app43.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp18.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id A0892330074; Mon, 14 Apr 2014 19:22:40 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by app43.wa-webapps.iad3a (Postfix) with ESMTP id 8EC5C380052; Mon, 14 Apr 2014 19:22:40 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Mon, 14 Apr 2014 19:22:40 -0400 (EDT) Date: Mon, 14 Apr 2014 19:22:40 -0400 (EDT) From: dpreed@reed.com To: "Dave Taht" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20140414192240000000_98534" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: References: <1397245399.392818481@apps.rackspace.com> Message-ID: <1397517760.583622260@apps.rackspace.com> X-Mailer: webmail7.0 Cc: "cerowrt-devel@lists.bufferbloat.net" , bloat Subject: Re: [Cerowrt-devel] wired article about bleed and bloat and underfunded critical infrastructure X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 23:22:42 -0000 ------=_20140414192240000000_98534 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0AAll great points.=0A =0ARegarding the Orange Book for distributed/networ= k systems - the saddest part of that effort was that it was declared "done"= when the standards were published, even though the challenges of decentral= ized networks of autonomously managed computers was already upon us. The O= range Book was for individual computer systems that talked directly to end = users and sat in physically secured locations, and did not apply to larger = scale compositions of same. It did not apply to PCs in users' hands, eithe= r (even if not connected to a network). It did lay out its assumptions; bu= t the temptation to believe its specifics applied when those assumptions we= ren't met clearly overrode engineering and managerial sense. For example, = it was used to argue that Windows NT was "certified secure" according to th= e Orange Book. :-)=0A =0A =0A=0A=0AOn Sunday, April 13, 2014 8:57pm, "Dave = Taht" said:=0A=0A=0A=0A> On Fri, Apr 11, 2014 at 12:4= 3 PM, wrote:=0A> > I'm afraid it's not *just* underfunde= d. I reviewed the details of the code=0A> > involved and the fixes, and m= y conclusion is that even programmers of=0A> > security software have not l= earned how to think about design, testing, etc.=0A> > Especially the contin= uing use of C in a large shared process address space=0A> > for writing pro= tocols that are by definition in the "security kernel"=0A> > (according to = the original definition) of applications on which the public=0A> > depends.= =0A> >=0A> >=0A> >=0A> > Ever since I was part of the Multics Security Proj= ect (which was part of the=0A> > effort that produced the Orange Book=0A> >= http://csrc.nist.gov/publications/history/dod85.pdf)=0A> =0A> Which I inci= dentally have read... and fail to see how it applies well=0A> to networked = systems.=0A> =0A> > in the 80's, we've=0A> > known that security-based code= should not be exposed to user code and vice=0A> > versa. Yet the SSL libr= aries are linked in, in userspace, with the=0A> > application code.=0A> =0A= > I note that I am glad that they are mostly dynamically linked in -=0A> so= mething that wasn't the case for some other crypto libs - because=0A> findi= ng applications=0A> that linked statically would be even more difficult.=0A= > =0A> And I have seen some reports of people using heavily patched openssl= =0A> doing smarter things with memory allocation - why weren't those patche= s=0A> pushed back into openssl?=0A> =0A> Well, because they were held priva= te and not publicly reviewed... and=0A> don't appear to actually work, acco= rding to this:=0A> =0A> http://lekkertech.net/akamai.txt=0A> =0A> > Also, u= pgrades/changes to protocols related to security (which always should=0A> >= have been in place on every end-to-end connection) should be reviewed *bot= h=0A> > at the protocol design level* and also at the *implementation level= * because=0A> > change creates risk. They should not be adopted blindly wi= thout serious=0A> > examination and pen-testing, yet this change just was c= asually thrown in in=0A> > a patch release.=0A> =0A> Yes, change creates ri= sk. Change also breeds change. Without change=0A> there would be no progres= s.=0A> =0A> Should there be an "office of critical infrastructure" or an=0A= > underwriters labratory examining and blessing each piece of software=0A> = that runs as root or handles money? Should some governmental or=0A> intergo= vernmental group be putting a floor under (or a roof over) the=0A> people w= orking on code deemed as critical infrastructure?=0A> =0A> heartbleed was n= ot detected by a coverity scan either.=0A> =0A> > I suspect that even if it= were well funded, the folks who deploy the=0A> > technology would be slapd= ash at best.=0A> =0A> I agree. Recently I was asked to come up with an "pho= ne-home inside=0A> your business embedded device architecture" that would s= cale to=0A> millions of users.=0A> =0A> I don't want the responsibility, no= r do I think any but hundreds of=0A> people working together could come up = with something that would let me=0A> sleep well at night - yet the market d= emand is there for something,=0A> anything, that even barely works.=0A> =0A= > If I don't do the work, someone less qualified will.=0A> =0A> =0A> > Reme= mber the Y2K issue=0A> =0A> I do. I also remember the response to it.=0A> = =0A> http://www.taht.net/~mtaht/uncle_bills_helicopter.html=0A> =0A> The re= sponse to heartbleed has been incredibly heartening as to the=0A> swiftness= of repair - something that could not have happened in=0A> anything other t= han the open source world. I have friends, however,=0A> that just went days= without sleep, fixing it.=0A> =0A> I've outlined my major concerns with TL= S across our critical=0A> infrastructure going forward on my g+.=0A> =0A> >= and the cost of=0A> > lazy thinking about dates. (I feel a little superior= because in 1968 Multics=0A> > standardized on a 72-bit hardware microsecon= d-resolution hardware clock=0A> > because the designers actually thought ab= out long-lived systems (actually=0A> =0A> I agree that was far-thinking. I = too worry about Y2036 and Y2038, and=0A> do my best to make sure those aren= 't problems.=0A> =0A> it seems likely some software will last even longer t= han that.=0A> =0A> > only 56 bits of the original clock worked, but the har= dware was not expected=0A> > to last until the remaining bits could be adde= d)).=0A> =0A> Multics died. It would not have scaled to the internet. And c= rypto=0A> development and public deployment COULD have gone more hand in ha= nd if=0A> it weren't basically illegal until 1994, and maybe before then, s= ome=0A> reasonable security could have been embedded deep into more protoco= ls.=0A> =0A> It would have been nice to have had a secured X11 protocol, or= =0A> kerberos made globally deployable, or things like mosh, in the 80s. In= =0A> terms of more recent events, I happen to have liked HIP.=0A> =0A> We d= on't know how to build secured network systems to this day, that=0A> can su= rvive an exposure to hundreds of millions of potential=0A> attackers.=0A> >= =0A> >=0A> > The open source movement, unfortunately, made a monoculture of= the SSL=0A> > source code, so it's much more dangerous and the vulnerable = attack surface=0A> > of deployments is enormous.=0A> =0A> No it didn't. Alt= ernatives to openssl exist - gnutls, cyassl, and=0A> polarssl are also open= source. Libraries that merely implement=0A> primitives well like nettle, g= mp, and libsodium - all developed later=0A> - also exist.=0A> =0A> I am GLA= D we don't have a monoculture in crypto.=0A> =0A> What happened was mostly = inertia from openssl being the first even=0A> semi-legal library for crypto= operations and huge demand for the=0A> functionality backed up with too li= ttle understanding of the risks.=0A> =0A> =0A> >=0A> >=0A> >=0A> > Rant off= . The summary is that good engineering is not applied where it must=0A> > = be for the public interest. That remains true even if the NSA actually=0A>= > snuck this code into the SSL implementation.=0A> >=0A> >=0A> >=0A> > On = Friday, April 11, 2014 2:22pm, "Dave Taht" =0A> said:= =0A> >=0A> >> http://www.wired.com/2014/04/heartbleedslesson/=0A> >>=0A> >>= And Dan Kaminisky writes about "Code in the Age of Cholera"=0A> >>=0A> >> = http://dankaminsky.com/2014/04/10/heartbleed/=0A> >>=0A> >>=0A> >>=0A> >> -= -=0A> >> Dave T=C3=A4ht=0A> >> ____________________________________________= ___=0A> >> Cerowrt-devel mailing list=0A> >> Cerowrt-devel@lists.bufferbloa= t.net=0A> >> https://lists.bufferbloat.net/listinfo/cerowrt-devel=0A> >>=0A= > =0A> =0A> =0A> --=0A> Dave T=C3=A4ht=0A> =0A> NSFW:=0A> https://w2.eff.or= g/Censorship/Internet_censorship_bills/russell_0296_indecent.article=0A> ------=_20140414192240000000_98534 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

All great = points.

=0A

 

=0A

Regarding the Orange Book for distributed/network systems= - the saddest part of that effort was that it was declared "done" when the= standards were published, even though the challenges of decentralized netw= orks of autonomously managed computers was already upon us.  The Orang= e Book was for individual computer systems that talked directly to end user= s and sat in physically secured locations, and did not apply to larger scal= e compositions of same.  It did not apply to PCs in users' hands, eith= er (even if not connected to a network).  It did lay out its assumptio= ns; but the temptation to believe its specifics applied when those assumpti= ons weren't met clearly overrode engineering and managerial sense.  Fo= r example, it was used to argue that Windows NT was "certified secure" acco= rding to the Orange Book. :-)

=0A

 =

=0A

 

=0A=0A



On Sunday, April 13, 2014 8:57pm, "Dave Taht" <dave.taht@= gmail.com> said:

=0A
=0A<= p style=3D"margin:0;padding:0;">> On Fri, Apr 11, 2014 at 12:43 PM, <= ;dpreed@reed.com> wrote:
> > I'm afraid it's not *just* under= funded. I reviewed the details of the code
> > involved and th= e fixes, and my conclusion is that even programmers of
> > secur= ity software have not learned how to think about design, testing, etc.
> > Especially the continuing use of C in a large shared process add= ress space
> > for writing protocols that are by definition in t= he "security kernel"
> > (according to the original definition) = of applications on which the public
> > depends.
> ><= br />> >
> >
> > Ever since I was part of the M= ultics Security Project (which was part of the
> > effort that p= roduced the Orange Book
> > http://csrc.nist.gov/publications/hi= story/dod85.pdf)
>
> Which I incidentally have read... and= fail to see how it applies well
> to networked systems.
> =
> > in the 80's, we've
> > known that security-based= code should not be exposed to user code and vice
> > versa. Ye= t the SSL libraries are linked in, in userspace, with the
> > ap= plication code.
>
> I note that I am glad that they are mo= stly dynamically linked in -
> something that wasn't the case for s= ome other crypto libs - because
> finding applications
> th= at linked statically would be even more difficult.
>
> And= I have seen some reports of people using heavily patched openssl
>= doing smarter things with memory allocation - why weren't those patches> pushed back into openssl?
>
> Well, because they w= ere held private and not publicly reviewed... and
> don't appear to= actually work, according to this:
>
> http://lekkertech.n= et/akamai.txt
>
> > Also, upgrades/changes to protocols= related to security (which always should
> > have been in place= on every end-to-end connection) should be reviewed *both
> > at= the protocol design level* and also at the *implementation level* because<= br />> > change creates risk. They should not be adopted blindly wit= hout serious
> > examination and pen-testing, yet this change ju= st was casually thrown in in
> > a patch release.
>
> Yes, change creates risk. Change also breeds change. Without change<= br />> there would be no progress.
>
> Should there be = an "office of critical infrastructure" or an
> underwriters labrato= ry examining and blessing each piece of software
> that runs as roo= t or handles money? Should some governmental or
> intergovernmental= group be putting a floor under (or a roof over) the
> people worki= ng on code deemed as critical infrastructure?
>
> heartble= ed was not detected by a coverity scan either.
>
> > I = suspect that even if it were well funded, the folks who deploy the
>= ; > technology would be slapdash at best.
>
> I agree. = Recently I was asked to come up with an "phone-home inside
> your b= usiness embedded device architecture" that would scale to
> million= s of users.
>
> I don't want the responsibility, nor do I = think any but hundreds of
> people working together could come up w= ith something that would let me
> sleep well at night - yet the mar= ket demand is there for something,
> anything, that even barely wor= ks.
>
> If I don't do the work, someone less qualified wil= l.
>
>
> > Remember the Y2K issue
> > I do. I also remember the response to it.
>
> htt= p://www.taht.net/~mtaht/uncle_bills_helicopter.html
>
> Th= e response to heartbleed has been incredibly heartening as to the
>= swiftness of repair - something that could not have happened in
> = anything other than the open source world. I have friends, however,
&g= t; that just went days without sleep, fixing it.
>
> I've = outlined my major concerns with TLS across our critical
> infrastru= cture going forward on my g+.
>
> > and the cost of
> > lazy thinking about dates. (I feel a little superior because in= 1968 Multics
> > standardized on a 72-bit hardware microsecond-= resolution hardware clock
> > because the designers actually tho= ught about long-lived systems (actually
>
> I agree that w= as far-thinking. I too worry about Y2036 and Y2038, and
> do my bes= t to make sure those aren't problems.
>
> it seems likely = some software will last even longer than that.
>
> > on= ly 56 bits of the original clock worked, but the hardware was not expected<= br />> > to last until the remaining bits could be added)).
>=
> Multics died. It would not have scaled to the internet. And cry= pto
> development and public deployment COULD have gone more hand i= n hand if
> it weren't basically illegal until 1994, and maybe befo= re then, some
> reasonable security could have been embedded deep i= nto more protocols.
>
> It would have been nice to have ha= d a secured X11 protocol, or
> kerberos made globally deployable, o= r things like mosh, in the 80s. In
> terms of more recent events, I= happen to have liked HIP.
>
> We don't know how to build = secured network systems to this day, that
> can survive an exposure= to hundreds of millions of potential
> attackers.
> >> >
> > The open source movement, unfortunately, made = a monoculture of the SSL
> > source code, so it's much more dang= erous and the vulnerable attack surface
> > of deployments is en= ormous.
>
> No it didn't. Alternatives to openssl exist - = gnutls, cyassl, and
> polarssl are also open source. Libraries that= merely implement
> primitives well like nettle, gmp, and libsodium= - all developed later
> - also exist.
>
> I am GL= AD we don't have a monoculture in crypto.
>
> What happene= d was mostly inertia from openssl being the first even
> semi-legal= library for crypto operations and huge demand for the
> functional= ity backed up with too little understanding of the risks.
>
&= gt;
> >
> >
> >
> > Rant off. = The summary is that good engineering is not applied where it must
>= ; > be for the public interest. That remains true even if the NSA actua= lly
> > snuck this code into the SSL implementation.
> &= gt;
> >
> >
> > On Friday, April 11, 2014 = 2:22pm, "Dave Taht" <dave.taht@gmail.com>
> said:
> &= gt;
> >> http://www.wired.com/2014/04/heartbleedslesson/
> >>
> >> And Dan Kaminisky writes about "Code in t= he Age of Cholera"
> >>
> >> http://dankaminsky= .com/2014/04/10/heartbleed/
> >>
> >>
>= >>
> >> --
> >> Dave T=C3=A4ht
>= >> _______________________________________________
> >>= ; Cerowrt-devel mailing list
> >> Cerowrt-devel@lists.bufferb= loat.net
> >> https://lists.bufferbloat.net/listinfo/cerowrt-= devel
> >>
>
>
>
> --
> Dave T=C3=A4ht
>
> NSFW:
> https://w2.eff.or= g/Censorship/Internet_censorship_bills/russell_0296_indecent.article
&= gt;

=0A
 ------=_20140414192240000000_98534--