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

On Sun 2025-07-13 22:41:15 +0100, Andrew Gallagher wrote:
> 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.

As Falko points out, if our goal is a smooth/usable upgrade path for
these mystery applications, we cannot afford to do this last step of
making the un-validated metadata fail or refusing to return it in the
API.  This means that all the existing applications will remain
vulnerable to this attack.  So what are we fixing?  Or, is the last
stage of this multi-stage process to actually break validation of all
existing OpenPGP signatures, and we hope these unknown users will
upgrade their signers before they upgrade the last stage of these
verifiers?  How will we assess when it's ok to make such a change?

What, by the way, is the API that you're proposing maintaining here?  in
GnuPG, for example, there is a --use-embedded-filename, which is
documented as problematic already (except for so-called "v5" signatures,
but there is no way ask for only --use-embeded-filename-from-v5-sigs).
And there is no --use-embedded-timestamp that i can see.

For GnuPG, yes, a tool could parse the --status output and implement
this business logic directly, but that would require changes to the
application layer already.  If they can do that, they can also easily
switch to something handling an entirely new API designed for safe
metadata transmission that is *not* vulnerable to legacy messages.

On Mon 2025-07-14 08:25:41 +0200, Falko Strenzke wrote:
> 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).

This appears to argue that while there is a large subset of users who
are likely to be vulnerable to this attack (by virtue of them relying on
the metadata), many of those users are *not* in fact vulnerable due to
other (equally unobservable) characteristics of the systems in which
they operate.  The net of this observation seems to be that we should be
less concerned about this use case.

On Mon 2025-07-14 11:59:05 +0100, Andrew Gallagher wrote:

> it’s not reasonable IMO to require that everyone pay attention to IETF
> WG discussions as the price of having their particular use case
> supported.

It's also not reasonable to expect the IETF WG to indefinitely support
scenarios for which there are *no* known use cases.  I completely agree
with you that the full scope of the OpenPGP userbase is (and should
remain) unknowable.  But the situation we have here is that in the known
userbase, there are *no* examples of anything comparable.

> That doesn’t mean we should support every obscure corner case forever,
> in case it breaks some hypothetical workflow somewhere, but reasonably
> obvious (and low-hanging) cases like this are worth the effort IMO.

I don't think this is as low-hanging as you claim it is.  If you're
going to go through a multi-year, staged roll-out of such an upgrade,
and it's going to need to end with actively breaking validation of all
existing OpenPGP signatures (i.e. those with a unsigned metadata stored
in a literal data packet), that seems like a heavy lift.  And it
wouldn't even be able to address any of the weaknesses of the existing
metadata format.

The low-hanging case, if OpenPGP wants to get involved in reliable
transmission of metadata, would be to define a novel metadata structure,
and introduce a clear API that extracts that secured information (or
indicates that it's not present).  Doing so well requires a survey of
what the users of this functionality actually need it for, though.  And
if no one is going to speak up, that's very hard to plan for.

Let's focus our energies on supporting those use cases that we know
exist and we can actively improve.

    --dkg

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