Hey Jon,
thanks for your thoughtful reply!
Moreover, gnupg is not merely a tool, it’s a reference implementation and as
a reference implementation it needs to have meta-features for the purpose of
debugging.
I agree with thre premise here, but not the conclusion. In the concrete bug
report I have, a bank(!) implemented OpenPGP in a way that included two major
blunders: 1) they encrypt to a subkey that doesn't have the flag. 2) they
include a one-pass signature packet, but then no actual signature (which isn't
a valid OpenPGP message, by spec).
The reason this happened, I strongly suspect, is exactly because they treated
GnuPG as a reference implementation: they tested that it worked against GnuPG
(or some frontend), found it worked in practice (without even a warning), and
then left it at that.
it’s *Alice* who has broken protocol, not me. Why punish me because someone
else has a broken implementation?
OpenPGP oughta say that an implementation MUST NOT encrypt to a sign-only key,
but it should leave it at that.
I believe that this all goes back to Postel's law of "conservative in what you
emit, liberal in what you accept". You're advocating for being "resilient" in
the face of bugs in implementations, and that sounds like a good idea on paper.
However, I've come to believe that for the long term health of an ecosystem. The
reason is that the required "bug compatibility" that is required to actually be
interoperable accumulates over time. This leads to more and more implicit
knowledge (rather than explicit, as in by spec) being necessary to create or
maintain an implementation.
Martin Thomson put these thoughts into an I-D fairly recently:
https://www.ietf.org/archive/id/draft-thomson-postel-was-wrong-03.txt
It is at this point terribly hard and time consuming to write an OpenPGP
implementation that works interoperably, because of a general expectation that
everyone be 100% GnuPG bug compatible. It's just a blip on the radar, but the
case described above happened five years into working on OpenKeychain. And it's
not a fluke, I have more similar incidents (will post about them soon).
The standard should not forbid resiliency in the face of a bug.
This is a very reasonable sentiment for specs like HTML, we certainly wouldn't
want to outright reject a website just because of a missing </i>. But in the
context of a cryptographic protocol, this is super dangerous.
Being overly relaxed in what we accept means giving attackers a large amount of
wiggling room. This is exactly what brought us EFAIL. We should learn from that,
and I hope we can do better in the future.
- V
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp