Re: AW: AW: AW: AW: Efail or OpenPGP is safer than S/MIME

[Werner Koch]

On Thu, 17 May 2018 13:11, roman.fied...@ait.ac.at said:

> How could that work together with the memory based "wipe" approach, you 
> envisioned in your message 
> https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060379.html , last 
> paragraph?

Tha is a different layer.  Basically a part of a MUA.  That feature
would be a safenet in case the actual MUA part does not check return
codes from GPGME.  GPGME has several types of data objects

  - Memory based
  - File based
  - File descriptor based
  - Callback based

For the first two we can clear the memory or delete the file in case of
an error and before we return to the caller.  It is actually a bit
complicate to implement because gpgme allows for synchornous and
asynchronous operation and for the latter we have not yet a way to
associate the data object with context.

> Would that imply, that using e.g. "--output /proc/self/3" would
> implicitly change the security behavior of gpg, e.g. by switching from
> "output before validation" model to "validation before output" model

No, gpg has no idea about this.  It only aware whether it is working on
a named file or on a file descriptor (which also includes a pipe)


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgp1ymasZ4luL.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: Efail or OpenPGP is safer than S/MIME

[Fiedler Roman]

> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von
> > On 17 May 2018, at 11:50, Patrick Brunschwig 
> wrote:
> >
> >> On 17.05.18 10:07, Werner Koch wrote:
> >> On Thu, 17 May 2018 08:59, patr...@enigmail.net said:
> >>
> >>> Within 12 hours after the release I got 5 bug reports/support requests
> >>
> >> Kudos to Enigmail for acting as our guinea pig.  I implemented the same
> >> thing in GPGME this morning (see my mail to enigmail users).
> >>
> >> What shall we do now?  Provide a separate tool to decrypt and clean HTML
> >> messages or add a tool to Enigmail to do just this?
> >
> > Good question... Thunderbird is working on fixing the HTML display
> > issue. But I think we should really start enforcing users to enable MDC.
> > I therefore would prefer keeping the barrier high. In any case, this is
> > nothing that I could implement with a week or two.
> 
> I agree, while it would be easy for the users to have a magic button in
> enigmail, this isn’t something we should be encouraging users to use on a
> regular basis.
> 
> IMO a better solution would be a standalone tool that you could point at a
> local Maildir and tell it to clean and re-encrypt anything it finds that is 
> bad (for
> a given value of “bad”), and save it to a new Maildir, perhaps with an
> attachment explaining what was done. This would of course invalidate any
> signatures on the re-encrypted data, but that’s OK for the use case. It should
> not be an in-place update, nor should it work over e.g. IMAP because that
> would a) encourage people to run it in a cronjob and b) destroy the originals,
> which may be a deal breaker for archival purposes.

Sounds nice. Maybe if you combine it with the suggestions from 
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060362.html (and perhaps 
improve my proposal, as a first guess usually cannot be the best), you could 
kill two birds with one stone. Hence you also could have a shorter path to get 
rid of old ciphers, MDCs and other backward compatibility stuff, thus 
increasing security and speeding up development.

LG Roman
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: AW: AW: AW: Efail or OpenPGP is safer than S/MIME

[Fiedler Roman]

> Von: Werner Koch [mailto:w...@gnupg.org]
>
> On Wed, 16 May 2018 16:24, roman.fied...@ait.ac.at said:
>
> > In my opinion it is hard to find such a "one size fits all"
> > solution. Like Werner's example: disabling decryption streaming
>
> The goal of the MDC is to assure that the message has been received
> exactly as the sender set it.  Thus there is just a binary decision:
> Okay or Fail.  Everything is like you have been dropped at boot time
> into manual fsck mode - you can do something about it or you just
> irginore things and restore the partition.

How could that work together with the memory based "wipe" approach, you 
envisioned in your message 
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060379.html , last 
paragraph?

If I understand your approach correctly, it will imply that at least one 
do-not-apply-one-size-fits-all switch has to be present, thus contradicting one 
of your statements. Or did I get something wrong in my argument? The decision 
output (fail/ok) in the end might be binary for both use-cases but the internal 
logic (process model) for validation/output will be different.

> > streaming of backups (decryption before final validation). So
> > you need something on the interface to support that non-standard
> > behavior, deviate from the default.
>
> It is already there.  If you use "--output FILE" the file is either
> created or not.  Your choice.

Would that imply, that using e.g. "--output /proc/self/3" would implicitly 
change the security behavior of gpg, e.g. by switching from "output before 
validation" model to "validation before output" model (again compare your 
message, cited above)? Implicit feedback from selected output mode on security 
related MDC-check behavior would seem dangerous to me. Somehow rings an alarm 
bell, if that should be the proposed solution.

LG Roman
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: AW: AW: Efail or OpenPGP is safer than S/MIME

[Werner Koch]

On Wed, 16 May 2018 16:24, roman.fied...@ait.ac.at said:

> In my opinion it is hard to find such a "one size fits all"
> solution. Like Werner's example: disabling decryption streaming

