[cbarrick]

The issue discovered in TFA isn't about the format of individual packets (which "The PGP Problem" laments) but the grammar above the packets, i.e. the correct ordering of valid packets.

Edit: foot successfully inserted in mouth

[tptacek]

I wrote the "PGP Problem" article and definitely was not just talking about "the format of individual packets", which you might be able to tell from the fact that it brings up a quadratic parsing DoS in that design as well.

[upofadown]

Since you are the author of TPP could you please explain how your example shows some sort of quadratic parsing DOS? I don't see anything like that. Just a huge number of signatures.

[tptacek]

The postmortem on that DoS attack was at pains to point out that they were "officially" documenting only one of the vulnerabilities. Somewhere on an old drive I have the giant mountain of mailing list posts I sorted through to write that post, and I may dig it out at some point, but right now you're just going to have to take my word for the fact that I was not suggesting that the only problem with the packet format was the fact that you can represent lengths 8 different ways.

This is a deeply silly discussion to be having on this particular thread, which, again, is about a vulnerability that owes to the PGP packet format.

[woodruffw]

An absence of a canonical order or a definition of a well-formed packet sequence is itself a flaw in the packet format. Other cryptographic serialization and encoding schemes do not make this mistake.

[twiss]

FWIW, OpenPGP does have a definition of a well-formed packet sequence, e.g. for messages here: https://www.rfc-editor.org/rfc/rfc9580.html#name-openpgp-mes...

The packet sequence used by this vulnerability was not a valid OpenPGP message, as pointed out by the blog post (under the header "An invalid packet list").

Part of the issue in OpenPGP.js was that it didn't fully validate the message packet grammar, which has now been fixed: https://github.com/openpgpjs/openpgpjs/pull/1853

[tptacek]

When we evaluate the design of a cryptosystem, we debit implementation vulnerabilities (at least in mainstream implementations) to the design. It is part of the goal of a cryptosystem design to foreclose on the possibility of implementation vulnerabilities.

[twiss]

I would usually tend to agree with that, I was mainly just responding to the specific claim that OpenPGP doesn't have a definition of a well-formed packet sequence, which is false.

Also, as a maintainer of OpenPGP.js, I'd say that while the complexity of OpenPGP certainly didn't help, quite a lot of things needed to go wrong to create this vulnerability:

- The message grammar validation was incomplete, as mentioned

- The streaming decryption/validation code affected how the packet sequence was processed

- A later optimization when not streaming affected it further in a way that caused an inconsistency in which packets were being read when

- Finally, the architecture of the code made it possible to return different data than what was verified, which should not have been possible (and we'll address this as well in a future refactor)

All in all, I would place more of the "blame" on OpenPGP.js rather than OpenPGP. That being said, I don't think placing blame is the most important here; both OpenPGP.js and OpenPGP should and will learn from this.

[tptacek]

What you're seeing me and 'woodruffw implying is that modern formats are (deliberately) trivial to parse. OpenPGP is not. That is a security design feature that OpenPGP lacks, and it's a big one, because it's caused multiple issues already.

[twiss]

Yes, I understand and never said I disagree with that :) I'm just trying to provide some nuance and background about the specific issue discussed in this submission, as IMHO I think it's more interesting than making the same high-level points about OpenPGP over and over in every thread related to it (no offense meant, of course).