-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2017-01-07 08:48, Chris Laprise wrote: > On 01/07/2017 03:18 AM, Andrew David Wong wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 >> >> On 2017-01-06 12:27, Chris Laprise wrote: >>> On 01/06/2017 06:24 AM, Andrew David Wong wrote: >>>> It sounds like you may be focusing exclusively on the >>>> hypothetical example at the expense of the general point, but >>>> for the sake of discussion: >>>> >>>>> If the Qubes Project is not authoring some of the packages, >>>>> it sounds unlikely to work as a primary step in verifying >>>>> integrity. This may /necessarily/ be true until the >>>>> upstream suppliers for dom0 change. >>>>> >>>> I don't see why. Maybe we're thinking of different things. >>>> Here's the general idea: >>>> >>>> https://github.com/QubesOS/qubes-issues/issues/2524 >>>> >>>>> Assuming GPG is an attack vector (a BIG assumption), I >>>>> don't think having users compare hashes with each other >>>>> over HTTPS links, for example, is going to suffice in >>>>> addition to GPG if the former won't suffice on its own. >>>> It's not supposed to. The idea is that hashing with minimal >>>> pre-parsing is a safe first-pass that mitigates (but does >>>> not eliminate) the risk of GPG verification (with >>>> pre-parsing). GPG verification is not replaced; it's still >>>> required. >>> If neither GPG nor 'collaborative hashing' is considered safe >>> on its own, and if GPG is a supposed attack vector, then the >>> weaknesses of the two procedures could *increase* risk >> How so? > > I think its up to advocates to state how it does *not* increase > risk when adding complexity to a process. Doubly so if discrete > verification steps are performed across networks without > signatures. >
Hashing a file with minimal pre-parsing doesn't, ex hypothesi, expose the system to any risks associated with parsing an untrusted file, so no risk from this vector is added over GPG verification. > >>> instead of canceling it out. >> I never said anything about "canceling it out." > It only *mitigates* the risk; it doesn't "cancel it out." The idea is that you do two passes: The first pass is a quick and dirty (but safe) check. The second is a slow and careful (but possibly risky) check. Using two passes makes the procedure safer for you and more difficult for your adversary. > Well, if its not intended to cancel out some of the supposed > 'risk' (single quotes) of verifying with GPG, then what is it? > > >>> This 'great new idea' may be unique for good reasons, >> Why did you put that in quotation marks? I never said it was a >> "great new idea." It's just a hypothetical example that I used to >> illustrate a more general point in the foregoing discussion. > > I used single 'ironic' quotes because they're my words and I don't > believe them to be true. > > >>> the primary one being that simple GPG verification is >>> considered safe. >> Well, there are many things that are considered safe by the >> general public (and even by the general computer security >> community) that are not considered safe in Qubes. For example, >> our position of distrusting the infrastructure seems to regard as >> unsafe (or at least insufficiently trustworthy) much of what most >> people consider safe (e.g., HTTPS). > > Distrust of infrastructure is applicable to this subject as well, > and its where the focus needs to stay if the debate is to get > anywhere. Focusing on hashing operations performed in a single > computer doesn't get anywhere. > > As for what's considered safe "in Qubes" (supposing you mean the > community or the project) I'll just say I don't think concern > should be mistaken for expertise, especially when it comes to > crypto tools. Qubes' particular expertise lies in domain isolation, > and our expert on that matter is Joanna. That was enough to start > and maintain an unusual new OS like Qubes because regular PCs were > lacking in high-quality isolation. But all that does not bestow any > special insight about crypto tools; that is a different animal and > the stakes (and interest level) for people using crypto on > different platforms is just as high. > > Maybe Joanna, Marek or someone else could analyze the non-crypto > parts of verification in GPG or the OpenPGP standard, and the > analysis might be credible, but I don't see that happening. If it > did, I would welcome it. > > What I do not want is to see the Qubes community become a part of > the anti-PGP bandwagon and acquire a boondoggle in the process. Its > already bad enough we have a Fedora update process in dom0 that > allows MITM to selectively withhold updates to packages, including > Xen. > > >> >> It's at least *possible* that the GPG pre-parsing issue indicates >> a genuine risk. A lot of security software is considered safe >> until bugs are later discovered. > > Every year multiple bugs are found in Xen's isolation. Does that > mean I should run Xen inside a different type of container to > 'help' it? I think its the design complexity thats really at > issue. > > >>>>> We would need some way of obtaining upstream packages >>>>> without any invocation of GPG and then verify them somehow >>>>> without invoking GPG. >>>> That's the whole idea. Roughly: >>>> >>>> 1. Download <package>. 2. $ sha512sum <package>. 3. Check >>>> hash. >>>> >>>> If match: >>>> >>>> 4. $ gpg --verify <package>. >>>> >>>> If no match: >>>> >>>> 5. $ rm <package>. >>> What happens if you're the first one to hash a package? You >>> don't get to use GPG at all? >> >> I suppose it depends on what your goals are. If you're the >> package maintainer, maybe you're providing the first hash to the >> database. If you're trying to be helpful, maybe you're finding >> packages without hashes in the database so that you can >> contribute them. If you're an end user, maybe you decide to wait >> a few hours to see if any hashes for that package get added. > > IOW, such a process would have to come with a ton of disclaimers > and caveats about its consistency and effectiveness. Doesn't all the best security software come with such disclaimers and caveats (Tor, GPG, Whonix, Qubes, etc.)? > In addition, the awful taint of 'exploitable' public key crypto > will have no place in the upload or download process? I'm not sure how you got the idea that I think of public key crypto in those terms, but nothing could be further from the truth. > Here's an idea :) Why don't you *sign* the hashes? :)) > > You know... for safety... > I think that could be a great idea, similar to this: https://github.com/rootkovska/codehash.db > I love the original idea of distributed verification laid out by > ITL. Somehow (rightly, I think) I assumed all that would be secured > by cryptographic signatures. What's being described here (so far) > is neither distributed nor secure; It lacks an acknowledgement of > the basic, high-risk design obstacles associated with multi-party > communications. When distributed verification for the development > process is figured out, then at that point we may be in a position > to extend it to enhance dom0 updates. > > The way I see it: If the vague, corrosive distrust of GPG/PGP > continues, the only options will be to eventually review the code > or move to another signing tool. You seem to think that I have something against GPG or PGP. I certainly don't. As a matter of fact, I count myself among their biggest fans. This was just (supposed to be) a thoughtful discussion about whether GPG, as a tool, can or should be more defensive when it verifies untrusted input. In any case, I think this discussion has run the course of its usefulness (for me, anyway), so I'm taking my leave from it. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYcmylAAoJENtN07w5UDAwSEUQAMLjJqctVbeVqbmFOChvqVmV THVluTnM1eDIV22ViqmFYjxmU/GJJtrBmBxtHqIKoYmYAY0OtGevfFCnkgrmOoKv KnDfm5js5mLciB12jwcLRdxhBNuVORzU290w5EjXmMpsmdqLBwn4e8j9D9UMKJTf 7194kVnGWNvbvOTj1zZ7aqAbTG1eJBi5wZ433PDHmK/V06//Gidqq/jyQdNDczF7 cuc5VshDg/HaqDpFWSF6M8lLRJ7N9x1iSw6h8Gpc4Be24pKSGKILU9lMzCA5jDjj rN+NQsOR+4B9vHvjbq5v+rWrOm2Acq6oyxrqAVvgRBgeV8sRpR5KcCwcpHnhmnW5 Jd1i5G64oowSjJ2xS8Ixp70Hj3WzA13SKmzQlRz5Z+wslZ0Uk81OjSmsGQ8V+/k7 WjQu0IFxw0da5fW0/wTiMSinBmR2PplS2oz/lVEoh8CU+TFqiOsuL9PQx8vVq7it DMF+yfauWM0KNGRDS1kCXMef771Kd5pjUnBC3pvBvYsmM4ULO68woVuYyidvgNpz p0wRry8PibKDZ9FJ1h0mA39fP5nbhnXJ/+O0wy24GmW5jrZ72UysBSCn7FZ/RxiR FpRMqhmabbx3hq6MCz/lIOQvHEyc+XJrTjwTpnyBndrjs+VoEOq2A2Xhxod31f+2 iZOoFU4uRyooi/ByOPcX =i9K4 -----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/46d93257-34bd-a291-0a37-2c89d567a90c%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
