This is an interesting point to consider, thanks 7v5w[...]. Some thoughts this 
brings to mind:

-
I know that we all understand that the canary system is little more than a 
matter of reassurance - as I understand it, it's not a security feature so much 
as a security blanket. That said, I would imagine that avoiding the chilling 
effect which often accompanies undue paranoia is a practical priority and I 
also feel that the community would be better served if the frequency was 
increased rather than decreased. As has been said, should the worst occur we'd 
be better equipped to mitigate damages and/or minimize exposure.
-
I wonder if the debate over whether there's a 'better' time to update the 
system with respect to the canary schedule is a moot point. I would think that 
the risk of having unpatched vulnerabilities would greatly outweigh the 
ostensible benefit(s) that might be afforded to those intent on avoiding a 
TAO-type situation, no? Regardless of the threat model you subscribe to there 
are tons of players on the field and most will take the path of least 
resistance if it should be available to them.
To that end, if the worst were to occur would any of us actually trust a backup 
to be trustworthy? We know now that many of the methods of evading detection 
and achieving persistence are sophisticated and disturbingly effective. I'd 
consider it Game Over at that point.
- Why aren't the canaries date-specific? I'm sure this is done with good reason 
but I'm curious to know what that reasoning is.

- TN

-------- Original Message --------
Subject: Re: [qubes-users] Qubes Canary #12
Local Time: June 5, 2017 5:35 PM
UTC Time: June 5, 2017 5:35 PM
From: 7v5w7go9u...@gmail.com
To: qubes-users@googlegroups.com

On 06/05/2017 04:06 PM, Unman wrote:
> On Mon, Jun 05, 2017 at 03:59:26PM +0000, 7v5w7go9ub0o wrote:
>> On 06/05/2017 01:42 PM, Andrew David Wong wrote:
>>
>> <snip>
>>
>>> 1. The date of issue of this canary is June 2, 2017.
>> <snip>
>>
>>> 5. We plan to publish the next of these canary statements in the first
>>> two weeks of September 2017. Special note should be taken if no new canary
>>> is published by that time or if the list of statements changes without
>>> plausible explanation.
>> <snip>
>>
>>
>> Thanks for the note.
>>
>> IIUC, the canary system is now quarterly and three months until the next
>> canary. That also means that a back-door and gag order could be placed
>> into effect against Qubes today, and users would be clueless about it
>> 'til September - up to three months of user jeopardy if there are Summer
>> updates.
>>
>> The cautious user will reason that his system updates should be only
>> applied immediately before the Quarterly canary; thereby assuring -
>> after the canary is issued - that his quarterly update(s) was not
>> back-doored. This could be a disaster if an accidentally flawed update
>> happened to get out.
>>
>> Please consider *increasing* the frequency of canaries - not decreasing.
>> Alternatively, consider issuing additional canaries shortly after
>> important system updates, and scheduling "minor" system updates a week
>> before the quarterly canary.
>>
>> A weekly canary would be much more useful and reassuring, as I wouldn't
>> have to wait to do updates. Also, ISTM weekly would be easier for ITL to
>> manage.
>>
> I agree on the frequency point. But surely a cautious user will not
> install updates until immediately AFTER the Quarterly canary, not
> before. And since the canary dates are not fixed, how is one to know
> when "immediately before" might be?
>
>

1. The canary needs to be issued on a fixed date for the system to work;
otherwise a "late" canary is meaningless.

2. Certainly the back-door and gag order will be mandated immediately
after the canary. So any updates after the canary are no longer
trustworthy. Any updates after the date of the most recent canary can be
compromised.

IF you update immediately before the date-certain canary, and then
discover that the canary is not updated or otherwise untrustworthy, you
then restore to the last known-good backup (and seek an explanation).

--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/012fa555-c3ca-f2e4-fc06-7b40791634fb%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5f8MO5O2Wc80XuhpjIgkWg5Y8Nxtw04kWuIERAuxShO215Cfqr6YYMjxhPcK3eLR7FM0WhQ_148TnE8cli_2cIIkrRN3z3fsYg0ff8eSggc%3D%40protonmail.ch.
For more options, visit https://groups.google.com/d/optout.

Reply via email to