Subject: [Openpgp-dt] 2022-03-02 design team meeting notes

From: Stephen Farrell <[email-masked]>
Date: Wed, 2 Mar 2022 16:11:36 +0000

OpenPGP Design Team
2022-03-02

Present:
dkg
stephen
gniibe
paul
daniel H
justus

# Agenda

## non-substantive MRs
- leave to editor's choice or fine to handle later

## AEAD Preferences
    https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/146
- ciphersuites vs. cross-product
- merged

## OCB Nonce size
    https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/83#note_859282506
    - 120 vs 96 bit nonces?
    - concern is whether some library might have hard-coded 96 bit nonces
    - dkg did some digging, openssl doesn't hard-code, python wrapper 
might as there're no published test vectors
    - daniel H: doesn't matter either way (security wise), maybe if 96 
bits everywhere that could be (a bit) simpler
    - 96 means re-doing test vectors
    - go with status quo (120), maybe flag issues (incl. this) for which 
we want WG review (if there are some for which we don't need such 
review) dkg will check
    - Stephen added a note to the issue describing why we did this

## gniibe: hash field for HKDF?
- should we support/mandate hkdf-sha384 when using aes256? (currently we 
have hkdf-sha256)
- gniibe: not after flexibility, more a concern about commensurate strength
- daniel H: not sure there's a real security concern (as collisions 
aren't a deal with hkdf)
- dkg: thinking how we'd do this (without flexibility)
- could be a new field
- could add column to IANA registry (or whatever) saying to use hkdf-sha384
- daniel H: there're other uses of hkdf, not sure how a change here 
would generalise
- SF: any API issues with hkdf-sha384?
- justus: also tied to size of salt (SF not following)
- gniibe: no strong objection to hkdf-sha256, just noticed tls1.3 has 
different combos
- conclusion: keep as-is but good to have considered this

## gniibe: OCB nonce structure
- current scheme came from 
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/84)
- gniibe: we're doing things differently from tls/openssh, is that 
ok/good/better?
- dkg: random starting point leading to overflow may differ for us
- justus: there's a trade off here vs. chunk size (that the note-taker 
didn't get;-)
- gniibe: concern is how we do/don't conform to SB800-38D
- https://csrc.nist.gov/publications/detail/sp/800-38d/final
- that says: "the probability that the authenticated encryption function 
ever will be invoked with the same IV and the same key on two (or more) 
distinct sets of input data shall be no greater than 2-32"
- dkg: in our case, nonce-reuse with same key doesn't arise really
- gniibe: ok with current spec, even if it looks a bit strange, it's ok 
as we're using hkdf to generate key
- ACTION: gniibe will add a note to issue#84 about this so we don't 
forget that we considered it

## AEAD preferences placement
- dkg: where do we put these? historically those have landed in user-id 
but we seem to be moving more towards having these associated with keys 
(that have decryption-capability)
- so can we say that for v5 keys, (some) preference packets belong with 
keys/self-sigs?
- dkg willing to try write text/MR along those lines (not for next I-D)
- that might mean v5 keys don't need user-id
- daniel H: I'd go further to say that prefs are property of entire cert 
and always go in self-sig and not elsewhere
- justus: raises question wrt which subkeys are usable for encryption
- this leads to questions about how many certs per user or device
- dkg: would be ok with something simpler than initially proposed, will 
write up something for discussion @ ietf113 (not for next I-D @ weekend)
- justus: prefs on certs tend to be unreliable/out-dated so can get 
ignored (people nod)
- that leads to good thoughts (around cert maintanence) that are beyond 
a crypto-refresh (but could be tee'd up by how we handle this)

## Test Vectors
- justus: was waiting for a couple of things to settle, and test vectors 
should also include padding so 1st time people try things they have to 
handle that
- dkg: anyone else able to contribute test vectors before
- daniel H: could make some, modulo issues related to where to put 
self-sigs and prefs
- dkg: discussion with a concrete artifact in-hand may be better (people 
nod in video)
- daniel H: his preference is to shift to direct key sigs, not sure we 
have text in spec for that yet, but not before Monday
- generally DT are fine with daniel H's approach (for v5 keys) and would 
like such test vectors (if we discover problems we can fix/change later)
- daniel H: will try do that, do we want some corresponding text? (e.g. 
#134)
- conclusion: we'd like test vector now if possible, maybe leave #134 
for later as it covers other stuff too that may need more discussion
- daniel H: do we want aead prefs in test vectors too? dkg: yes, if poss 
but don't block on that for this weekend

## next I-D (Monday deadline)
- @paul: what do you need from us?
- paul: only really waiting on test vectors, otherwise good
- deadline for input to paul: early Sunday his TZ
- ACTION: chairs to send mail to list about this being an 
"implementation draft"

## IETF113 agenda
- SF will send draft agenda to DT list, then WG list in next day or so, 
will also ask who wants to present stuff/who'll be in-person

## interop
- daniel H: can anyone else check my v5 sig outputs?
- not that we know (but daniel H has 2 x implementations)

## preferences placement in certificates
- rough consensus in the DT seems to be that all preferences for v5 keys 
should be certificate-wide, placed in a direct key signature on the 
primary key.
- ACTION: dkg to take a look at #134 to see whether it can be used to 
document this, or if not, to propose alternate text.
- key maintenance is something that implementations have not prioritized.
- ACTION: dkg to look at updating sop for certificate management: asking 
implementations to be able to "refresh" a key might be useful.