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.
instead of canceling it out.
I never said anything about "canceling it out."
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. In addition, the awful
taint of 'exploitable' public key crypto will have no place in the
upload or download process?
Here's an idea :) Why don't you *sign* the hashes? :))
You know... for safety...
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.
Chris
--
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/e052c385-a965-9c35-bb54-9f4706870185%40openmailbox.org.
For more options, visit https://groups.google.com/d/optout.
