IETF-114 OpenPGP WG Minutes

Logistics

• When: Friday July 29 1400-1600 UTC (1000-1200 meeting local time)
• WG page: https://datatracker.ietf.org/wg/openpgp/documents/
• Notetaker: Tero Kivinen

Agenda

• Administrivia & Agenda bash (chairs, 5)

• Chartered work:

  • WGLC issues (however long it takes)
  • Next steps (chairs, 5)

• Other presentations (time may shift if above takes longer or less
  time):

  • Daniel Huigens, Symmetric re-encryption (10)
  • Aron Wussler, Automatic Forwarding (10)

Administrivia

No trivia or bashing

WGLC issues of RFC4880bis

Issue #132: Padding octets (zero/random/other)

PHB: if you put zeros, you have known plain text, if you use random
then you have covert channel. Rigid structure that is generated from key
does not give known plaintext or covert channel.

Paul: It requires too much resources to do the HKDF

PHB: you only need to change the data slightly to get rid of the
known plain text.

Farrell: Is the receiver expected to check the padding

Gillmor: What is receiver expected to do if the padding does not
match.

Aron: There is many ways of adding covert channel data, so adding
random data does not make covert channels that much easier.

Gillmor: Random is currently recommend, do we leave it to that.

Huigens: My only issue with the status-quo is the justification (for
protecting against compression), as compression of the non-padding data
will reveal information about the length anyway. Other than that I'm
fine with leaving the padding as random data.

(on chat, Justus Winter noted that he would also be fine with
removing that justification)

Poll keep the random padding scheme: 8 yes, 1 no, confirm in the
list, that we want to keep the current text. Huigens wants to remove the
justification.

Issue #134: AEAD Decryption failures

Poll Should change the SHOULD to MUST for AEAD decryption failures
as described in merge request 206: 15 yes, 0 no.

Issue #135: GCM

PHB: OCB is much stronger, someone can add it to IANA registry, I am
going to implement what is in the draft, thus if GCM is not in the
draft, then most likely people are not going to implement.

Gillmor: OCB is MUST others are not mandatory to implement. There is
negotiation mechanism, so you do not use GCM with anybody who does not
support it.

Quynh Dang: I am fine that GCM is not mandatory to implement, but if
there is people who want to use it then would like to have option to do
that, and not be non-complient because of that. GCM is not one of the
best of chiphers, but is still good in some cases. It should be ok as an
option.

Gillmor: What are the reasons to use it?

Quynh Dang: Have implementation already, and have checked the
security properties and are fine with them, and want to use it, as it is
the same cipher they use in other places. Does not need to be mandatory,
but would like to keep it as option.

Wouters: I do not think whether it matters where it is specified,
the people who want to use it are those who want to be FIPS complient
and do not have any other choises, and are going to do it anyways. Lets
do it in the group, so we get it done properly.

Jonthan Hammell: In favor of including GCM. It provides a benefit
that implementations can be tested by independent labs.

Daniel Huigens: Want to keep as it is what is currently implemented.
For performance reasons (native to WebCrypto). We can do it in private
number, but we are going to implement it anyways.

Orie Steele: Agree with Daniel, it would be good to have one FIPS
algorithm included.

Ben Kaduk: Agree in Paul. It is going to happen, so lets do it here.
There are cases where people are required to use GCM.

Poll: Keep GCM as an option: 15 yes, 0 no.

Issue #136: Binding Keys to Modes

Daniel Huigens: There was paper where GCM ciphertext could be
converted to CFB, and if you have decryption oracle for CFB, then
security of the GCM gets reduced to CFB. In general I think not being
able to convert keys between modes is good. As we are keeping GCM, I
think we should keep this too.

Justus Winter: This is not only about GCM, it is generic downgrade
attacks. I want to keep this. Because of the salt that is used in
SEIPDv2, it's now possible to offer a robust way to reply (and "reply
all") to encrypted messages even when the replying party does not know
the OpenPGP certificates of all the recipients.

Poll: Keep HKDF for binding modes as per draft -06: 17 yes, 0 no.

Issue #137: Direct Key Sigs

Ben Kaduk: Asking question: In v4 we could have per self signed
signature they could have different preferences for different user id,
if in v5 all of them are global there is no way of doing that.

Gillmor: Old RFC explictly mentions that you use the certificate
wide parameters from the user id you are using, but I do not know
anybody doing that, or using keys that have different preferences. We do
not have anybody mentioning this in the list that they use this feature.

Farrell: The reason people were against this as they were concerned
that this would allow user id less keys.

Gillmor: We can still require user id even if we do this, might
incur one extra signature per OpenPGP certificate if we do.

Orie Steele: What about future, we might get rid of support for v4,
and then things would be easier as we do not need to keep support for
this.

Daniel Huigens: There are some uses cases user id less keys, and
this allows that. You do not want to publish the user id in some
context, or you have catch all key, you do not know which user ids
beforehand. So having user id less keys would be usefull at some point,
and this allows it.

Justus Winter: I like user id less use cases, to ben's question they
usually have separate keys, and having preferences changing by user id
might get unexpected results.

Poll: Certificate-wide parameters live in Direct Key Sigs for v5,
keep that: 8 yes, 0 no.

Issue #138: Revocation key subpacket is disallowed for v5 keys.

