[openpgp] Re: review of draft-ietf-openpgp-persistent-symmet ric-keys-01

Am 02.09.25 um 23:23 schrieb Daniel Kahn Gillmor:
> I appreciate the detailed thought in this exchange that is put into how
> these things will actually be used, and what the risks are for those
> likely uses.
>
> I'm not sure how much this draft needs to spell those out (which i take
> to be something like Falko's position) and how much it can just describe
> the mechanism as a stepping stone for future applicability work (which
> is a sketch of what i'm reading as Daniel's position).  I personally
> tend to want to see at least some clear use case rationales and thoughts
> about security risks over pure mechanism for mechanism's sake.
What do you mean by "over pure mechanism for mechanism's sake"?
>    I'd be
> curious to hear what other members of the working group think about this
> tradeoff.

A "stepping stone" can also be interpreted as a "half-way" solution to 
an applicable system. The danger that I see with this is that 
implementers might start using the "stepping stone" as soon as the RFC 
is out. If their use conflicts with the later intended use, that seems 
to be bad outcome. But as I point out below, with the specification to 
use time stamping signatures for "freezing" messages and a pointer to 
the respective section in draft-gallagher-openpgp-signatures, as DKG 
suggests, this problem seems to be solvable quite easily.

>
> Specific comments interleaved below:
>
> On Wed 2025-08-20 15:34:49 +0200, Falko Strenzke wrote:
>> Am 19.08.25 um 15:52 schrieb Daniel Huigens:
>> Any ambiguity of an HMAC signature would have to be ruled out.

For the sake of context: the above quote from my message was preceded by 
the following text:

/Take for instance the case where an HMAC key is used for communication 
and is shared between Alice and Eve. If Eve makes up an invalid 
signature for a signature key of Bob, applies an HMAC signature to it 
(in what ever way that you have in mind for the use case of storage 
MAcing), and sends it to Alice, how would Alice's client then know that 
it must not show the message as validly signed?/

> Falko, what if we took the fact of symmetric cryptography out of the
> picture entirely here.  Do you think that OpenPGP asymmetric signatures
> have this kind of ambiguity?
In principle yes. But the persistent symmetric keys draft specifically 
addresses the "freezing" of signatures as a use case. So I see two 
option: a) specify how the use case is to be implemented; b) don't 
mention the "freezing" of signatures at all. In the latter case I would 
agree that then there is not really a difference to the use of 
asymmetric signatures.
>
> Presumably, the signing secret key is known only to the keyholder
> (shared among their multiple devices, perhaps, or just used for the sake
> of backup and recovery with a single device).  If Alice re-signed a
> message from Bob today, the signature would still be "Alice's
> signature", right?  And therefore wouldn't be normally applicable to a
> message from Bob.
The problem with symmetric "signatures", i.e. MACs, is that Alice's and 
Bob's signatures with the same MAC key aren't distinguishable. That's 
what makes it different from the asymmetric signature case. But the 
problem would be solved by using time stamping signatures for that purpose.

>
> So if we're talking about how to make timestamping (or similar) claims
> about other signatures, that's mechanism we'd need to flesh out even in
> the case of non-symmetric signing algorithms.
>
> Does anything from draft-gallagher-openpgp-signatures address this
> concern?

I think so, yes, Section "3.5. Timestamp Signature (0x40)" seems to 
sufficiently specify how to create time stamp signature over a message. 
If the persistent symmetric keys draft pointed to that document for how 
to "freeze" a signed message, that would solve the "half-way" problem I 
point out above in my view.

>
>> I think the draft needs to address the security considerations that
>> apply to introducing HMAC as a signature scheme. It is just not
>> equivalent to asymmetric signatures.
> Falko, can you propose some text for the security considerations section
> that would address your concerns?  Having something concrete might make
> the conversation more fruitful.
I think I can propose something, yes. Under the assumption that the 
persistent-symmetric keys draft will refer to 
draft-gallagher-openpgp-signatures for the time stamping / signature 
wrapping (or specify a different approach if necessary) the points to 
cover in the Security Considerations seem mainly:

- Guidance on the symmetric key size
- Guidance on symmetric key exchange between users
- Guidance on how to display symmetric "signatures" to users

I also suggest that we add a sentence the security considerations of 
draft-gallagher-openpgp-signatures about the display of time stamping 
signatures. With all that, it currently seems to me that all important 
security aspects are covered for the use of persistent symmetric keys 
for communication as well as recrypting and time stamping of stored 
messages. It would still be good to address migration considerations for 
the latter two use cases, as I had suggested in my review. But that 
doesn't necessarily have to happen in the persistent symmetric keys draft.

@Daniel H.:
- Do you agree with this approach for the security considerations? 
Should I suggest a text for the security considerations as outlined above?
- Do you think that using time stamping signatures is the right way?

Falko

>      --dkg
-- 

*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]