Subject: [Openpgp-dt] 2021-11-24 DT minutes

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Nov 2021 16:53:50 +0000

OpenPGP DT meeting 2021-11-24

Present

Stephen
Daniel H
Gniibe
Jeffrey
Justus
Paul

# Agenda:
     - outline of cross-mode keying thing from list
     - merge request/issue processing

# outline of cross-mode keying thing from list

Daniel H describes issue - we'll discuss (possible changes resulting) 
more next week.
The problem: if decryption oracle for CFB exists, for symmetrically 
encrypted data packets, then an attacker can use that might also provide 
an oracle for GCM decryption.
Action: Daniel H will create issue

# MRs/issues

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

Small part of "v5-ing" - but having checked we're all happy with overall 
v5-ing.
This MR generates discussion of whether or not we want to/should link 
all v5 "features" so they MUST be used together.

Seems ready to merge, could be affected later as we figure linkage issue.

## V5? Fingerprint

https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/44
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/45

### Initial discussions:

Issue: what's a v5 fingerprint? what's a v5 fingerprint of a v4 key? ...
Usability issues made worse if >1 fingerprint exists per key.
Usability made worse the longer the fingerprint (if you depend on the FP 
comparison for security)

Agreement that we don't want to make usability worse. But there may be 
limits to what can be improved.

Maybe adopt shake for FP?

Possible alternative to sha256, use sha-1 modified as git et al did 
(https://github.com/cr-marcstevens/sha1collisiondetection)

### Questions we need to answer (with strawperson answers):

     - output length: at protocol level 32 octets
     - alg for producing them: maybe sha256 (if that gets busted, you 
need new keys)
     - how to handle the existence of >1 FP per key
     - if you have a v5 key it has precisely one FP
     - tricky questions arise though when someone has to deal with both 
v4 & v5
     - different display conventions
     - we could define a v5 FP -> QR code scheme
        - 8 octet value/keyid as short form? preserve that or ditch it?
        - for protocol uses: we probably do all want to get rid of these
   - maybe we can not even define that for v5 FPs?
Action: Justus to generate suggestion/MR based on the above

---

From: Justus Winter <[email-masked]>
Date: Wed, 24 Nov 2021 18:21:53 +0100

> (https://github.com/cr-marcstevens/sha1collisiondetection)

Sorry that I didn't catch this in time.  The context was that Daniel
mentioned that ProtonMail is computing SHA256 "fingerprints" for *v4
keys*, to which I replied that an alternative to doing that is to use
SHA1CD to compute v4 fingerprints.

So, in case anyone is wondering, we're in no way thinking about sticking
with SHA1CD for v5 fingerprints.

Justus

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 24 Nov 2021 17:22:49 +0000

Hiya,

> with SHA1CD for v5 fingerprints.

Nope, that's my fault for getting the wrong end of
the stick! Thanks for correcting.

Cheers,
S.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Tue, 30 Nov 2021 09:04:29 -0500

> with SHA1CD for v5 fingerprints.

In any case, we could explicitly retcon v4 fingerprints to be SHA1CD,
not SHA1 in the crypto-refresh draft.

 ("retcon" means "retroactive continuity"; it's a term from serialized
 fiction -- think comic books and tv shows -- where future episodes
 provide an alternate explanation for facts that appeared to be evident
 from previous episodes)

Re-defining any existing, stored protocol element (as v4 fingerprints
most certainly are) in this way is a little unusual, but i'm having a
hard time coming up with an argument against doing so.

operationally, i suppose it would require any existing index of public
keys to be rebuilt, but there are probably clever ways to do that on an
as-needed basis, which implementers can figure out as appropriate for
their implementation.

I suppose we could even retcon hash algorithm 2 more broadly to be
SHA1CD across all of OpenPGP, not just the v4 fingerprint.  As long as
that doesn't draw out people's expectations of deprecating SHA1
properly, that might make it easier for implementers (no need to have
both SHA1 and SHA1CD in your implementation).

This seems like an independent choice from the question around v5
fingerprints.

         --dkg

---

From: Justus Winter <[email-masked]>
Date: Tue, 30 Nov 2021 15:23:56 +0100

> both SHA1 and SHA1CD in your implementation).

For the record, that is exactly what we did.  To prevent a further
proliferation of SHA1, we baked a deprecation mechanism into the
software.  From our docs:

> [..] we start rejecting SHA-1 in cases where collision resistance is
> required in 2013, and completely reject it in 2023:
>
> > Since 2005 SHA-1 has not been considered secure against well-funded
> > opponents, as of 2010 many organizations have recommended its
> > replacement. NIST formally deprecated use of SHA-1 in 2011 and
> > disallowed its use for digital signatures in 2013. As of 2020, attacks
> > against SHA-1 are as practical as against MD5; as such, it is
> > recommended to remove SHA-1 from products as soon as possible and use
> > instead SHA-256 or SHA-3. Replacing SHA-1 is urgent where it's used for
> > signatures.
>
> (Wikipedia on SHA1, Accessed Feb. 2020.)
>
> There are two main reasons why we have decided to accept SHA-1 for so
> long. First, as of the end of 2020, there are still a large number of
> certificates that rely on SHA-1. Second, Sequoia uses a variant of SHA-1
> called SHA1CD, which is able to detect and mitigate the known attacks on
> SHA-1's collision resistance.

(from https://docs.sequoia-pgp.org/sequoia_openpgp/policy/struct.StandardPolicy.html#method.reject_hash_property_at)

> This seems like an independent choice from the question around v5

Yes.

Justus