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

From: Stephen Farrell <[email-masked]>
Date: Wed, 16 Feb 2022 14:22:27 +0000

OpenPGP WG Design Team meeting 2022-02-16

Present:
- justus
- dkg
- gniibe
- jeffrey
- stephen
- daniel H
- paul

Agenda:
     - usual MR/issue processing
     - next I-D

We seem to have 11 open MRs as of now.

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/135
- ready to merge? just has one approve but was previosly approved to 
yeah, good to go

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/136
- justus updated that and generated some test vectors (yesterday)
- daniel H: should be fine
- ocb nonce still 15 octets for now (easily changed later if needed)
- suggestion: merge and fix later if needed
- agreed, please merge after 135, paul will unmark-as-draft

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/134
- daniel H: <describes content and discussion:-)>
- dkg: ostensibly there can be other prefs (e.g. enc algs) per userid 
(not convinced himself, just reporting; better to use >1 key), but 
that's been part of the spec for ages - this MR gets rid of that 
use-case, that probably needs explicit text saying we're making a change
- justus also doesn't like that "feature"
- justus: justification for wanting 1 sig is to prevent stripping e.g. 
key expiration time, but that doesn't work if there's ever been a sig 
without that data
- ...notetaker (SF) distracted...
- various better ways to handle preferences discussed, justus raises 
point that such may be out of charter (even if desirable)
- dkg: confusion over alg prefs does relate to a crypto-refresh but... 
parts of this are defo at the boundary of what's in-charter
- discussion as to which attacks may be mitigated in which threat r 
deployment models, but those vary
- dkg: can we untangle different aspects of this? e.g.
- how/where to put preferences;
- are we requiring a self-sig on a userid? (spec guidance hasn't matched 
reality)
- ...
- goal here isn't to get this for next I-D (needs more thought) but 
rather to prepare to discuss this with WG @ ietf113 given it borders on 
charter things

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/118
- padding, nearly there
- this is new, not deployed (there's always a ? there:-)
- maybe s/backwards interop/interop/ @ line 2451 currently (paul wil do 
that)
- the SHOULD (@ 2446?) doesn't have guidance about when it's ok ti not 
follow the SHOULD
- someone with a need to pad v4 might use this packet
- paul: if so, wouldn't there need to be a flag saying "I can do v4 
padding of type <foo>"
- dkg: ok with it as-is
- paul: other concerns addressed
- dkg: this needs to be rebased
- paul: will fix in next day or so and merge

# https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/114
- let's merge now and validate later, good to have 'em
- agreed to merge

# daniel H: do we want/need an MTI AEAD mode?
- daniel H will to make MR
- dkg leaning towards OCB
- process via mail in next day or two
- if we don't reach consensus via mail then omit this from next I-D

# other open MRs we're ok to leave for now (for next I-D)

# dkg: we'd like people to valdidate test vectors in next I-D as far as 
possible, might make a MR to improve usability of those after next I-D out

# actions:
- aead mti mode via email
- paul do merges then pop out I-D
- chairs - announce that I-D as interop version to list
- chairs - create agenda for vienna

# all: think about what to do as a DT after vienna, maybe e.g. different 
cadance or more topic driven

# next week: maybe skip or smaller call (vacations etc.)

---

From: Daniel Huigens <[email-masked]>
Date: Thu, 17 Feb 2022 10:51:35 +0000

Hi all,

I've created a MR for the MTI AEAD algorithm here: [!137].

I also realized that we should probably also add key separation for the
V5 Symmetric-Key Encrypted Session Key Packet. We had this in [!101],
but lost it in the series afterwards starting with [!128].

I created a MR to add it back in [!138]. Hopefully this seems reasonable.

Unfortunately, this does invalidate the test cases. Apologies for not
thinking of this earlier, particularly to Justus. Hopefully this
doesn't cause too much extra work (if you agree that this is something
we should have).

Best,
Daniel

[!137]: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/137
[!101]: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/101
[!128]: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/128
[!138]: https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/138

---

From: Justus Winter <[email-masked]>
Date: Thu, 17 Feb 2022 13:03:41 +0100

> but lost it in the series afterwards starting with [!128].

Can you explain which key spaces you want to separate?

