[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <516F662A.9090308@fifthhorseman.net>
Date: Wed, 17 Apr 2013 23:19:06 -0400
From: Daniel Kahn Gillmor <dkg@...thhorseman.net>
To: kseifried@...hat.com
CC: oss-security@...ts.openwall.com, Thomas Biege <thomas@...e.de>,
patrick@...gmail.net
Subject: partial signed message verification in MUAs [was: Re: debian: gpg
--verify suggests entire file was verified, even if file contains auxiliary
data]
[ i've changed the subject because i don't want the enigmail UI/UX
discussion to distract from the report about "gpg --verify" raised by
Thomas Beige; i think the "gpg --verify" issue needs to be dealt with
separately ]
On 04/17/2013 10:44 PM, Kurt Seifried wrote:
> So I think first off we need to figure out what the behaviour should
> be. My thought would be that it should be quit explicit, e.g. "this
> entire message/file/etc. was signed by X" or "a part of this
> file/message/etc. was signed by X" and so on.
I agree that these use cases need to be handled separately, but the
latter use case is quite problematic too -- if there's no way to
indicate *which part* of the message has been signed, the user is
basically left to guess at things. Not very helpful, and it seems quite
prone to abuse by someone who can figure out which ways people are
likely to guess.
Thunderbird's non-handling of S/MIME-signed subparts is an interesting
point of comparison: it shows that the thunderbird devs decided to not
even try to handle the latter case, despite having well-defined semantic
boundaries to key off of. I'd be curious to see an evaluation of other
MUAs handling of verification of any cleartext-signature scheme.
(there may also be a problem with indications of decryption, in addition
to clearsig verification, but i think clearsig verification is probably
worth tackling first)
> The next challenge is how to signal it to the end user. One challenge
> with enigmail is it provides some of the signalling "in band" as it
> were (in the email text area) which can be modified by the attacker,
> and some of it "out of band: (at the top of the window area it puts
> the color bar and text to clarify. With GPG command line it can maybe
> say something like "part of this message was signed by X"?
********* *BEGIN ENCRYPTED or SIGNED PART* *********
Enigmail's in-band signalling is trivially-forgeable, unfortunately, as
this paragraph indicates :(
********** *END ENCRYPTED or SIGNED PART* **********
The in-band signalling is also not used for PGP/MIME-signed messages; I
believe it's only intentionally used for those inline-PGP messages which
have text outside of the signature (though enigmail doesn't prevent the
same markers from showing up in other messages, or even elsewhere in the
same message).
Without a clear way to indicate a sub-part in the thunderbird UI that
can't be controlled by the message author, it's not clear to me that
there is a responsible way to report this information :(
> I'm inclined to assign a CVE to this type of vulnerability but I have
> no idea how we fix this _properly_. Anyone have ideas?
notmuch-emacs' PGP/MIME verification approach is worth looking at
(though perhaps not appropriate for the same groups of users as
thunderbird/enigmail): it provides controlled indenting of message parts
and threading, and places visually-distinct (and i think unforgeable)
signature tags at the appropriate indent level to indicate the scope of
the signature. It does not handle inline-PGP signatures at all, though.
I present this as one datapoint, not a silver bullet, unfortunately.
--dkg
Download attachment "signature.asc" of type "application/pgp-signature" (1028 bytes)
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
