Re: [Enigmail] Future OpenPGP Support in Thunderbird

Eli Schwartz <[email protected]> Sun, 27 Oct 2019 21:40:07 -0400
Newsgroups	gmane.comp.mozilla.enigmail.general
Message-ID	<[email protected]>
On 10/19/19 7:06 PM, Daniel Kahn Gillmor wrote:
> On Tue 2019-10-08 13:01:50 -0400, Eli Schwartz wrote:
>> Luckily if Mozilla is actually going to use a reimplementation of
>> OpenPGP instead of using the badly designed gnupg program, there will be
>> the option of interacting with a developer of OpenPGP software who is
>> willing to do things like check the size of a downloaded SKS key before
>> importing it... rather than getting angry at the world, flipping over
>> the board, and deciding that only the inferior keys.openpgp.org in
>> combination with self-sigs-only shall be used in future.
> 
> There are a number of implications in this message that i don't
> understand,

Oh, I'm sure I can clarify...

> but i'll focus on the practical suggestion:
> 
>  * Am I supposed to check the size of the "downloaded SKS key" without
>    retrieving the key itself (e.g. with an HTTP HEAD)?  Or am i supposed
>    to spend 22MB of bandwidth (and the equivalent amount of time) to
>    find out that the answer is "too large"?

The current state of things as I understand it is that gnupg already
spends 22MB of bandwidth, discovers the answer is "too large", and
responds by hanging. A *segfault* would be a better user experience.

>  * If I always issue an HTTP HEAD request first, do I expect my user to
>    wait for a second round trip if we decide to request the key itself?
> 
>  * Assuming I'm just using a HEAD request to learn the size, how long
>    should I wait for the response to come back from the server? (some
>    servers in the hkps pool occasionally take 15s or more to respond,
>    even for a HEAD)

These bullet points condense down to "here are some trivial policy
questions / objections that make the issue seem larger than it is".

While it might be *nice* to save bandwidth by asking for the key size
before wasting time downloading it, nice things are not core
requirements. Even if they were core requirements, I'm not sure what
your bullet points are here to say: they both have answers, because they
are policy decisions, and which answer you ultimately opt for does not
influence whether it's worthwhile to start work on input validation in
the first place.

Also it's fine to panic, drop the key, and return an error message "key
too large". It would be a net improvement over the current situation.

For bonus points, you could use a download library or implement one
yourself, which starts downloading the file immediately, then simply
aborts if the download exceeds a maximum threshold. curl has
--max-filesize for this, although that checks at the beginning of the
download and only works if the server returns a Content-Length (I don't
know if the keyservers do, I know that the html interface for
"lookup?op=get&search=XXXXXX" does not), then again, without a
Content-Length there would be no point in checking an HTTP HEAD request
first.

>  * What should I do if the response from the server is an HTTP 502 "Bad
>    Gateway" response or other 5xx return code? (This happens sometimes
>    for SKS implementations in the pool)

It's also fine to do exactly the same thing gnupg already does when
faced with a 502 error in the current 1-stage import process, if it gets
a 502 error during stage 1 of a 2-stage import process.

>  * If i check the size of a downloaded SKS key before downloading it,
>    and the answer is "very large", what am I supposed to do?  Give up?
>    Or maybe fetch it from somewhere that is more likely to have a
>    minimized copy?

What do you do if you check for the existence of an SKS key and the
answer is "not found"? Do you give up, or maybe fetch it from somewhere
that is more likely to have any copy at all?

> I am as sad as anyone about the failure of SKS's federated model, and I
> am by no means opposed to federation generally.  But the specific form
> of federation offered by SKS was known to be trivially subject to a
> range of attacks by casual adversaries for years, and has been
> increasingly hard for people to use reliably.

It's been known to be trivially subject to a range of attacks
principally against gnupg which is the only practically existing
implementation of OpenPGP which people use. Yes.

The fact that the attack has been known for years and GnuPG never did
anything about the fact that GnuPG (not the SKS federation model) is
vulnerable to an "I don't perform input validation" bug, is not exactly
an indictment on the SKS federation model.

My understanding is that the SKS software doesn't care if it is attacked
by the submission of junk data, because it is powerful software and can
crunch through the key anyway. Thus, SKS is perfectly *reliable* on its
own. In a bubble. It is the addition of GnuPG into the mix which makes
it unreliable, and the logical conclusion here is that it is, in fact,
GnuPG which is unreliable.

(Yes, I do acknowledge that a multilayered defense means that if SKS can
be improved to reject junk data, it should still do so. By the same
token, GnuPG is not now let off the hook!)

> I don't want people to use keyservers in general either, but if you're
> going to use a keyserver, you might as well use one that is more
> reliable.

What? This sounds like you're trying to suggest you are sympathizing
with my distaste for keyservers.

Except what. WHAT.

I didn't say I don't want people to use keyservers. There is no "either"
here. You don't want people to use keyservers. I want people to use
keyservers, and I want GnuPG to fix its brokenness so people can use
keyservers.

