Re: On the matter of OpenBSD breaking embargos (KRACK)
On Tue, 19 Jun 2018 09:30:05 -0600 > > > > > ps. Disable Intel Hyper-Threading where not needed, until we all > > > know more. > > > > Is it safer to use bsd.sp for the time being? > > No, a better solution is coming. And in snapshots already. Thankyou for enabling us to patch ASAP.
Re: On the matter of OpenBSD breaking embargos (KRACK)
Kevin Chadwick wrote: > On Fri, 15 Jun 2018 17:28:14 -0600 > > > > ps. Disable Intel Hyper-Threading where not needed, until we all know > > more. > > Is it safer to use bsd.sp for the time being? No, a better solution is coming. And in snapshots already.
Re: On the matter of OpenBSD breaking embargos (KRACK)
On Fri, 15 Jun 2018 17:28:14 -0600 > ps. Disable Intel Hyper-Threading where not needed, until we all know > more. Is it safer to use bsd.sp for the time being?
Re: On the matter of OpenBSD breaking embargos (KRACK)
Thank you Stefan and Mathy for setting the record straight. This archive is relevant as a followup to comments Gordon Tetlows (FreeBSD Security Officer) made in an audience a week ago (I honestly didn't know who/what until a few hours ago). However, this reconstruction is because others have also been playing the "OpenBSD breaks embargos" meme, to gain favour for their projects, disadvantage OpenBSD, and whatever other reasons they may have. Now the facts undermine their claims. I'd like to mention I made an error reconstructing the timeline below; KRACK happened in 2017, not 2018. ps. Disable Intel Hyper-Threading where not needed, until we all know more. Stefan Sperling wrote: > This a copy of internal discussion between me, Theo, and Mathy Vanhoef > about KRACK, from the initial message I received from Mathy, up to today. > > I am making this public with Theos's and Mathy's consent, without redaction. > I have annotated quoted blocks with names to make the discussion a bit > easier to follow. > > Mathy's approval of my commit is documented below. > If you hear people claiming OpenBSD (and by extension, me personally) broke > the KRACK embargo, then please point them to this so they see I was given > permission to commit the fix. If I remain a villain in their minds after > reading this, I won't try to convince them any further. > I don't do shouting matches. > > --- Forwarded Message > > Date: Fri, 15 Jun 2018 22:32:15 +0200 > From: Mathy Vanhoef > To: Stefan Sperling > Subject: Re: [dera...@openbsd.org: Re: Key reinstallation attack against > WPA1/2 resulting in nonce reuse]] > User-Agent: Roundcube Webmail/1.2.9 > > > [mathy] > > > The security advisory released on 30 Aug 2018 wasn't explicitly > > > agreed, > > > only releasing the silent patch. So this was unexpected. Though I > > > don't > > > recall which details were included in this early advisory. > > [stsp] > > For the record, this is the initial commit to -current: > > https://marc.info/?l=openbsd-cvs=150294967228872=2 > > > > With diff: > > https://github.com/openbsd/src/commit/2e40dd69ac29d6a858309bce0e05e65eec66648f#diff-4cf043b0a21146c45238a2c964206909 > > > > To reiterate, we had no idea where information about the bug was going to > > spread between Aug 14 and Oct 16. Given the wide impact, the many parties > > involved, and the long time frame of an additional 2 months, a leak into > > circles which would try to abuse this information was possible. > > The process was now trundling outside your own control and, in my opinion, > > exceeding reasonable risk dimensions. > > > > Theo and I didn't want to wait much longer, knowing if users running > > OpenBSD > > releases got targeted e.g. by industry/government insiders or as a result > > of leaks from the embargo process, we would be partly responsible. > > We carefully issued an errata on Aug 30 (the originally agreed time > > frame). > > No impact beyond OpenBSD could be discerned from our errata patch. > > The errata description was designed to imply an implementation-specific > > bug. > > https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/027_net80211_replay.patch.sig > > > > Your name was kept off all of this to avoid drawing attention to your > > research in this context. Since we had collaborated before on the > > WPA1/TKIP > > issue, mentioning your name would have given away the fact that > > independent > > research had occurred. > > > > I would argue that this still conforms to our "silent patch" agreement, > > though I would understand if in your opinion we stretched it a little. > > An errata does send a strong signal that something is wrong. However, a > > major goal of the embargo was to avoid early exposure of the fact that > > the industry at large was affected, and we evidently didn't expose this. > > There were no public news reports of the problem before your announcement. > > And if you hadn't specifically highlighted OpenBSD in your announcement, > > chances are very few people would have noticed the timing of our patch > > (https://www.krackattacks.com/#openbsd, which BTW we weren't asked to > > comment upon before it was made public -- that would have been nice and > > might have avoided some public drama we had to endure). > > [mathy] > Many people interpreted the OpenBSD FAQ in a manner that I did not intend. > So that could have been written better. My intention was to mention there > were different opinions about disclosure timelines. Then I gave the OK to > push a silent patch (so this was effectively my decision). In future > disclosures I will probably not give anyone the OK to push a silent patch > in advance. > > One thing that's unclear to me is how much in advance OpenBSD would want > to be notified in the future if there is a coordinated disclosure? Because > there appears to be discomfort with knowing there is a vulnerability, but > having to wait a relatively long time before deploying it? > > On this topic, it is
On the matter of OpenBSD breaking embargos (KRACK)
This a copy of internal discussion between me, Theo, and Mathy Vanhoef about KRACK, from the initial message I received from Mathy, up to today. I am making this public with Theos's and Mathy's consent, without redaction. I have annotated quoted blocks with names to make the discussion a bit easier to follow. Mathy's approval of my commit is documented below. If you hear people claiming OpenBSD (and by extension, me personally) broke the KRACK embargo, then please point them to this so they see I was given permission to commit the fix. If I remain a villain in their minds after reading this, I won't try to convince them any further. I don't do shouting matches. - Forwarded message from Mathy Vanhoef - Date: Fri, 15 Jun 2018 22:32:15 +0200 From: Mathy Vanhoef To: Stefan Sperling Subject: Re: [dera...@openbsd.org: Re: Key reinstallation attack against WPA1/2 resulting in nonce reuse]] X-Spam-Level: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-ID: <0e9828ceae1236b0571745540313e...@cs.kuleuven.be> User-Agent: Roundcube Webmail/1.2.9 X-Spam-Score: (-2.004) BAYES_00,SPF_HELO_PASS,SPF_SOFTFAIL [mathy] > > The security advisory released on 30 Aug 2018 wasn't explicitly > > agreed, > > only releasing the silent patch. So this was unexpected. Though I > > don't > > recall which details were included in this early advisory. [stsp] > For the record, this is the initial commit to -current: > https://marc.info/?l=openbsd-cvs=150294967228872=2 > > With diff: > https://github.com/openbsd/src/commit/2e40dd69ac29d6a858309bce0e05e65eec66648f#diff-4cf043b0a21146c45238a2c964206909 > > To reiterate, we had no idea where information about the bug was going to > spread between Aug 14 and Oct 16. Given the wide impact, the many parties > involved, and the long time frame of an additional 2 months, a leak into > circles which would try to abuse this information was possible. > The process was now trundling outside your own control and, in my opinion, > exceeding reasonable risk dimensions. > > Theo and I didn't want to wait much longer, knowing if users running > OpenBSD > releases got targeted e.g. by industry/government insiders or as a result > of leaks from the embargo process, we would be partly responsible. > We carefully issued an errata on Aug 30 (the originally agreed time > frame). > No impact beyond OpenBSD could be discerned from our errata patch. > The errata description was designed to imply an implementation-specific > bug. > https://ftp.openbsd.org/pub/OpenBSD/patches/6.1/common/027_net80211_replay.patch.sig > > Your name was kept off all of this to avoid drawing attention to your > research in this context. Since we had collaborated before on the > WPA1/TKIP > issue, mentioning your name would have given away the fact that > independent > research had occurred. > > I would argue that this still conforms to our "silent patch" agreement, > though I would understand if in your opinion we stretched it a little. > An errata does send a strong signal that something is wrong. However, a > major goal of the embargo was to avoid early exposure of the fact that > the industry at large was affected, and we evidently didn't expose this. > There were no public news reports of the problem before your announcement. > And if you hadn't specifically highlighted OpenBSD in your announcement, > chances are very few people would have noticed the timing of our patch > (https://www.krackattacks.com/#openbsd, which BTW we weren't asked to > comment upon before it was made public -- that would have been nice and > might have avoided some public drama we had to endure). [mathy] Many people interpreted the OpenBSD FAQ in a manner that I did not intend. So that could have been written better. My intention was to mention there were different opinions about disclosure timelines. Then I gave the OK to push a silent patch (so this was effectively my decision). In future disclosures I will probably not give anyone the OK to push a silent patch in advance. One thing that's unclear to me is how much in advance OpenBSD would want to be notified in the future if there is a coordinated disclosure? Because there appears to be discomfort with knowing there is a vulnerability, but having to wait a relatively long time before deploying it? On this topic, it is also worthwhile to mention that Microsoft pushed their fixes on patch Tuesday on 10 October 2016 [1]. That's before the agreed disclosure deadline, albeit quite close in time. This was only for their rather low-impact vulnerability CVE-2017-13080. Their Security Update Guide was only updated on October 16 to provide full details. [1] https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2017-13080 [stsp] > Your implementation-independent source code comments with details > about the bug were added only after the Oct 16 embargo had expired: >
