[openpgp] Re: on discarding Literal Data Packet metadata [ was: Analysis document]

Am 13.07.25 um 23:41 schrieb Andrew Gallagher:
> On 13 Jul 2025, at 17:35, Daniel Kahn Gillmor <[email protected]> 
> wrote:
>>
>> Clearly, all these "automated and semi-automated" processes are broken,
>> to whatever extent they're relying on integrity and authenticity of the
>> filename/mtime information.  If we can't even identify them, i don't
>> know how we can provide fixes to the protocol that will be meaningful at
>> an application layer.
>
> It would be possible in principle to update an API to sign over the 
> metadata (which must already be provided if the application is 
> vulnerable), to fail the signature verification if the metadata has 
> been modified, and to return safe default values if the metadata 
> subpacket is missing (unix timestamp zero, “decrypted-file” or some 
> such). No deep knowledge of the application should be required, as the 
> happy path would be unchanged, and the entire point is to create a new 
> unhappy path.

I don't think it's a good idea to change the behaviour in case the 
legacy fields are present without integrity protection. This might break 
the existing implementations in a disruptive manner. Security is one 
requirement, availability another. Many proprietary uses of the 
unprotected LIT header fields that Nickolay described (and which I 
assume to be quite widespread as I argue below) will never be subject to 
modification attacks (since they often transmit messages only in 
internal "secure" networks). I think the right path would be to first 
upgrade them to an optional security mechanism (i.e., a hashed subpacket 
used by the verifier if present). At the same time those fields might be 
marked as deprecated (requiring that deprecation is supported by the 
commonly used CLI tools and libraries).

I think an important question that is underlying these considerations is 
who is the real OpenPGP user base. I don't think it is just the few 
F/LOSS email clients, packet managers and backup tools. In my 
experience, OpenPGP is used in proprietary industry applications. I 
think this is mainly because very often, there is the need for 
point-to-point communication where setting up a PKI is only an 
artificial burden. Using OpenPGP is also simpler than for its 
PKI-equivalent, CMS, and there is a good basis of CLI tools. If this 
conjecture is true I think there is no way to actually identify or count 
the uses of the broken scheme, and the right way is (at least in a first 
step) to fix it.

Best regards,
Falko

>
> A
>
>
> _______________________________________________
> openpgp mailing list [email protected]
> To unsubscribe send an email [email protected]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: [email protected]
Web: mtg.de <https://www.mtg.de>

------------------------------------------------------------------------

MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
Commercial register: HRB 8901
Register Court: Amtsgericht Darmstadt
Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
Chairman of the Supervisory Board: Dr. Thomas Milde

This email may contain confidential and/or privileged information. If 
you are not the correct recipient or have received this email in error,
please inform the sender immediately and delete this email.Unauthorised 
copying or distribution of this email is not permitted.

Data protection information: Privacy policy 
<https://www.mtg.de/en/privacy-policy>

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]