Subject: [Openpgp-dt] 2021-11-15 meeting notes

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Nov 2021 15:13:34 +0000

2021-11-15 OpenPGP DT meeting

Attending:

Stephen Farrell
NIIBE Yutaka
Jeffrey Lau
Daniel Huigens (after 30m)
Daniel Kahn Gillmor (after 30m)
Justus Winter (after 30m)
Paul Wouters (after 1h)

Proposal: Tuesday 12:30 UTC or Wednesday 12:30 UTC

Stephen: wednesday is less good, but ok

We believe Paul would prefer wednesday

no other preference, going with Wednesday

November 24th 1230 UTC is next meeting.

IETF112 session seemed happy with DT progress.

# Topic: AEAD modes and FIPS

At IETF112 session we had some discussion about FIPS and AEAD modes. 
NIST have only really studied/approved GCM, so if we want to be 
FIPS-friendly we may need to support that. Today, we don't have a 
well-defined way to use GCM but do have some early code. Daniel H offers 
to write up a proposal, to be done after a bit of checking to be done first.

Likely DT take would be to not make that GCM option MTI.

New thought: adding GCM makes 3 AEAD modes (OCB, EAX and GCM). Maybe we 
could consider dropping EAX given GCM isn't slow. We'll consdier that 
once we have the HOTWO do GCM proposal.

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/48

AES-256? Currently that's a SHOULD. We're not worried that people won't 
implement it (as far as we know everyone has). Gniibe points out that 
making aes256 a MUST ought likely be accompanied by curve448 also being 
a MUST.

ed25519 needs sha512 internally, so ought sha512 itself be a MUST? We 
can't ditch sha256 though as that's needed for fingerprints. Nonetheless 
we figure leaving 512 as a SHOULD seems best.

webassembly of sha256 is feasible (openpgpjs ships one) but sha512 would 
be much larger, so they ship a straight js version (which is slower).

ZIP->ZLIB change: we chatted about it, wondering if there were realistic 
CRIME like threats that'd cause us to not want the SHOULD. Such attacks 
seemed a bit of a stretch for mail (though some footer+many-drafts 
scenarios could maybe approach the way JS enables CRIME on the web).

Related, padding: Justus points out that a ZIP or ZLIB stream allows 
garbage at the end of the streaam and that can be used as a way of 
padding. But maybe we want a better way to pad so we'll return to that 
topic.
Padding issue: https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/55

We say "Implementations MUST implement uncompressed data." then we 
discussed also saying "Implementations MUST NOT use uncompressed data." 
:-) That looks odd doesn't it? The context is handling of compressed 
data packets (which allow passing uncompressed data) so it may be less 
crazy than it seems. But some clarification may be helpful here as it's 
confusing. Daniel H volunteered to try propose text.

# Editing

Paul W will spend a bit of time checking to see what's left for us.

Justus has made a couple of new MRs cleaning up stuff. Please 
read/comment/approve between now and 24th to the extent you can.
DKG also points out some others exist that could do with the same kind 
of work.