The goal of the MDC is to assure that the message has been received
exactly as the sender set it.  Thus there is just a binary decision:
Okay or Fail.  Everything is like you have been dropped at boot time
into manual fsck mode - you can do something about it or you just
irginore things and restore the partition.

> streaming of backups (decryption before final validation). So
> you need something on the interface to support that non-standard
> behavior, deviate from the default.

It is already there.  If you use "--output FILE" the file is either
created or not.  Your choice.


Shalom-Salam,

   Werner

-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpNMq8eJWffx.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: AW: AW: Efail or OpenPGP is safer than S/MIME

[Fiedler Roman]

> Von: Andrew Gallagher [mailto:andr...@andrewg.com]
>
> > On 16 May 2018, at 13:44, Fiedler Roman 
> wrote:
> >
> > I am not sure, if gpg could support 
> > implementation/testing/life-cycle-efforts
> to establish all those parameters and different process models for most of the
> decryption processes gpg users envision to use gpg for.
>
> Why do we need a plethora of configuration parameters to selectively turn
> off various parts of a security protocol? Why should we even encourage such
> a thing? With security, either everything seems to be ok, or it’s broken in 
> such
> a way that it’s potentially an utter disaster. And quite probably both
> simultaneously.

In my opinion it is hard to find such a "one size fits all" solution. Like 
Werner's example: disabling decryption streaming operation might increase 
security for some use-cases (validation before decryption) but might 
make others impossible, like streaming of backups (decryption before 
final validation). So you need something on the interface to support that 
non-standard behavior, deviate from the default.

> The only reasonable use case for selective disabling of security protocol
> features is for backwards compatibility. That doesn’t require fine grained
> control, just a version number. And even then, it opens up the possibility for
> user error.

Yes, another example for different use-cases and hence different process model 
requirements in software.

> I’m going to preemptively quote RJH here before he gets around to it. Use the
> defaults! ;-)

Then why are there already so many command line options for 
decryption/validation gpg not just one: "--insecure"? From my point of view, 
monopolists might be able to push one set of defaults but the open source 
software ecosystem might work differently: those projects survive, that enable 
that many use-cases per development effort, so that they find sufficient 
developers/funds to support development. If they drift off, the project will 
fork/another project might take over.

So gpg has to watch out for the optimum point between following extremes:

1) Only supporting one standard use-case with default settings (thus increasing 
security but loosing users)

2) Supporting many use-cases via different gpg-internal 
decryption/validation-process models (requiring loads of parameters, complex 
models, lot of implementation, risk to invoke gpg with wrong parameters)

3) Supporting one generic use-case/process model and leaving it to the caller 
(other side of interface) to decide what to make from it (risk, that other 
party just does not do it right - e.g. ignores a warning like with Efail)


Assuming, that the ideal point would be somewhere in between, supporting only a 
single FAIL status like old-style shell commands might not be sufficient to 
attract sufficient users from world 1, 2, 3 above.

LG Roman
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: AW: Efail or OpenPGP is safer than S/MIME

[Robert J. Hansen]

> I’m going to preemptively quote RJH here before he gets around to it. Use the 
> defaults! ;-)

:)


___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: AW: Efail or OpenPGP is safer than S/MIME

[Andrew Gallagher]

> On 16 May 2018, at 13:44, Fiedler Roman  wrote:
> 
> I am not sure, if gpg could support implementation/testing/life-cycle-efforts 
> to establish all those parameters and different process models for most of 
> the decryption processes gpg users envision to use gpg for.

Why do we need a plethora of configuration parameters to selectively turn off 
various parts of a security protocol? Why should we even encourage such a 
thing? With security, either everything seems to be ok, or it’s broken in such 
a way that it’s potentially an utter disaster. And quite probably both 
simultaneously. 

The only reasonable use case for selective disabling of security protocol 
features is for backwards compatibility. That doesn’t require fine grained 
control, just a version number. And even then, it opens up the possibility for 
user error. 

I’m going to preemptively quote RJH here before he gets around to it. Use the 
defaults! ;-)

A

___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: AW: Efail or OpenPGP is safer than S/MIME

[Fiedler Roman]

> Von: Werner Koch [mailto:w...@gnupg.org]
>
> On Tue, 15 May 2018 11:44, roman.fied...@ait.ac.at said:
>
> > The status line format should be designed to support those variants to
> > allow a "logical consistency check" of the communication with GnuPG
>
> There is a
>
> DECRYPTION_FAILED
>
> and that is all what it takes.

But this is only a single status code for a very complex decryption/validation 
process (considering cipher methods, signature methods, local time, trust DBs, 
signatures, number of messages, ...). When relying on that single code, gpg 
would need configuration parameters to configure each step of the whole 
decryption/validation process in a very fine-grained way, so that gpg will know 
in the end, if it should issue the FAILED or not. I am not sure, if gpg could 
support implementation/testing/life-cycle-efforts to establish all those 
parameters and different process models for most of the decryption processes 
gpg users envision to use gpg for.

