-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-01-01 15:20, Chris Laprise wrote: > On 12/31/2016 11:43 AM, Andrew David Wong wrote: >> On 2016-12-30 19:32, Chris Laprise wrote: >>> On 12/30/2016 12:58 AM, Andrew David Wong wrote: >>>> After meditating on this thread for a little over three years, >>>> I'd like to revive it, because I think Marek made an important >>>> point here, and I don't quite understand Joanna's response. >>>> >>>> If we don't trust GPG in our backup system because it does too >>>> much parsing of untrusted data before verification (which I >>>> believe is correct), then why do we trust it in our dom0 update >>>> system? >>> Ultimately, only Joanna can decide whether some guardian functions >>> are suitable for Qubes. But I don't necessarily buy into her >>> assertion about gpg verify: Watch some verbose output and declare >>> 'Hark! Complexity!'. Is it /that/ worrisome for gpg to iterate over >>> X message segments and decide if each is valid? >>> >> Interesting point. I wish I knew. > > If Qubes devs are going to start making commitments of time and effort > based on such claims, and disrupting the admin aspect of using Qubes as > well, I'd advise you to back them up with something rigorous before > leading the community down that path. >
You're misinterpreting the nature of this conversation. It's just a discussion. No decisions or commitments have been made. I'm primarily asking questions. The claims I'm making are conditional in nature. It's quite possible that no action is warranted, but that's by no means obvious. > Laboring under the assumption that GPG is bad, you won't even know if > your Qubes-curated Fedora/Debian packages are good unless you get those > projects to switch to your alternative as well. > First, I'm not laboring under that assumption. It's one of the things about which I'm inquiring. Second, that's not necessarily true. There could be solutions that don't require other projects to change anything (for example, a hypothetical system in which we first compute the hash of a package with minimal pre-parsing, compare the hash value to a distributed database, then, if it matches, proceed to verify the package's signature with GPG). >> >>> "If we don't trust GPG in our backup system" ...can it be trusted >>> anywhere else? >>> >>> Remember, a number of us are defending pgp/gpg in social media for >>> general use. IIRC, Joanna recently has. Does it make sense to >>> assume Qubes backups or updates are special cases? This issue >>> should be taken to the GnuPG and OpenPGP fora. >>> >> Yes, I think the argument can be made that Qubes backups and dom0 >> updates are both special cases in Qubes, since both directly concern >> the security of dom0. By contrast, using GPG in an AppVM is far less >> security-critical, and the risk is mitigated even further with Split >> GPG. > > GPG is used by developers, whistleblowers, activists and journalists on > X number of platforms. Some of those platforms use it for secure system > updates. Sorry, but this aspect of Qubes isn't special --- When > non-Qubes users use GPG in whatever role, it is just as critical to > *their* security. > You misunderstand me. I clearly stated that these may be special cases of GPG usage *in Qubes* compared to other kinds of GPG usage *in Qubes*. The claim is not that the security of Qubes backups and dom0 updates is more important than the security of GPG usage in non-Qubes contexts. Rather, it's simply that Qubes backups and dom0 updates are special cases *within Qubes* since they directly concern the security of dom0. >>>> Perhaps we meant something slightly different here: All the >>>> normal distro packages *for dom0* (e.g., Fedora 23 packages, in >>>> the case of R3.2) would have to be included in the Qubes repos in >>>> order for such a solution to be effective. Even this would be >>>> true only if the custom solution were repo- or package-dependent, >>>> and only if we wanted to guarantee secure updates using the new >>>> method for all of those packages. (There's a lot to be said for >>>> making dom0 smaller, and minimizing the number of packages >>>> installed there accords with that notion.) >>>> >>>> [2] This would seem to be a significant design flaw (perhaps a >>>> flaw in the OpenPGP spec).[3] It means that GPG does either >>>> mac-then-encrypt or mac-and-encrypt rather than the superior >>>> encrypt-then-mac.[4] >>>> >>>> [3] http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html >>>> >>>> [4] >>>> http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html >>> No. 3 is really old. Does it still apply? Is there really no option >>> that results in encrypt-then-mac? >>> >> No idea. >> >>> No. 4 is interesting, but no mention of PGP and it seems focused on >>> AES. >>> >> IANAC, but I think this is a general cryptographic principle. I don't >> see any reason to think that it's implementation- or >> algorithm-specific. (BTW, we do use AES as the default encryption >> algorithm in Qubes backups.) >> >>> On update packages -- Since they're not encrypted (only signed), >>> does it matter? Furthermore, its the repo manifests that are signed >>> (at least on Debian). >>> >> Indeed, it does. That's the central point here. If GPG does too much >> pre-parsing before verification, and if that's why we rejected it for >> the backup system, then we ought, on pain of inconsistency, to reject >> it for the same reason in the dom0 update system. > > I worry that a foolish consistency may be setting in. > No offense, but this reads like a feeble jab attempting to mask the absence of a real argument. I encourage you to say what you mean and mean what you say. An unwillingness to engage in a clear and direct rational discussion will get us nowhere. For what it's worth, I have absolutely no problem with differences of opinion or with being told that I'm wrong. Here's an example of a dissenting response that I'd actually be inclined to agree with: "Sure, our position is probably inconsistent, but it's not worth trying to change it. Here's why: Even if GPG does too much pre-parsing when verifying packages, it would be exceedingly difficult for an attacker to exploit it because [reasons], and it would be extremely difficult to fix. By contrast, it would be much easier to attack Qubes users through [other vectors], so we should just live with the inconsistency for now and focus our efforts on those other vectors, which will take up all of our time for the foreseeable future. To put it another way: GPG may theoretically be exploitable, but it's still one of the safest parts of the system. So, this isn't even the bad kind of inconsistency. It just means that the backup system is *extra* secure (i.e., more conservative than it needs to be). That's not a bad thing, but it doesn't follow that other components, like the update system, also have to be more conservative than they need to be." - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYaasxAAoJENtN07w5UDAw8QMQAIlXtgpeT4hkjoxpgxDT9Cja szqeRLV34jWyTApH01twr9ZjaUlBGnYpdnCz9tMlJk9k0Cg+7g8UHssnPIcF0+vV KOxJL+jc2GlitnuTfhwqOd2P91eENy5QCYegePZuiR13bzozNu40vCI/jWiNv7vV 1B8jjG9eV2NC5H/BdB1lf7qkfk/yEcuWPnI7K/NO5tmElm1hSqd5KMzj+hP/rILa +277W3XzAP2H+a9JOKo98p/CAREOnXC5qJNEQfFmgyGHiViFBcT3rHctGGp3tm/9 Vq/VJrJD/WoAapOtiM0Mfd4uohrOUc3tNoIyXEdrG5J89UzHv6RLUzP5Bl1OJi2D V5NkKAVczjfvPXIlxS7wz3dlO41Aj9RAfPcymuXWMOvnEmH308fosKIsrfFYBro5 pw412UxL5d5b95K4y+FYc7tCy180gV6EPX1nNJQCIrxfTNJ8KxMBkkE0MJbFetSl 2YS/xGVnmhvDd8xcET2Yv1nfVO6VKG0zNcQffB3Jc44kwI8aFBhfKffpLxb14Bvu 7lDD1h8QHRU+GUnkq1eZIRJNOLPFwTYdazjP8yRGgw+2Gm4HWnW3e5JgszPXdjKd IHe4+IcmNXlq/s+YrsBCjtAD7yn8+OJUcsG4zuZJf+UEZZgonuSaNi7hCzJ3AOWw U+O1dUst2P/mC3QrBONn =AiLu -----END PGP SIGNATURE----- -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/399ff54a-99d2-7b84-6667-1fc4ec4785db%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