For SKESKv5/SEIPDv2 messages, encryption is done at two points.  First,
in the SKESK packet to encrypt the session key, then in the SEIPDv2
packet to encrypt the payload.

The SEIPDv2 provides key separation, so I guess you are talking about
the SKESK step.

I don't think that key separation between ciphers or AEAD modes in
SKESKv5 is an issue, because cipher and mode are part of the additional
authenticated data.

So that leaves separation between SKESKv5 and SKESKv4, i.e. downgrading
an AEAD-encrypted session key to a non-AEAD encrypted session key.

Is that actually a problem?  By doing such a downgrade, the attacker
only gains the ability to make the encryption wrapping the session key
malleable, i.e. to give the victim a different session key.

Furthermore, considering that the shape of the plaintext changes
(SKESKv4 packets have the cipher octet prefixed to the session key),
even if the ciphertext is now malleable, it is not clear that the
attacker can prefix an octet (that decrypts to a useful cipher octet)
while preserving the session key.

As far as I can see, the attacker can prevent a successful decryption of
the whole message, but that is something an attacker controlling the
transmission channel can do in other ways too.

> I created a MR to add it back in [!138]. Hopefully this seems reasonable.

I'm not convinced that this is necessary, or adds any protection.

Thanks,
Justus

---

From: Daniel Huigens <[email-masked]>
Date: Fri, 18 Feb 2022 11:03:51 +0000

Hey Justus,

> Can you explain which key spaces you want to separate?

In general, it's both between different AEAD modes and between AEAD and CFB.

The "general" justification of this is still [0], particularly section
3.2, however it's difficult to say if there's a specific attack today.
However, it seems safer to me to protect against it anyway, in case an
attack is found tomorrow. Especially if we're already protecting against
it everywhere else, it seems like an oversight not to do it here.

> SKESKv5 is an issue, because cipher and mode are part of the additional

In principle, we shouldn't rely on the AD of an AEAD mode if we don't
know (yet) that it's the one we should be using.
If an attack in any of the AEAD modes is ever found, then all of them
would reduce to the security of the weakest one. So in that sense,
putting the AEAD mode in the AD doesn't seem to help much.

> malleable, i.e. to give the victim a different session key.

The attack that the paper presents, allows the attacker to find out
something about the plaintext (which in this case is the session key).
Whether the attack actually works in this case I'm not sure, but if
(worst-case scenario) an attacker could find out the session key based
on some error messages (presumably after trying multiple times, or when
sending multiple session key packets), that would be quite bad.

In any case, I agree the attack is not as clear-cut as the SEIPD v2/v1
case, and it's quite late to make this change now, for which again I
apologize, but I think if we'd considered the approach of using HKDFs
for key separation in the first place, we would have done so
consistently, and I think we still should do so now.

Best,
Daniel

[0]: https://www.ndss-symposium.org/wp-content/uploads/2017/09/10_4_0.pdf

---

From: Justus Winter <[email-masked]>
Date: Fri, 18 Feb 2022 15:47:57 +0100

Hi Daniel :)

> putting the AEAD mode in the AD doesn't seem to help much.

I think you are saying that an attacker may be able to produce/derive a
ciphertext/tag combination that is valid under a different cipher and/or
AEAD mode *without* being in possession of the symmetric key (that is
derived from the password).

So we assume that an attacker can break the authentication property of a
mode without breaking the confidentiality.  Essentially, the remaining
construction has the properties of a SKESKv4 packet, which uses a
malleable block cipher mode.

>> malleable, i.e. to give the victim a different session key.

As above, we are at a point where an attacker can modify the
ciphertext.  If we are concerned about ciphertext modification attacks,
I think we need to disallow SKESKv4.

> sending multiple session key packets), that would be quite bad.

Decryption oracles are quite bad.  This seems to be orthogonal, though.
And, as noted above, if we are worried about that, we cannot process
SKESKv4 packets.

Also, we're talking about decryption oracles that presumably have humans
in the loop entering passwords.

(Note that the attack in the paper uses a very strong oracle model.)

> consistently, and I think we still should do so now.

I'm somewhat skeptical.  I'd like to hear from others, and I'd prefer us
to merge whatever changes we deem necessary before I update the test
vectors again.  It is not that it is hard work, but is annoying work
that is easy to mess up if one isn't paying close attention :/

Thanks,
Justus