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

[Fiedler Roman]

> Von: Andrew Gallagher [mailto:andrewg at andrewg.com]
>
> > On 16 May 2018, at 13:44, Fiedler Roman <Roman.Fiedler at ait.ac.at>
> 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&output) but might make others impossible, like streaming of backups (decryption&output 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