Re: [openpgp] Should signatures be rejected if the embedded hash prefix does not match?

[Justus Winter <[e-mail]>]

Andrew Gallagher <andrewg=[e-mail]> writes:

> On 27/02/2023 15:20, Justus Winter wrote:
>> Andrew Gallagher <andrewg=[e-mail]> writes:
>>
>>> Omitting that particular check has
>>> been common practice for decades, and there are no known security
>>> implications.
>> 
>> There is a security implication.  If different implementations disagree
>> about the validity of a signature, this in itself can lead to a
>> vulnerability.  An example what can go wrong when different JSON parsers
>> disagree is given here:
>> https://bishopfox.com/blog/json-interoperability-vulnerabilities
>
> Interop failures can in principle lead to security issues, yes. But do 
> we know that this particular interop failure does? If so, then there 
> would be a potential sig forgery attack against github* (amongst 
> others), which is a *lot* more serious than anyone has previously suggested.

Imagine a setup where a git hoster uses a lenient implementation to
check that every commit has a valid signature, and a client that uses a
strict implementation that only allows updating if all the commits have
a valid signature.

Now, someone pushes a commit with a bad signature that the lenient
implementation on the server will accept, but the client will refuse.
This is a denial of service attack against the system.

>>> On the other hand, if implementations were to start enforcing that check
>>> retrospectively, we have no way of knowing the scope of the breakage.
>>> Are you proposing to cryptographically invalidate half of GitHub because
>>> of a technicality?
>> 
>> As you point out, Github's OpenPGP implementation has several flaws.
>> Are you proposing to simply accept whatever malformed artifacts Github
>> produces because they are Github?
>
> No, I'm proposing to accept that this particular kind of malformed 
> artifact should be accepted because the cost/benefit ratio of doing 
> anything about it now is too high, and to instead concentrate on making 
> sure it doesn't happen again.

So you are saying we should accept Github's signatures that are
malformed in two ways (the digest prefix is wrong and the MPI encoding
is wrong), because the benefit is high.

What is the benefit exactly?  Who has access to the key?  Who can create
signatures with that key?  Everybody!  What does a signature on a commit
from Github even mean?

Github has been notified about this issue in July 2022.  I just asked
Github to create a signature, and it is malformed.  I don't think they
care, I don't think they will do the right thing going forward.

>>> Please let's just draw a line under this and call it a learning
>>> experience.
>> 
>> I think the takeaway should be:
>> 
>> - Downstream users: Be diligent when selecting an OpenPGP
>>    implementation.
>> - Implementers: Engage in the standardization and interop testing
>>    process.
>> - Standards body: Require consumers to be strict to avoid this kind of
>>    mess.
>
> I agree completely with points 2 and 3, but not point 1. If implementers 
> did not fully understand this issue until relatively recently, it is 
> unreasonable to expect downstream users to have made an informed
> choice.

I don't follow.  What is it we the implementers did not understand until
recently?  The spec says how to form signatures.  The spec says put the
digest prefix there.  If you don't put the digest prefix there, you
didn't form a signature.

Best,
Justus