Re: [openpgp] Review of crypto-refresh 07

[Falko Strenzke <[e-mail]>]

Hi Paul,

Am 16.11.22 um 23:01 schrieb Paul Wouters:
> On Wed, 16 Nov 2022, Falko Strenzke wrote:
> ## 9.2. ECC Curves for OpenPGP
> The alternative to not even checking MD5 is worse. The text states to
> use this only for old (stored) messages, not new incoming messages.

The alternative I propose would be to indicate a verification failure. 
MD5 is broken and generally phased out as a signature hash algorithm 
since about 20 years.

Note that the same document forbids the verification of RSA signatures 
with less than 2048 bit keys: "An implementation MUST NOT encrypt, sign 
or verify using RSA keys of size less than 2048 bits". An RSA key 
between 1024 and 2047 bits is not yet broken. For MD5, anyone can 
download tools to build collisions on the internet and forge signatures. 
So I think it would be good to have a clarification why these cases are 
treated so differently by this specification.

Also I am not sure to understand the whole concept of "old signatures" 
that are known to be stored for a long time. If one knows to have 
received a message long ago and that it is unmodified since then, what 
is then the gain of a repeated signature verification at all? If I 
really now that a message is unmodified since a time in the past where I 
received it and back then I still trusted the signature mechanism 
(including the hash function), I don't need a new signature verification 
at all. If I think I need to repeat the verification, my trust in the 
message not having been modified apparently is not high enough. And for 
sure non-repudiation is completely irrelevant in the view of a broken 
hash algorithm.


>> ### Table 32
>>
>> "Table 32: Key length equivalences" would benefit from making clear 
>> to what algorithms "Asymmetric key size" pertains and from the 
>> addition of EC key sizes.
>
> There is no specific algorithm for these "rough estimates" of strength.
> We are simply quoting NIST and they have generalized these numbers. I do
> not think a text change is needed here.
What I meant by "algorithm" is what cryptographic algorithm that column 
pertains to. Clearly, the column "Asymmetric key size" refers to RSA and 
DL groups. Extending it by ECC key sizes would make sense in my opinion 
as that is the current preferred standard in OpenPGP if I understand 
correctly. See 
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf 
page 67 for the security strengths of ECC parameter sizes.
>
>> ###  14.7. Avoiding Ciphertext Malleability
>>
>> The list following the sentence "Any of the following OpenPGP data 
>> elements indicate that malleable ciphertext is present:" mixes 
>> instances of malleable ciphertext formats with non-malleable 
>> ciphertext formats where the ciphertext has been manipulated. This 
>> should be corrected.
>
> Do you have specific text in mind? Split the listing in two, or remove
> the entries that have no malleable ciphertext ?
I would split the list. If preferred I can make a merge request with a 
proposal.
> ## 14.7. Avoiding Ciphertext Malleability
>>
>>> When encrypting to one or more public keys: all recipient keys 
>> indicate support for version
>>
>> Insert "If" after the colon.
>
> I cannot locate this text? Perhaps it was changed since you read it, or
> this was a note of you based on an older version?
This is the link: 
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-07.html#section-14.7-9.2.1
>
>> ## A general note on terminology used to refer to bits
>>
>> * In certain places bits in a byte are referred to by number, e.g. 
>> "bit 7". There is an instance where the meaning of this numbering is 
>> explained, but it is contained in a section under which it is not 
>> easily found. I recommended to
>>   introduce this notation in a preliminary section for easy reference.
>
> Please provide text and location where you would want this.

The definition of the bit numbering is given here: 
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-07.html#name-packet-headers

A use of the numbering is found here: 
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-07.html#section-5.2.3.5-10

and here: 
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-07.html#section-5.3.2-4

and more places.

The specification of the bit numbering could be given in a new section 
under Section 3 
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-07.html#name-data-element-formats

If the section numbering shall remain unchanged, one could put it 
instead into the existing section 
https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-07.html#name-scalar-numbers 
(with a possible title change, but strictly viewed, octets are just 
8-bit scalar numbers)

>
>> ## 4.1 Overview
>>
>>>  In the event that a subfield length indicator within a packet implies 
>> inclusion of octets outside the range indicated in the packet header, 
>> a parser MUST truncate the subfield at the octet boundary indicated 
>> in the packet header. Such a
>> truncation renders the packet malformed and unusable.
>>
>> If the packet becomes invalid altogether, it is not necessary to 
>> describe the truncation of the subfield. In the current form, this 
>> paragraph seems a bit confusing and bears the risk
>> that it is interpreted differently by readers. It should be clearly 
>> said by the specification if a packet becomes malformed and must be 
>> ignored / flagged as erroneous when one of its subfields refers to 
>> octets outside the packet's range.
>
> I think what this is trying to do is prevent out of bounds writing,
> which could possibly lead to remote code execution. I've changed it to:
>
>     In the event that a subfield length indicator within a packet implies
>     inclusion of octets outside the range indicated in the packet 
> header, a
>     parser MUST abort without writing outside the indicated range and 
> MUST
>     treat the packet as malformed and unusable.
I think this paragraph is rather about preventing *reading* outside the 
packet range. So I would replace the word "writing" with "reading" in 
your proposed text.
> ## 11.3. OpenPGP Messages
>>
>>>  (comma represents sequential composition, and vertical bar separates 
>> alternatives)
>>
>> I propose to add "([...] alternatives
>> *, where the comma operator takes precedence over the bar operator*)"
>
> I don't think that is needed, as | represents an alternative, so clearly
> it works as an OR and then the binding becomes logical anyway, eg:
>
>     : Signature Packet, OpenPGP Message | One-Pass Signed Message.
>
> Though reading this now, that makes no sense for this one:
>
>     : OpenPGP Message | OpenPGP Message, Padding Packet.
>
> So even your interpretation is wrong :)

For this example:

Optionally Padded Message :- OpenPGP Message | OpenPGP Message, Padding 
Packet

I still think my interpretation is correct also here: when the comma 
takes precedence, it has to be read as

Optionally Padded Message :- OpenPGP Message | (OpenPGP Message, Padding 
Packet)

which is what I understand is meant. But it would be good to have this 
interpretation confirmed to be valid for the whole list.

- Falko

>
> Perhaps this last one should have been:
>
>     : OpenPGP Message , OpenPGP Message | Padding Packet.
>
> This could use some clarification on the list as well before making 
> changes.
>
> Thanks again for the review!
>
> Paul
-- 

*MTG AG*
Dr. Falko Strenzke
Executive System Architect

Phone: [phone]
E-Mail: [e-mail]
Web: mtg.de <https://www.mtg.de>


*MTG Exhibitions 2022 – Let´s meet again!*

------------------------------------------------------------------------
<https://www.itsa365.de/de-de/companies/m/mtg-ag>

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>