> My understanding is that there are plans to improve the SKS keyserver
> network to where it is significantly more respsonsive using Hockeypuck,
> and where it cannot be abused by third-party certifications.  However,
> it sounds like it will be self-sigs only, at least at first.  Further
> discussion about this probably belongs on the [email protected] list.

Being more responsive sounds great, but it's really an unrelated issue.

I can be plenty unhappy at unresponsive keyservers (like the chronically
issueful mit.edu server) and happy at other SKS servers running more
robust implementations of SKS on better servers, while simultaneously
being unhappy at GnuPG itself too for *not* working to be more
responsive, and I am unhappy that the people with influence in the GnuPG
community (of which you are not exactly a stranger) can give 150k words
on how flawed SKS is for for being federated in the manner that it is,
while having zero words for how GnuPG might so much as share blame (and
ultimately, carefully avoiding any slight hint that such might be the case).

I would be thrilled if people with experience in developing GnuPG would
respond to the situation by, I dunno, teaching GnuPG how to sanitize
input before blindly loading said data into an exploding parser.

> If you want to encourage the distribution of third-party certifications
> in a safe way, i recommend reading about Attestation Key Signatures in
> https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-08 and looking
> into offering patches to SKS, hockeypuck, or hagrid that can make use of
> such attestations.

I'm severely skeptical about the need for any such thing. Sure, having
the ability to do so cannot hurt, but that is very different from
calling it the fundamental solution to the fact that GnuPG is buggy.
GnuPG is buggy, so your solution is to radically reinvent how people
distribute certificates, whereupon you can respond by saying "see, no
one is giving unparseable data to GnuPG anymore, so GnuPG cannot choke
on it. Such solution! Much wow!"

> At any rate, I welcome these changes to the pool, just as I welcome the
> service offered by keys.openpgp.org.  In the meantime, I hope we can
> agree that it's not useful to dismiss people who just want things to
> work reliably.

I can certainly agree to that. I believe everything should work
reliably, and my vision for "everything works reliably" is that, in
parallel to interesting explorations into alpha systems like
keys.openpgp.org, some exploration should be done into making GnuPG
work, too.

This was, after all, my fundamental logic in posting in the first place.
I just want GnuPG to work, GnuPG has a bug, the GnuPG developers
responded to that bug by flipping over the table and saying "no, you
cannot have things which work unless you wait indeterminate years for
standards that don't exist and reconciliation methods that haven't been
agreed upon, let alone developed, from which you can acquire data".

I'm curious: do you *also* feel the concerns of people who just want the
Web of Trust to work reliably?

...

Now on to a new, more interesting topic. What plans do the GnuPG
developers have for combating malicious keys which are crafted for the
purpose of freezing GnuPG, and self-signed or signed by other keys owned
by the same person, with valid attestations and mutual signing and email
address validation (of some throwaway email account) and all that happy
stuff, which is *legitimately* all very much valid, but simply happens
to be quite maliciously large?

Oh, sure, it won't have the same impact as nuking someone else's key and
messing up peoples' ability to verify messages from you or Robert J.
Hansen. But on the other hand -- send someone a "joke" email of your
own, or send lots of people an email via a mailing list, and cause their
GnuPG to do weird things like freeze up.

Literally every single possible iota of messaging I've seen from
anywhere in the OpenPGP community is "the world will suddenly be perfect
if no one can attack *MY* key because of my Lord and Savior, hagrid". As
far as I can tell, it's not just missing the point, it hasn't even found
the continent where the point is hiding.

Seriously. "Thou shalt do input validation" is not exactly a novel
concept. Why is GnuPG immune to the idea, then? I absolutely refuse to
entertain the notion that there is *no* way for GnuPG to defend itself.
Maybe it's hard, maybe it will take a lot of refactoring and/or a lot of
time, maybe we need to just hang tight for a few months or a year while
decades of technical debt get cleared up, just SOMETHING I could accept.
But not "no, there is no problem, go away and bug those stupid keyserver
people instead".

I suspect I could go a long way toward solving the problem with a simple
shellscript that first downloads the key using curl, then checks the
size of the downloaded .asc file, and either uses gpg --import or exits
with the error message

"error: downloaded key is 60MB in size, holy cow!!! aborting without
calling gpg..."

If I can defend against that key by wrapping `gpg` using /bin/sh, curl
and stat, then I'm utterly positive some clever GnuPG developers can
reimplement the same logic in C, give or take a few months to be generous.

Voila. Sanitization of user input. Users get error messages instead of
hanging processes and unresponsive machines. (My laptop can sure handle
a 50MB file even if it wastes bandwidth, but it *cannot* handle whatever
it is gnupg is doing when it downloads that same file.)

Since this does not seem to have happened, I will go back to my corner
and mutter about how GnuPG developers are aggressively uninterested in
finding solutions to anything that implies their code isn't perfect.

-- 
Eli Schwartz
Arch Linux Bug Wrangler and Trusted User

_______________________________________________
enigmail-users mailing list
[email protected]
To unsubscribe or make changes to your subscription click here:
https://admin.hostpoint.ch/mailman/listinfo/enigmail-users_enigmail.net
signature.asc (application/pgp-signature, 1.6 KB)