[Openpgp-dt] Design Team Meeting minutes 2021-08-20

[Daniel Kahn Gillmor <[e-mail]>]

# Notes from OpenPGP Design Team Meeting 2021-08-20

Attending:
	* dkg (taking notes)
	* jeffrey lau
	* daniel huigens
	* paul wouters
	* justus winter

!56 discussion rises again: chunk sizes for AEAD

The group on the call agrees with Werner's framing in MR 56, but
changing the final SHOULD NOT to a MUST NOT, in line with what Werner
proposed in the previous call.  Paul will make a commit with that
change.

Given that decision, a final discussion remains about how
implementations should *process* an AEAD packet with a chunk size
octet > 16:

Options identified:
	* chunk sizes > 16 are explicitly Reserved
	* explicitly say MUST NOT process
	* say nothing
	* explicitly say SHOULD NOT process
	* explicitly say MAY process

On the call, there was a rough consensus around either MUST NOT or
Reserved, with Paul being willing to stand aside.

Huigens pointed out that values above 56 are reserved right now.  if we
change the leading text, that reservation might apply to things above 16
instead.  So if the updated text implies that above 16 is reserved, we
may not need any other changes. That is, "say nothing" has the same
effect as "explicitly Reserved".  If the revised text leaves it that
way, we may prefer the "say nothing" approach.

Concerns raised about permitting processing of larger chunk sizes:

 * chunk size is attacker-controlled value that might implicate memory
   allocation -- it is very difficult to reason about memory allocation
   from the application's point of view (justus)
        
 * combinatorial explosion between different parameters that need
   testing (justus)
   
 * implementations faced with chunk sizes larger than they can process
   are pressured to release unauthenticated data (before they've
   validated the authentication tag) (huigens)

 * having more chunks in a ciphertext means you can parallelize the
   processing better (huigens)

Concerns about limiting processing of larger chunk sizes (from Paul):

 * making decisions based on future hardware assumptions without strong
   need to place limit currently might negatively impact future
   interoperability

 * with IPSec, everything has to go through one CPU, because no one
   thought about that as an issue -- we don't know what we'll encounter
   in the future, better in general to leave more flexibility and less
   constraint.

ways to fix problems that we run into in the future if we decide we want
to encourage production of larger chunk sizes:

	* new AEAD version number (justus)
	* come up with a new packet entirely (justus)
	* signalling mechanism for support from readers (dkg)

# Next Week

Huigens wants to talk about curve448:
	* format/structure: same as 25519 vs distinct
	* please review MR 61 before next week as preparation

Justus wants to talk about v5 key format
	* please review issue 43 as prep