[openpgp] Re: New Version Notification for draft-dkg-openpgp -stateless-cli-15.txt

Hi, Daniel! :-)

On 09/01/2026 22:16, Daniel Kahn Gillmor wrote:
> On Thu 2026-01-08 18:01:49 +0000, Andrew Gallagher wrote:
>> 
>> It is not safe to treat ephemerality as an optional extension of
>> existing encryption subkeys, because then it's too easy to accidentally
>> downgrade it to non-ephemeral.
> 
> This is true of all "ephemeral" keys, whether marked as such or not,
> right?
> 
> I mean, draft-green-tls-static-dh-in-tls13 offers a way to effectively
> recreate supposedly ephemeral keys in the forward-secure TLS handshake.
> 
> We can discourage it, but we can't prevent it.  Guidance that says
> "please don't extend encryption-capable subkey expiration" seems like
> good guidance generally, no?

There are use cases where extending subkey expiration is necessary, e.g. 
if the secret key is distributed across multiple devices, or if it is in 
a hardware token with limited storage for subkeys (e.g. openpgp card) 
and rolling the secret would be difficult. Such guidance can therefore 
never be universal, so applications can never remove the ability to 
extend such keys. And so long as that code path exists, it could 
potentially be triggered.

But if you have a separate mechanism for ephemeral keys, and if the 
expiry date was part of the key material packet (not the binding 
signature), and contributed to the fingerprint, it would be very 
difficult to make any such code path function at all. This would offer 
an actual guarantee that the expiry date of this kind of key cannot be 
accidentally extended, and is therefore solid enough to build a "secure 
disappearing messages" UX on top of. Without solid guarantees I think 
the attractiveness of the mechanism will be limited.

We can't prevent people from trying to work around security guarantees, 
but we can make it difficult.

> I actually don't think it's unclear how these rules would be
> consistently implemented given the data in the self-signatures.

You're suggesting we assign novel semantics to the existing E(comms) and 
E(storage) key flags. Any time we retcon semantics like this, there will 
be laggy implementations and mistakes. It's fine if we treat these new 
semantics as hints, but I don't believe we can make solid security 
guarantees based on them.

(before anyone complains, draft-signatures is not the same because the 
semantics it tries to fix are already inconsistent in the wild)

> Can you say more about how much bloat you think would cause a self-DoS?
> or even what you think the self-DoS would be?  are you saying that the
> keyholder would be unable to operate their own secret key to decrypt?
> Or that their peer would somehow be unable to encrypt to it?

I'd fear that some peers may be unable to encrypt because they see too 
many encryption subkeys attached to a certificate, or that distribution 
mechanisms may fail to serve an updated key if it goes over some limit 
(particularly when we have post-quantum self-signatures).

I already sent a message to the list about the bloating effect of ML-DSA 
self-signatures, and that was using a slow subkey refresh cycle (2 
years). With a refresh cycle on the order of years we have years to 
upgrade all the clients and distribution mechanisms, but if we encourage 
a faster one on the order of months or weeks rather than years? oof...

>> Part of the problem is that the existing wire format offers *too many*
>> knobs. In order to tighten security, you have to remove the knobs that
>> are no longer required; otherwise you're one knob-twiddle away from a
>> downgrade attack.
> 
> I think what you're calling a "downgrade attack" is the current status
> quo: a message that can't be reliably deleted.  Is that right?

Correct.

> what is the knob-twiddle that would cause it?  who has to twiddle the
> knob to get that wrong?

The user accidentally extends the expiry date on the wrong subkey. Which 
as I have argued above, will always be a risk if we reuse existing formats.

> The way i'm currently thinking about it is these certificates will work
> with modern OpenPGP implementations. As long as their implementations
> can handle RFC9580, the peers that access the certificate at least don't
> need to implement anything other than the already-known semantics about
> expiration.  In particular: don't encrypt to expired encryption-capable
> subkeys.

Right, and if we're just helping people to rotate their subkeys more 
often by giving them better tooling, there is some merit in that. But 
subkey rotation is not completely cost-free for the other correspondent.

> If we were to use a distinct new critical wireformat change (new packet
> type, critical signature subpacket, etc) to mark a component key as "not
> renewable" (for example) then we risk being unable to even distribute
> the associated certificate to a brittle RFC9580 client that might
> complain about or reject the entire certificate.  On the other hand, if
> we use some non-critical extension or signature subpacket (or other
> similar inoffensive wireformat change) to distribute it, then we face
> the same risks that i think you're describing.

If we are using a new wire format, we don't have to distribute it in a 
certificate, or at least not a traditionally-formatted one. I'm just 
thinking off the top of my head here, but we could (throws dart at a 
board) define a new UAT subpacket and put both the ephemeral key and its 
binding signature in the UAT, so that legacy code will think the UAT is 
unbound and silently ignore it. I'm sure we can think of plenty of other 
ways of doing it that are invisible to legacy code...

A

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