<div dir="ltr"><div>iang wrote:<br><br></div>- start quote - <br><div>
While everyone's madly rushing around to fix their bits&bobs, I'd<br>
encouraged you all to be alert to any evidence of *damages* either<br>
anecdotally or more firm. By damages, I mean (a) rework needed to<br>
secure, and (b) actual breach into sites and theft of secrets, etc,<br>
leading to (c) theft of property/money/value etc.<br>
<br>
In risk analysis, we lean very heavily on firm indications of actual,<br>
tangible damages, because risk analysis is an uncertain tool and the<br>
security industry is a FUD-driven sector. Where we have actual<br>
experiences of lost money, time, destruction of property or whatever,<br>
this puts us in a much better position to predict what is worth spending<br>
money to protect.<br></div><div>- end quote - <br><br></div><div>There are now suggestions that Heartbleed has been exploited in the<br></div><div>wild:<br><br><a href="https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013">https://www.eff.org/deeplinks/2014/04/wild-heart-were-intelligence-agencies-using-heartbleed-november-2013</a><br>
<br></div><div>Even if this is not the case, I reject iang's (facetious, I know :-) suggestion.<br></div><div>Security flaws aren't the same as tsunamis. Reporting a power station's<br></div><div>possible vulnerability to the former doesn't make tsunamis more likely.<br>
</div><div>However, the wide dissemination of a previously unknown security <br></div><div>flaw *does* make its future attempted exploitation a near certainty.<br><br></div><div>pt<br><br></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote">On Wed, Apr 9, 2014 at 12:00 PM, <span dir="ltr"><<a href="mailto:cryptography-request@metzdowd.com" target="_blank">cryptography-request@metzdowd.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Send cryptography mailing list submissions to<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
<br>
To subscribe or unsubscribe via the World Wide Web, visit<br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" target="_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
or, via email, send a message with subject or body 'help' to<br>
<a href="mailto:cryptography-request@metzdowd.com">cryptography-request@metzdowd.com</a><br>
<br>
You can reach the person managing the list at<br>
<a href="mailto:cryptography-owner@metzdowd.com">cryptography-owner@metzdowd.com</a><br>
<br>
When replying, please edit your Subject line so it is more specific<br>
than "Re: Contents of cryptography digest..."<br>
<br>
<br>
Today's Topics:<br>
<br>
1. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
(ianG)<br>
2. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
(Jonathan Thornburg)<br>
3. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
(<a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a>)<br>
4. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
(<a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a>)<br>
5. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
(<a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a>)<br>
6. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
(ianG)<br>
7. Re: [cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL (ianG)<br>
8. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
(ianG)<br>
9. Re: TLS/DTLS Use Cases (Nico Williams)<br>
10. Re: [cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL (Nico Williams)<br>
11. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
(Tom Mitchell)<br>
12. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
(Jerry Leichter)<br>
13. Re: TLS/DTLS Use Cases (Bear)<br>
14. Re: OpenPGP and trust (Bear)<br>
15. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
(Dave Horsfall)<br>
16. Re: The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
(Paul Ferguson)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Tue, 08 Apr 2014 11:46:49 +0100<br>
From: ianG <<a href="mailto:iang@iang.org">iang@iang.org</a>><br>
To: <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>, <a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
Subject: Re: [Cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL<br>
Message-ID: <<a href="mailto:5343D399.8010702@iang.org">5343D399.8010702@iang.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 7/04/2014 22:53 pm, Edwin Chu wrote:<br>
> Hi<br>
><br>
> A latest story for OpenSSL<br>
><br>
> <a href="http://heartbleed.com/" target="_blank">http://heartbleed.com/</a><br>
><br>
> The Heartbleed Bug is a serious vulnerability in the popular OpenSSL<br>
> cryptographic software library. This weakness allows stealing the<br>
> information protected, under normal conditions, by the SSL/TLS<br>
> encryption used to secure the Internet. SSL/TLS provides<br>
> communication security and privacy over the Internet for<br>
> applications such as web, email, instant messaging (IM) and some<br>
> virtual private networks (VPNs).<br>
><br>
> The Heartbleed bug allows anyone on the Internet to read the memory<br>
> of the systems protected by the vulnerable versions of the OpenSSL<br>
> software. This compromises the secret keys used to identify the<br>
> service providers and to encrypt the traffic, the names and<br>
> passwords of the users and the actual content. This allows attackers<br>
> to eavesdrop communications, steal data directly from the services<br>
> and users and to impersonate services and users.<br>
<br>
<br>
We have here a rare case of a broad break in a security protocol leading<br>
to compromise of keys.<br>
<br>
While everyone's madly rushing around to fix their bits&bobs, I'd<br>
encouraged you all to be alert to any evidence of *damages* either<br>
anecdotally or more firm. By damages, I mean (a) rework needed to<br>
secure, and (b) actual breach into sites and theft of secrets, etc,<br>
leading to (c) theft of property/money/value etc.<br>
<br>
In risk analysis, we lean very heavily on firm indications of actual,<br>
tangible damages, because risk analysis is an uncertain tool and the<br>
security industry is a FUD-driven sector. Where we have actual<br>
experiences of lost money, time, destruction of property or whatever,<br>
this puts us in a much better position to predict what is worth spending<br>
money to protect.<br>
<br>
E.g., if we cannot show any damages from this breach, it isn't worth<br>
spending a penny on it to fix! Yes, that's outrageous and will be<br>
widely ignored ... but it is economically and scientifically sound, at<br>
some level.<br>
<br>
I maintain a risk history here: <a href="http://wiki.cacert.org/Risk/History" target="_blank">http://wiki.cacert.org/Risk/History</a> for<br>
the CA field, so if anyone can find any real damages effecting the CA<br>
world, let me know!<br>
<br>
<br>
<br>
iang<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 2<br>
Date: Tue, 8 Apr 2014 13:12:25 -0400<br>
From: Jonathan Thornburg <<a href="mailto:jthorn@astro.indiana.edu">jthorn@astro.indiana.edu</a>><br>
To: <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>, <a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
Subject: Re: [Cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL<br>
Message-ID: <<a href="mailto:20140408171208.GA927@copper.astro.indiana.edu">20140408171208.GA927@copper.astro.indiana.edu</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Tue, Apr 08, 2014 at 11:46:49AM +0100, ianG wrote:<br>
> While everyone's madly rushing around to fix their bits&bobs, I'd<br>
> encouraged you all to be alert to any evidence of *damages* either<br>
> anecdotally or more firm. By damages, I mean (a) rework needed to<br>
> secure, and (b) actual breach into sites and theft of secrets, etc,<br>
> leading to (c) theft of property/money/value etc.<br>
><br>
[[...]]<br>
><br>
> E.g., if we cannot show any damages from this breach, it isn't worth<br>
> spending a penny on it to fix!<br>
<br>
This analysis appears to say that it's not worth spending money to<br>
fix a hole (bug) unless either money has already been spent or damages<br>
have *already* occured. This ignores possible or probable (or even<br>
certain!) *future* damages if no rework has yet happened.<br>
<br>
This seems like a flawed risk analysis to me.<br>
<br>
In particular, this analysis could be used to argue against spending any<br>
money trying to reduce risk or damages from rare events which haven't<br>
happened yet. For example, as of January 1, 2011 (= 69 days before the<br>
Fukushima Daiichi disaster), this analysis would have said that since no<br>
nuclear reactor in the world has ever been damaged by a tsunami (a true<br>
statement on that date), it isn't worth spending any money trying to<br>
secure nuclear reactors against tsunami damage.<br>
<br>
--<br>
-- "Jonathan Thornburg [remove -animal to reply]" <<a href="mailto:jthorn@astro.indiana-zebra.edu">jthorn@astro.indiana-zebra.edu</a>><br>
Dept of Astronomy & IUCSS, Indiana University, Bloomington, Indiana, USA<br>
"There was of course no way of knowing whether you were being watched<br>
at any given moment. How often, or on what system, the Thought Police<br>
plugged in on any individual wire was guesswork. It was even conceivable<br>
that they watched everybody all the time." -- George Orwell, "1984"<br>
<br>
<br>
------------------------------<br>
<br>
Message: 3<br>
Date: Tue, 08 Apr 2014 21:18:52 +0200<br>
From: <a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a><br>
To: ianG <<a href="mailto:iang@iang.org">iang@iang.org</a>>, <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>,<br>
<a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
Subject: Re: [Cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL<br>
Message-ID: <1316776432.92614.1396984732457.JavaMail.www@wwinf8313><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
> Message du 08/04/14 18:44<br>
> De : "ianG"<br>
><br>
> E.g., if we cannot show any damages from this breach, it isn't worth<br>
> spending a penny on it to fix! Yes, that's outrageous and will be<br>
> widely ignored ... but it is economically and scientifically sound, at<br>
> some level.<br>
><br>
<br>
So, let's wait until another 40 million credit cards are stolen, then we prove this method was used exactly, then we will try to fix it in all deployments ... yeah, seems reasonable.<br>
<br>
<br>
------------------------------<br>
<br>
Message: 4<br>
Date: Tue, 08 Apr 2014 22:02:24 +0200<br>
From: <a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a><br>
To: ianG <<a href="mailto:iang@iang.org">iang@iang.org</a>>, <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>,<br>
<a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
Subject: Re: [Cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL<br>
Message-ID: <501480181.95836.1396987343949.JavaMail.www@wwinf8313><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
> Message du 08/04/14 21:42<br>
> De : "ianG"<br>
> A : <a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a>, <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>, <a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
> Copie ? :<br>
> Objet : Re: [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
><br>
> On 8/04/2014 20:18 pm, <a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a> wrote:<br>
> >> Message du 08/04/14 18:44<br>
> >> De : "ianG"<br>
> >><br>
> >> E.g., if we cannot show any damages from this breach, it isn't worth<br>
> >> spending a penny on it to fix! Yes, that's outrageous and will be<br>
> >> widely ignored ... but it is economically and scientifically sound, at<br>
> >> some level.<br>
> >><br>
> ><br>
> > So, let's wait until another 40 million credit cards are stolen, then we prove this method was used exactly, then we will try to fix it in all deployments ... yeah, seems reasonable.<br>
><br>
><br>
> Well, be blind if you like. But 40 million stolen credit cards are<br>
> measurable, are damages, and are directly relatable by statistical<br>
> models to theft damages.<br>
><br>
> My advice is when you have a number like 40m in front of you, then you<br>
> should DO SOMETHING. Spend a penny, dude!<br>
><br>
<br>
Your first advice is extremely dangerous and preposterous, I was being sardonic in my comment, but let's get this straight.<br>
<br>
You said you control a quite famous bug list. I should not ask this here, but considering the situation we found ourselves regarding encryption infrastructure abuse from the part of US government ... I'm just curious and can't resist it.<br>
<br>
How much are you being paid to give such dangerous and preposterous advice? Or, who are your handlers?<br>
<br>
<br>
------------------------------<br>
<br>
Message: 5<br>
Date: Tue, 08 Apr 2014 22:35:46 +0200<br>
From: <a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a><br>
To: ianG <<a href="mailto:iang@iang.org">iang@iang.org</a>>, <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>,<br>
<a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
Subject: Re: [Cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL<br>
Message-ID: <1903091161.97701.1396989346005.JavaMail.www@wwinf8313><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
<br>
<br>
> Message du 08/04/14 22:18<br>
> De : "ianG"<br>
> A : <a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a>, <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>, <a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
> Copie ? :<br>
> Objet : Re: [Cryptography] The Heartbleed Bug is a serious vulnerability in OpenSSL<br>
><br>
<br>
> On 8/04/2014 21:02 pm, <a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a> wrote:<br>
><br>
> > You said you control a quite famous bug list.<br>
><br>
><br>
> Not me, you might be thinking of the other iang?<br>
><br>
> > I should not ask this here, but considering the situation we found ourselves regarding encryption infrastructure abuse from the part of US government ... I'm just curious and can't resist it.<br>
><br>
> the shoe turns, the knife fits...<br>
><br>
> > How much are you being paid to give such dangerous and preposterous advice? Or, who are your handlers?<br>
><br>
><br>
> Nothing, nix. I wish. Please!?<br>
><br>
> At this stage it is customary to post a bitcoin address but I don't even<br>
> have one of them....<br>
><br>
><br>
<br>
Interesting way to try avoid answering about the subject directly. You should know that bad advice is noticed and sooner than you may think, your reputation falls between your fingers like sand and nobody will pay attention to your crazy rants anymore.<br>
<br>
Which is a good payout for someone that sells his soul for so little.<br>
<br>
Regarding automated exploit tools that will be used to cause enormous damage related to this bug, well they are already being devised and are in their earliest stages, but perfectly workable:<br>
<br>
<a href="https://www.mattslifebytes.com/?p=533" target="_blank">https://www.mattslifebytes.com/?p=533</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 6<br>
Date: Tue, 08 Apr 2014 20:42:10 +0100<br>
From: ianG <<a href="mailto:iang@iang.org">iang@iang.org</a>><br>
To: <a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a>, <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>,<br>
<a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
Subject: Re: [Cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL<br>
Message-ID: <<a href="mailto:53445112.9090904@iang.org">53445112.9090904@iang.org</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On 8/04/2014 20:18 pm, <a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a> wrote:<br>
>> Message du 08/04/14 18:44<br>
>> De : "ianG"<br>
>><br>
>> E.g., if we cannot show any damages from this breach, it isn't worth<br>
>> spending a penny on it to fix! Yes, that's outrageous and will be<br>
>> widely ignored ... but it is economically and scientifically sound, at<br>
>> some level.<br>
>><br>
><br>
> So, let's wait until another 40 million credit cards are stolen, then we prove this method was used exactly, then we will try to fix it in all deployments ... yeah, seems reasonable.<br>
<br>
<br>
Well, be blind if you like. But 40 million stolen credit cards are<br>
measurable, are damages, and are directly relatable by statistical<br>
models to theft damages.<br>
<br>
My advice is when you have a number like 40m in front of you, then you<br>
should DO SOMETHING. Spend a penny, dude!<br>
<br>
<br>
<br>
iang<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 7<br>
Date: Tue, 08 Apr 2014 21:10:33 +0100<br>
From: ianG <<a href="mailto:iang@iang.org">iang@iang.org</a>><br>
To: Nico Williams <<a href="mailto:nico@cryptonector.com">nico@cryptonector.com</a>>, Jonathan Thornburg<br>
<<a href="mailto:jthorn@astro.indiana.edu">jthorn@astro.indiana.edu</a>><br>
Cc: <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>, <a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
Subject: Re: [Cryptography] [cryptography] The Heartbleed Bug is a<br>
serious vulnerability in OpenSSL<br>
Message-ID: <<a href="mailto:534457B9.8040006@iang.org">534457B9.8040006@iang.org</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
On 8/04/2014 20:33 pm, Nico Williams wrote:<br>
> On Tue, Apr 08, 2014 at 01:12:25PM -0400, Jonathan Thornburg wrote:<br>
>> On Tue, Apr 08, 2014 at 11:46:49AM +0100, ianG wrote:<br>
>>> While everyone's madly rushing around to fix their bits&bobs, I'd<br>
>>> encouraged you all to be alert to any evidence of *damages* either<br>
>>> anecdotally or more firm. By damages, I mean (a) rework needed to<br>
>>> secure, and (b) actual breach into sites and theft of secrets, etc,<br>
>>> leading to (c) theft of property/money/value etc.<br>
>>><br>
>> [[...]]<br>
>>><br>
>>> E.g., if we cannot show any damages from this breach, it isn't worth<br>
>>> spending a penny on it to fix!<br>
>><br>
>> This analysis appears to say that it's not worth spending money to<br>
>> fix a hole (bug) unless either money has already been spent or damages<br>
>> have *already* occured. This ignores possible or probable (or even<br>
>> certain!) *future* damages if no rework has yet happened.<br>
><br>
> The first part (gather data) is OK. The second I thought was said<br>
> facetiously. It is flawed, indeed, but it's also true that people have<br>
> a hard time weighing intangibles.<br>
<br>
<br>
Right, exactly. Thought experiment.<br>
<br>
<br>
> I don't know how we can measure anything here. How do you know if your<br>
> private keys were stolen via this bug? It should be possible to<br>
> establish whether key theft was feasible, but establishing whether they<br>
> were stolen might require evidence of use of stolen keys, and that might<br>
> be very difficult to come by.<br>
<br>
<br>
Precisely, that is the question. What happens if we wait a year and<br>
nothing .. happens?<br>
<br>
What happened with the Debian random plonk? Nothing, that I ever saw in<br>
terms of measurable damages. The BEAST thing? Twitter, was it?<br>
<br>
What happened with PKI? We (I) watched and watched and watched ... and<br>
it wasn't until about 2011 that something finally popped up that was a<br>
measurable incident of damages, 512bit RSA keys being crunched from memory.<br>
<br>
That's 16 years! Does that mean (a) PKI was so good that it clobbered<br>
all attacks, or (b) PKI was so unnecessary because there was nobody<br>
interested in attacks?<br>
<br>
Dan Geer once said on this list [0]:<br>
<br>
"The design goal for any security system is that the number of<br>
failures is small but non-zero, i.e., N>0. If the number of failures is<br>
zero, there is no way to disambiguate good luck from spending too much.<br>
Calibration requires differing outcomes."<br>
<br>
We now have what amounts to a *fantastic* opportunity <ghoulish laugh><br>
to clarify delta. We've got a system wide breach, huge statistics, and<br>
it's identifiable in terms of which servers are vulnerable.<br>
<br>
Hypothesize: Let the number of attacked servers be 1% of population of<br>
vulnerable servers. Let our detection rate be 1%. Multiply. That<br>
means 1 in 10,000 attacked servers. Let's say we have 1m vulnerable<br>
servers.<br>
<br>
We should detect 100 attacks over the next period.<br>
<br>
We should detect something!<br>
<br>
<br>
> We shouldn't wait for evidence of use of<br>
> stolen keys!<br>
<br>
<br>
(Well, right. I doubt we can actually tell anyone to wait.)<br>
<br>
> Nico<br>
<br>
<br>
<br>
<br>
iang<br>
<br>
<br>
<br>
[0] <a href="http://financialcryptography.com/mt/archives/001255.html" target="_blank">http://financialcryptography.com/mt/archives/001255.html</a><br>
<br>
<br>
------------------------------<br>
<br>
Message: 8<br>
Date: Tue, 08 Apr 2014 21:17:59 +0100<br>
From: ianG <<a href="mailto:iang@iang.org">iang@iang.org</a>><br>
To: <a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a>, <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>,<br>
<a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
Subject: Re: [Cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL<br>
Message-ID: <<a href="mailto:53445977.9030904@iang.org">53445977.9030904@iang.org</a>><br>
Content-Type: text/plain; charset=UTF-8<br>
<br>
On 8/04/2014 21:02 pm, <a href="mailto:tpb-crypto@laposte.net">tpb-crypto@laposte.net</a> wrote:<br>
<br>
> You said you control a quite famous bug list.<br>
<br>
<br>
Not me, you might be thinking of the other iang?<br>
<br>
> I should not ask this here, but considering the situation we found ourselves regarding encryption infrastructure abuse from the part of US government ... I'm just curious and can't resist it.<br>
<br>
the shoe turns, the knife fits...<br>
<br>
> How much are you being paid to give such dangerous and preposterous advice? Or, who are your handlers?<br>
<br>
<br>
Nothing, nix. I wish. Please!?<br>
<br>
At this stage it is customary to post a bitcoin address but I don't even<br>
have one of them....<br>
<br>
<br>
<br>
iang<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 9<br>
Date: Tue, 8 Apr 2014 14:21:20 -0500<br>
From: Nico Williams <<a href="mailto:nico@cryptonector.com">nico@cryptonector.com</a>><br>
To: Bear <<a href="mailto:bear@sonic.net">bear@sonic.net</a>><br>
Cc: Bill Stewart <<a href="mailto:billstewart@pobox.com">billstewart@pobox.com</a>>, Cryptography List<br>
<<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>><br>
Subject: Re: [Cryptography] TLS/DTLS Use Cases<br>
Message-ID: <20140408192118.GI7962@localhost><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Tue, Apr 08, 2014 at 12:12:54PM -0700, Bear wrote:<br>
> On Sat, 2014-04-05 at 18:23 -0500, Nico Williams wrote:<br>
> > Also, HTTP is just about the worst datagram protocol ever. There's no<br>
> > XID, so responses have to be sent in the same order as requests over<br>
> > any one keptalive TCP connection. Yuck. (When I've brought this up<br>
> > in the context of HTTPbis I've been told to go away.)<br>
><br>
> To be fair, keep-alive was not part of the design. Http was initially<br>
> a completely stateless protocol, and actually a fairly well designed<br>
> one. The reason keep-alive is not well supported is because it's got<br>
> nothing to do with the original design and was bolted on as an<br>
> afterthought.<br>
<br>
It was added as a new minor version of the protocol. That would tend to<br>
indicate (to me anyways) that it wasn't an afterthought.<br>
<br>
> Is there a take-home lesson there? Only that if we engage in elegant<br>
> design we should not trust those who come after us not to screw it up.<br>
<br>
Are you saying that HTTP/1.0 was elegant? Well, I suppose it was, if we<br>
ignore all the complexity of text, line-oriented headers (the two ways<br>
to express multiple header values, continuation lines, verbosity). The<br>
elegant part is the REST/CRUD aspects, IMO.<br>
<br>
Anyways, the part that interests me here is that there's still no<br>
interest in fixing this, particularly when HTTP/2.0 is so much about<br>
performance. Perhaps the lesson is that we don't learn from our<br>
lessons.<br>
<br>
(I haven't checked recently, so it's possible that this has been<br>
addressed since. I sure hope so!)<br>
<br>
Nico<br>
--<br>
<br>
<br>
------------------------------<br>
<br>
Message: 10<br>
Date: Tue, 8 Apr 2014 14:33:42 -0500<br>
From: Nico Williams <<a href="mailto:nico@cryptonector.com">nico@cryptonector.com</a>><br>
To: Jonathan Thornburg <<a href="mailto:jthorn@astro.indiana.edu">jthorn@astro.indiana.edu</a>><br>
Cc: <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>, <a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
Subject: Re: [Cryptography] [cryptography] The Heartbleed Bug is a<br>
serious vulnerability in OpenSSL<br>
Message-ID: <20140408193339.GJ7962@localhost><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Tue, Apr 08, 2014 at 01:12:25PM -0400, Jonathan Thornburg wrote:<br>
> On Tue, Apr 08, 2014 at 11:46:49AM +0100, ianG wrote:<br>
> > While everyone's madly rushing around to fix their bits&bobs, I'd<br>
> > encouraged you all to be alert to any evidence of *damages* either<br>
> > anecdotally or more firm. By damages, I mean (a) rework needed to<br>
> > secure, and (b) actual breach into sites and theft of secrets, etc,<br>
> > leading to (c) theft of property/money/value etc.<br>
> ><br>
> [[...]]<br>
> ><br>
> > E.g., if we cannot show any damages from this breach, it isn't worth<br>
> > spending a penny on it to fix!<br>
><br>
> This analysis appears to say that it's not worth spending money to<br>
> fix a hole (bug) unless either money has already been spent or damages<br>
> have *already* occured. This ignores possible or probable (or even<br>
> certain!) *future* damages if no rework has yet happened.<br>
<br>
The first part (gather data) is OK. The second I thought was said<br>
facetiously. It is flawed, indeed, but it's also true that people have<br>
a hard time weighing intangibles.<br>
<br>
I don't know how we can measure anything here. How do you know if your<br>
private keys were stolen via this bug? It should be possible to<br>
establish whether key theft was feasible, but establishing whether they<br>
were stolen might require evidence of use of stolen keys, and that might<br>
be very difficult to come by. We shouldn't wait for evidence of use of<br>
stolen keys!<br>
<br>
Nico<br>
--<br>
<br>
<br>
------------------------------<br>
<br>
Message: 11<br>
Date: Tue, 8 Apr 2014 15:32:11 -0700<br>
From: Tom Mitchell <<a href="mailto:mitch@niftyegg.com">mitch@niftyegg.com</a>><br>
To: "<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>" <<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>><br>
Cc: "<a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a>" <<a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a>><br>
Subject: Re: [Cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL<br>
Message-ID:<br>
<CAAMy4URAE7WiMZud3HjLh1n=d54=<a href="mailto:1%2BpgOjT%2BZdquXapHpYH2rQ@mail.gmail.com">1+pgOjT+ZdquXapHpYH2rQ@mail.gmail.com</a>><br>
Content-Type: text/plain; charset="iso-8859-1"<br>
<br>
On Tue, Apr 8, 2014 at 10:12 AM, Jonathan Thornburg <<br>
<a href="mailto:jthorn@astro.indiana.edu">jthorn@astro.indiana.edu</a>> wrote:<br>
<br>
> On Tue, Apr 08, 2014 at 11:46:49AM +0100, ianG wrote:<br>
> > While everyone's madly rushing around to fix their bits&bobs, I'd<br>
> > encouraged you all to be alert to any evidence of *damages*<br>
><br>
<br>
<br>
> [[...]]<br>
> ><br>
> > E.g., if we cannot show any damages from this breach, it isn't worth<br>
> > spending a penny on it to fix!<br>
><br>
> This analysis appears to say that it's not worth spending money to<br>
> fix a hole (bug) unless either money has already been spent or damages<br>
> have *already* occured.<br>
><br>
<br>
May I add that the analysis must take into account the ability<br>
to detect an exploit and the value of the exploit over time.<br>
This might be very hard to detect.<br>
<br>
To me the bigger you are or more interesting you are the<br>
more important it is to fix. Time makes exploited data like<br>
a public key a risk for the life of the key and perhaps longer.<br>
<br>
This one is especially nasty in that it may have exposed any<br>
data visible to the ssl-bug compromised process. In the case of<br>
a private key escape the ability to detect future abuse is near zero.<br>
<br>
Fixing this is important. Less so for me but astoundingly so<br>
for any host that a CSS might pull from or any host that transacts<br>
money. To some degree this is a two end problem so both<br>
ends need to be aware.<br>
<br>
I will be installing patched code as quickly as it shows up.<br>
<br>
--<br>
T o m M i t c h e l l<br>
-------------- next part --------------<br>
An HTML attachment was scrubbed...<br>
URL: <<a href="http://www.metzdowd.com/pipermail/cryptography/attachments/20140408/caa09cca/attachment-0001.html" target="_blank">http://www.metzdowd.com/pipermail/cryptography/attachments/20140408/caa09cca/attachment-0001.html</a>><br>
<br>
------------------------------<br>
<br>
Message: 12<br>
Date: Tue, 8 Apr 2014 20:22:02 -0400<br>
From: Jerry Leichter <<a href="mailto:leichter@lrw.com">leichter@lrw.com</a>><br>
To: Jonathan Thornburg <<a href="mailto:jthorn@astro.indiana.edu">jthorn@astro.indiana.edu</a>><br>
Cc: <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>, <a href="mailto:cryptography@randombit.net">cryptography@randombit.net</a><br>
Subject: Re: [Cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL<br>
Message-ID: <<a href="mailto:2B02EDFC-609A-4255-A3EC-182E74334104@lrw.com">2B02EDFC-609A-4255-A3EC-182E74334104@lrw.com</a>><br>
Content-Type: text/plain; charset=us-ascii<br>
<br>
On Apr 8, 2014, at 1:12 PM, Jonathan Thornburg <<a href="mailto:jthorn@astro.indiana.edu">jthorn@astro.indiana.edu</a>> wrote:<br>
>> E.g., if we cannot show any damages from this breach, it isn't worth<br>
>> spending a penny on it to fix!<br>
><br>
> This analysis appears to say that it's not worth spending money to<br>
> fix a hole (bug) unless either money has already been spent or damages<br>
> have *already* occured. This ignores possible or probable (or even<br>
> certain!) *future* damages if no rework has yet happened.<br>
You're misreading what Iang wrote. To say one should not fix a *potential problem that hasn't yet occurred* because we can't prove it's caused any losses yet is absurd. Before the problem actually occurs, all we have to go on is our estimates of the possible cost, and we have to anticipate those costs.<br>
<br>
However, in the case of a problem that *has actually occurred*, if you *still* can't show any loses - then you have to seriously ask whether the problem is worth fixing, or whether it isn't really a "problem" at all.<br>
<br>
For example, there are all sorts of plausible-sounding arguments that if people are exposed to signals at the frequencies and power levels used for WiFi then various bad things will happen to them. Well ... we've exposed many millions of people to such signals for extended periods of time, and the evidence is that the "problem" - exposure to RF - doesn't produce any real costs. The research that shows that is valuable; and documentation of the actual costs (or lack thereof) for various classes of software bugs would *also* be valuable. Without such research an documentation, our risk analyses are lacking a solid foundation.<br>
-- Jerry<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 13<br>
Date: Tue, 08 Apr 2014 12:12:54 -0700<br>
From: Bear <<a href="mailto:bear@sonic.net">bear@sonic.net</a>><br>
To: Nico Williams <<a href="mailto:nico@cryptonector.com">nico@cryptonector.com</a>><br>
Cc: Bill Stewart <<a href="mailto:billstewart@pobox.com">billstewart@pobox.com</a>>, Cryptography List<br>
<<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>><br>
Subject: Re: [Cryptography] TLS/DTLS Use Cases<br>
Message-ID: <<a href="mailto:1396984374.22160.3.camel@excessive.dsl.static.sonic.net">1396984374.22160.3.camel@excessive.dsl.static.sonic.net</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
On Sat, 2014-04-05 at 18:23 -0500, Nico Williams wrote:<br>
<br>
> Also, HTTP is just about the worst datagram protocol ever. There's no<br>
> XID, so responses have to be sent in the same order as requests over<br>
> any one keptalive TCP connection. Yuck. (When I've brought this up<br>
> in the context of HTTPbis I've been told to go away.)<br>
><br>
<br>
To be fair, keep-alive was not part of the design. Http was initially<br>
a completely stateless protocol, and actually a fairly well designed<br>
one. The reason keep-alive is not well supported is because it's got<br>
nothing to do with the original design and was bolted on as an<br>
afterthought.<br>
<br>
Is there a take-home lesson there? Only that if we engage in elegant<br>
design we should not trust those who come after us not to screw it up.<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 14<br>
Date: Tue, 08 Apr 2014 13:21:48 -0700<br>
From: Bear <<a href="mailto:bear@sonic.net">bear@sonic.net</a>><br>
To: Peter Gutmann <<a href="mailto:pgut001@cs.auckland.ac.nz">pgut001@cs.auckland.ac.nz</a>><br>
Cc: <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>, <a href="mailto:crypto@senderek.ie">crypto@senderek.ie</a><br>
Subject: Re: [Cryptography] OpenPGP and trust<br>
Message-ID: <<a href="mailto:1396988508.22160.39.camel@excessive.dsl.static.sonic.net">1396988508.22160.39.camel@excessive.dsl.static.sonic.net</a>><br>
Content-Type: text/plain; charset="UTF-8"<br>
<br>
On Sun, 2014-04-06 at 20:59 +1200, Peter Gutmann wrote:<br>
> Ralf Senderek <<a href="mailto:crypto@senderek.ie">crypto@senderek.ie</a>> writes:<br>
><br>
> >You can easily solve this problem by obtaining a certificate that verifies in<br>
> >almost all browsers for a few bucks per year,<br>
><br>
> And the neat thing is that any bad guy can buy a cert from the same CA you<br>
> bought your one from (or any other commercial CA of their choice), set up a<br>
> dummy server, and all your friends will connect thinking it's the real thing.<br>
> The false sense of security created by the cert will make things much easier<br>
> for them.<br>
<br>
For a while now I've been considering 'continuity' as an (adhoc)<br>
approach to security. It could be a supplement to the web-of-trust<br>
or a supplement to X.509, or even something that provides a certain<br>
level of trust on its own for particular purposes.<br>
<br>
In a continuity-based system, you'd be associating each key with<br>
an entity. An entity presenting a different key/cert, without some<br>
continuity measure such as new-key-signed-by-old plus revocation<br>
of old key, should not be assumed to be the same entity regardless<br>
of what they or their cert claims.<br>
<br>
And revocation of old key is a very important part of it, because<br>
with revocation you get a situation where an impersonator is forced<br>
to either use a key that the impersonated person can decrypt (leaving<br>
possible evidence) or break the impersonated person's key (leaving<br>
possible evidence).<br>
<br>
Anyway this is the sort of thing that approach would address. You<br>
have bought a cert for your site, some other guy has bought a<br>
cert for his site, and when people log on, they get a cert - but<br>
not the one they've been getting up to that moment. This is a<br>
continuity violation, and absolutely nothing that their software<br>
knows is associated with your site should be working for or with<br>
this other site which has a different key.<br>
<br>
My vision of UI for this would be that each site should come up<br>
next to (or under, or over) a banner that lists previous interactions<br>
with that site, and that a completely new previously-unseen cert,<br>
regardless of who it's signed by or what it says, should come up<br>
with a banner that says,<br>
<br>
"YOU HAVE NEVER ACCESSED THIS SITE BEFORE TODAY - NEW KEY HAS NO<br>
PREVIOUS HISTORY."<br>
<br>
Obviously if the user "knows otherwise" there's something wrong.<br>
If it's important, and there's no continuity, then the user should<br>
be making a phone call and getting his bank to verify that yes, it<br>
did in fact change its key since last time he connected. The bank<br>
doesn't want the hassle of answering phone calls? Then it should<br>
do the continuity dance, sign the new cert with the old one, and<br>
revoke.<br>
<br>
<br>
<br>
<br>
<br>
------------------------------<br>
<br>
Message: 15<br>
Date: Wed, 9 Apr 2014 12:12:22 +1000 (EST)<br>
From: Dave Horsfall <<a href="mailto:dave@horsfall.org">dave@horsfall.org</a>><br>
To: Cryptography List <<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a>><br>
Subject: Re: [Cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL<br>
Message-ID: <<a href="mailto:alpine.BSF.2.00.1404091208370.739@aneurin.horsfall.org">alpine.BSF.2.00.1404091208370.739@aneurin.horsfall.org</a>><br>
Content-Type: TEXT/PLAIN; charset=US-ASCII<br>
<br>
Is there an echo here somewhere? Three and counting...<br>
<br>
-- Dave, remebering the Johnny Cash lyrice<br>
<br>
<br>
------------------------------<br>
<br>
Message: 16<br>
Date: Tue, 08 Apr 2014 20:15:02 -0700<br>
From: Paul Ferguson <<a href="mailto:fergdawgster@mykolab.com">fergdawgster@mykolab.com</a>><br>
To: ianG <<a href="mailto:iang@iang.org">iang@iang.org</a>><br>
Cc: <a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
Subject: Re: [Cryptography] The Heartbleed Bug is a serious<br>
vulnerability in OpenSSL<br>
Message-ID: <<a href="mailto:5344BB36.7070207@mykolab.com">5344BB36.7070207@mykolab.com</a>><br>
Content-Type: text/plain; charset=ISO-8859-1<br>
<br>
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA256<br>
<br>
Ian,<br>
<br>
On 4/8/2014 3:46 AM, ianG wrote:<br>
<br>
><br>
> I maintain a risk history here: <a href="http://wiki.cacert.org/Risk/History" target="_blank">http://wiki.cacert.org/Risk/History</a><br>
> for the CA field, so if anyone can find any real damages effecting<br>
> the CA world, let me know!<br>
><br>
<br>
Thank you very much for providing a pointer to the CAcert Risk History<br>
page -- that is extraordinarily useful. :-)<br>
<br>
Cheers,<br>
<br>
- - ferg<br>
<br>
- --<br>
Paul Ferguson<br>
VP Threat Intelligence, IID<br>
PGP Public Key ID: 0x54DC85B2<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v2.0.22 (MingW32)<br>
Comment: Using GnuPG with Thunderbird - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iF4EAREIAAYFAlNEuzYACgkQKJasdVTchbKlzgD+MdDTtiTDBwyWBq2DTuE7OTAn<br>
xCBrX+KFkKxabmxLVeQA/A/YzQ+loOqsQAjKuGVImDKBuNrDItH47yZergLhDT+X<br>
=nEzj<br>
-----END PGP SIGNATURE-----<br>
<br>
<br>
------------------------------<br>
<br>
_______________________________________________<br>
cryptography mailing list<br>
<a href="mailto:cryptography@metzdowd.com">cryptography@metzdowd.com</a><br>
<a href="http://www.metzdowd.com/mailman/listinfo/cryptography" target="_blank">http://www.metzdowd.com/mailman/listinfo/cryptography</a><br>
<br>
End of cryptography Digest, Vol 12, Issue 9<br>
*******************************************<br>
</blockquote></div><br></div>