Ben Kaduk: The escrow system might be bit more risky than revocation
key subpacket method, i.e., the escrowed key revocation signature might
get leaked too early.

Justus Winter: I am in favor of removing this. There is not that
much implementation support for this feature, likely because it was too
complicated to implement it. Interop tests do not test this feature.

Daniel Huigens: We do not support it. I think removing is
reasonable, and use the already exisiting method of using revocation
certificates, which works for v4 also.

Ben Kaduk: If we cannot rely on it working, we should remove it.

Poll: Revocation key subpacket is disallowed for v5 keys, keep that:
10 yes, 0 no.

Issue #140: IANA

Kivinen: You need to give instructions or guidance to the expert
what kind of specification is enough. Most likely just some web page
somewhere is not enough, 3gpp specification is enough.

Ben Kaduk: I do have example of where we have given export
instructions and guidance to do the allocations. Support of opening this
up. There is cases where experts are not allowed much freedom to do
allocations, for example in the quic the have to give numbers unless
someone is asking lots of numbers.

Orie Steele: I am expert on registry that was opened up this way.
Make sure you give good guidance to the experts, as they do not need to
end up in the middle of political mess. Have designated expert, and give
them good guidelines, and support them when they work based on these
guidelines.

Benjamin Kaduk via chat: On guidance to IANA designated experts, I
like
https://datatracker.ietf.org/doc/html/draft-ietf-cose-rfc8152bis-algs-12#section-10.4
, quoting in part:

part, defined as expert review. This section gives some general
guidelines for what the experts should be looking for, but they are
being designated as experts for a reason, so they should be given
substantial latitude.

Expert reviewers should take into consideration the following points:
* Point squatting should be discouraged. [...]

Poll: I'm happy with the changes to IANA registration rules (but we
should give guidance to the DE): 11 yes, 0 no.

Issue #142: Argon2

Justus Winter: There is no test for Argon2 yet, but we do have two
interoperable implementations.

Niibe Yutaka: There is support in my branch of GnuPG (with libgcrypt
1.10 which has Argon2).

Farrell: We have heard there is multiple implementations and they
interoperate, so the text can't be that bad.

Wouters: Was there a case where someone did not want to have Argon2
at all.

Farrell: There was some discussion about that, but that seemed to be
only one person or so.

Unclear how to structure a poll for this; discussion to revert to list.

Issue #143: Problematic keys

Justus Winter: There is hash digest, what should prefix is wrong,
what should implementations do? The github key has different issue, they
have invalid mp integers.

Daniel Huigens: If you have crypto api which allows you to hash and
sign it would be nice to be able use it. Some implementations are not
checking it, we check it and reject the signature if it has invalid
metadata. There are keys out there which are wrong. Either remove it
completely, or check it.

Orie Steele: I agree with Daniel. if it is there it should be
checked, if not we should remove. They should generate new keys.

Gillmor: We can only remove it for v5.

Justus Winter: This might have been optimization, we might also have
some keys that were mangeled by key server. I would prefer to keep it,
but I would be ok to make the check mandatory.

Poll: should we remove the signature checksum from v5 sigs? 5 yes, 2
no.

Aron Wussler: It provides debugging information, even when we do not
check it.

Gillmor: Three things it can do:
allows rejecting sigantures first
allows debugging information
allows reordering certificates

Poll: Should we state that implementations MUST reject signatures
(v4 or v5) with incorrect signature checksums? 9 yes, 1 no.

Aron Wussler: Would be in favor of SHOULD, but having MUST is too
strong when you know there is implementations which do not do it.

Gillmor: Another issue is the malformed MPIs, like the one in
github.

Orie Steele: I do not know about the internal things, but unless
there is a way of giving annoying warning, we should reject the
certificates.

Gillmor: That would mean rejecting signatures github generates.

Ben Kaduk: For these problematic signatures you can modify the
signatures and fix them yourself.

Gillmor: Should we fix it.

Ben Kaduk: Probably, better just fix than reject it. rejecting it
just to breaking it sounds bad.

Daniel Huigens: We could reject on v5, but not for v4. Old versions
of openpgp.js had similar issues.

Justus Winter: My concern is that if we have system that they use it
differently, then some might reject it and some others dont, that could
cause problems.

Kivinen: I think fixing the code to generate signatures is faster
than getting implementations to start checking that.

Gillmor: there is also old signatures.

Kivinen: But if nothing starts breaking they will never fix their
code. Perhaps the correct solution is to do this check on v5, but keep
v4 as it is.

Orie Steele: Similar issues with where there was two different in
bitcoin and it is mess in the code. In v5 it should be rejected, for v4
it should be as.

Justus Winter: Not sure if there is a way of giving warnings, and
what to do with that.

Gillmor: If we have signatures of signatures, and fixing the mpints
do break those. Changing mpints in public keys will change fingerprints.

Farrel: Can anybody make merge request.

Daniel Huigens: I can make merge request

Next steps

Farrel: Only do WGLC on the changes.

Wouters: Can we do it, what happens if someone comments on other
parts.

Ben Kaduk: We have done it before, we can say we did WCLC earlier
and agreed on other parts, focus on the review on the changes now.

Symmetric re-encryption

Daniel Huigens

Automatic Forwarding

Aron Wussler

AOB

EOF