I was curious for your thoughts on the threshold for how widespread an end-use implementation issue needs to be before you’d consider it to be exemplary of an issue with the spec/ecosystem, which is why I asked about that.

Given that you’d established that this issue, in your opinion, wasn’t with GPG but instead was with the end-use implementations, I thought that discussing that threshold would help clarify the point under discussion.

I didn’t ask about an “acceptable” level of anything, nor was this intended to make the discussion about you, except insofar as you are a party to the discussion, so I was attempting to get more details on your position.

The new position you’ve given, that EFail was a “hoax” and that GPG wasn’t vulnerable, is pretty readily false given the details already provided as part of the EFail disclosure. The claim from the GnuPG devs (between https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032... and https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06033... ) is that GnuPG will print a warning if the MDC is stripped or fails to validate. This isn’t disputed by the EFail release, which notes that the issue occurs because decrypted plaintext is returned alongside the eventual warning, and that common clients will utilize the decrypted plaintext despite the warning.

This is the crux of the discussion as to whether this is an end-use implementation problem or a spec/ecosystem problem. My position is that as a security-focused tool, GnuPG should not present foot-gun opportunities like this which require all end-use implementations to handle their own validation for these kind of failure modes. A proper security-focused tool would refuse to provide decrypted plaintext in the case that the MAC check failed, because it would have required the MAC check to pass before ever starting to decrypt anything.

GPG just happened to have a check that could of prevented this particular attack if the client had done certain things in response to the failure of that check. S/MIME didn't have a check of that type and was as a result was more affected by the attack. S/MIME had one less "footgun" than GPG did. That still didn't help anyone and in this particular case make things worse in practice.

There is a tendency in these sorts of things to get so wrapped up in the details that the root issue gets forgotten about. In this case the root issue is the leakage of information from HTML emails. After that, what really matters here? What point is there in considering each and every thing that could of been different that would of prevented the attack? Sure, if I hadn't of left the house on Thursday I would not of been hit by the bus, but this particular insight is not valuable in any way.

The hoax here is the suggestion that PGP (and S/MIME for that matter) was broken in some way. The original paper was called "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels" which was not just misleading, it was straight up wrong.

S/MIME didn’t have one less footgun: it had roughly the same footgun. The fact that GPG prints a warning isn’t the footgun, the footgun is the fact that decrypted plaintext was returned even if the MDC check failed.

The point of considering each thing that could have prevented an attack is clear, and is a central part of threat modeling and defense in depth. Those concepts aren’t really controversial. Thinking critically about the parts of a system that can contribute to adverse results, and then applying mitigations and avoiding pitfalls, is a pretty core part of basically all engineering (software and otherwise).

The bus analogy (if I hadn’t left the house on the day I got hit by a bus, I’d not have gotten hit) would, in a threat modeling context, be accurately identified as both ‘definitely true’ and ‘low probability’. Yes, leaving your house is dangerous, for a variety of reasons. But the relative danger of leaving your house vs not leaving your house is more questionable (staying inside the house is likewise dangerous), and the probability of leaving-the-house causing hit-by-bus is low. But a security tool returning plaintext despite a MAC fail isn’t like leaving your house, it’s like looking both ways once you’re already crossing the street. GPG warns you there’s a car coming, but you’re already standing in front of the car. A dexterous human could potentially dive out of the way, as an end-use implementation could discard the decrypted plaintext when it sees the MDC warning, but a root-cause-analysis would still rightly suggest that you should be looking both ways before crossing, rather than during.

Taking this thread in aggregate, it’s interesting to me how the goalposts keep shifting. The original thrust was “There were no real weaknesses in the OpenPGP standard or the GnuPG implementation of that standard”. When pressed, your position shifted to include “Even if the GPG implementation and/or OpenPGP standard had of been entirely broken, this is still mostly the email clients fault.” You’ve now further shifted to questioning why we should even worry about whether GPG could be better (“What point is there in considering each and every thing that could of been different that would of prevented the attack?”).

I don’t understand the rigidity with which you refuse to consider the possibility that GPG could have better handled this kind of threat.

> OK, but this is all in response to an attempt to have me come up with an acceptable level of client information leaks. Since that is an obvious trap I had fun with the idea instead.

Oh, you're commenting badly on purpose because you misinterpreted something as a 'trap'? Great.

It's not a trap question. If something gets misimplemented once, it's maybe probably not an issue with the spec. If it happens over and over again, it's suspicious.