> If the integrity check fails there
> should be no easy way to circumvent this. RFC-5083 states this cleary:
>
>The recipient MUST verify the integrity of the received content
>before releasing any information, especially the plaintext of the
>content.  If the integrity verification fails, the receiver MUST
>destroy all of the plaintext of the content.
>
> Unfortunately this can't be done by tools prepared to process huge
> amounts of data.  And in contrast to the Efail claims this is an
> important feature. How would you else do your ZFS backups without
> having a way to stream the data to the backup system.

This is just the example of two different, complex decryption/validation 
processes, that should be supported both. As the definition of the "process" 
also has implications, what a valid "integrity check" is (see also the 
discussion about historic messages), I believe, that this is hard to be done by 
breaking it down to a single 0/1 decision for gpg (which might not know the 
constraints of the current process in detail). Otherwise a 
"--allow-non-rfc-5083-streaming-mode" flag should already exist to tell gpg 
more about the decryption process constraints (to distinguish between the two 
different process models, that should be implemented already, just for your 
RFC-citation from above).

> ...

LG Roman
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

Re: AW: Efail or OpenPGP is safer than S/MIME

[Werner Koch]

On Tue, 15 May 2018 11:44, roman.fied...@ait.ac.at said:

> The status line format should be designed to support those variants to
> allow a "logical consistency check" of the communication with GnuPG

There is a 

DECRYPTION_FAILED 

and that is all what it takes.  If the integrity check fails there
should be no easy way to circumvent this. RFC-5083 states this cleary:

   The recipient MUST verify the integrity of the received content
   before releasing any information, especially the plaintext of the
   content.  If the integrity verification fails, the receiver MUST
   destroy all of the plaintext of the content.

Unfortunately this can't be done by tools prepared to process huge
amounts of data.  And in contrast to the Efail claims this is an
important feature.  How would you else do your ZFS backups without
having a way to stream the data to the backup system.

For failsafe reasons I consider to wipe the plaintext data in GPGME's
interface on decryption failure.  That can only be done when memory
based data or file based objects are used.  But I guess that many MUAs
use the memory data approach.  Such a failsafe protection would avoid an
attack even if the error code returned by GPGME is not checked.


Salam-Shalom,

   Werner


-- 
#  Please read:  Daniel Ellsberg - The Doomsday Machine  #
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.


pgpdsLAun8Nqs.pgp
Description: PGP signature
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: Efail or OpenPGP is safer than S/MIME

[Fiedler Roman]

> Von: MFPA [mailto:2017-r3sgs86x8e-lists-gro...@riseup.net]
>
> Hi
>
> On Monday 14 May 2018 at 1:33:03 PM, in
>  local>,
> Fiedler Roman wrote:-
>
> > This would also prevent many other programming
> > errors: e.g. if gpg
> > claims to have processed 2 signed messages, a client
> > has to verify,
> > that it also received two "GOOD_SIG" messages.
>
> What if a message has more than one signature?

The status line format should be designed to support those variants to allow a 
"logical consistency check" of the communication with GnuPG like a message 
digest allows consistency checking for a cryptographic message. I guess it 
would be ease for the GnuPG-hardcore developers to define, which fields are 
required to perform a thorough consistency check.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users

AW: Efail or OpenPGP is safer than S/MIME

[Fiedler Roman]

> Von: Gnupg-users [mailto:gnupg-users-boun...@gnupg.org] Im Auftrag von
> 
> On 14/05/18 12:25, Robert J. Hansen wrote:
> > The problem is that gpg doesn't say anything. I would expect a
> > DECRYPTION_FAILED message here:
> 
> So perhaps the solution is to throw a big warning and prompt when an
> integrity check failure is thrown by gnupg? That would mitigate the
> current issue, but allow for reading pre-MDC emails as per Werner's
> earlier link.
> 
> The problem here is that an integrity failure is a serious error when it
> occurs in a context where oracle behaviour is possible (such as email),
> but it's much less serious when used outside that context. Just because
> gnupg says it's only a warning-level offence doesn't mean enigmail
> should agree...

In my opinion, the problem is related to the general gnupg interface design. An 
optional error or warning is always somehow problematic in interfaces:

1) you have to read and understand the complete documentation to know of any 
message that may occur

2) if it is not here, you simply do not know, if everything is right, if you 
just missed the message or an attacker managed to "suppress" it somehow. Makes 
it easier on the attacker - like here

In my opinion, gnupg would do itself a favour by avoiding optional messages - 
without any other reference to it. With such a protocol I would expect gnupg to 
end somehow like ...

[END_STATUS]: Messages: 3, Valid MDCs 2, Signed Messages 2, , Warnings: 1, 
Errors: 0 ... (put here everything you deem important and document it)

This would also prevent many other programming errors: e.g. if gpg claims to 
have processed 2 signed messages, a client has to verify, that it also received 
two "GOOD_SIG" messages. If just any of the numbers do not match, any good mail 
client should bail out immediately, e.g. if warn=1 but the client did not 
understand the warning.

LG R

PS: A end message as single line sorted JSON dictionary might make parsing less 
error prone and increase the number of developers really parsing and using them.
___
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users