search

openpgp-pqc / draft-openpgp-pqc

Repository of the WIP draft-ietf-openpgp-pqc
Other
8 stars 2 forks source link

symmetric algorithm preferences: clarify what happens in the absence … #110

Open TJ-91 opened 3 months ago

TJ-91 commented 3 months ago

…of the subpackets

Closes #106

Not sure if the last sentence is really required, but the Crypto Refresh leaves a lot of room for implementations to determine v2 SEIPD support so it can't hurt.

TJ-91 commented 3 months ago

@wussler @dkg Thanks for the fixes and suggestions.

The reason I wrote the text is given in #106:

The crypto-refresh does not clearly state that the implicit lists of preferred algorithms are in force even when the respective subpacket is missing. We should clarify this at least in the PQC specification.

In 5.2.3.15. Preferred AEAD Ciphersuites strictly speaking, it is not described what happens in the absence of the subpacket. The same is true for the non-AEAD stuff (see 12.2. Symmetric Algorithm Preferences).

I do think it's not a problem in the Crypto Refresh since it's clear enough what algorithm to choose in such a case since there is only one choice left, the MTI algorithm. Now we extend this mechanism and set more implicit default options to the lists of the subpackets. Now there is ambiguity in the case of a missing subpacket.

I am also not very happy with the additional text but with the reasoning I gave, do you still think we can drop this clarification completely?

wussler commented 3 months ago

I am also happy with @dkg's proposed text, and I think it's now clear what to do in the case of missing subpackets. I also think here would be the right place to add a "forbid SED tag 9" for issue #91

dkg commented 3 months ago

@TJ-91 i see what you're saying about the specifics of what is missing, but (a) the text you're proposing is a lot of words to say "for these purposes, treat a missing subpacket the same as an empty subpacket", and (b) i don't really know what the alternative interpretation would be likely to be. are you suggesting that an implementer might really think "if they have an empty AEAD ciphersuites subpacket, then i know i can use AES256-OCB, but if they have a missing AEAD ciphersuites subpacket, then i know i have to fall back to AES128-OCB"? That would be very weird.

Maybe this would be best illustrated in a test vector, with a minimal certificate with a PQ/T encryption key, and a features packet that supports v2 SEIPD, and no AEAD Ciphersuites subpacket. then the test vector could include an encrypted message that uses AES256-OCB .

TJ-91 commented 3 months ago

are you suggesting that an implementer might really think "if they have an empty AEAD ciphersuites subpacket, then i know i can use AES256-OCB, but if they have a missing AEAD ciphersuites subpacket, then i know i have to fall back to AES128-OCB"? That would be very weird.

That's true, there is not much potential for harm here.

Maybe this would be best illustrated in a test vector

I don't think the test vector really conveys the message (many would probably not notice the detail or if they do, be confused by it).