Re: [openpgp] Meeting Minutes for OpenPGP at IETF 114

Hello,

Two minor clarifications of my quotes:

> Huigens: Compression will compress the non random padding anyways, fine with leaving with random.

what I said in the meeting is something like:

"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."

Justus wrote in the chat that he would be fine with removing the justification also, so it might be worth having that point clarified in the notes. I'll also make a MR proposing that change (probably next week, I'm officially on vacation this week).

And:

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

->

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

Best,
Daniel

------- Original Message -------
On Monday, August 1st, 2022 at 11:52, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:

> Hi folks--
> 
> Thanks for a lively and useful discussion of the remaining outstanding
> issues. Thanks to Tero for the complicated task of taking notes in a
> fairly fast-moving session with a lot of technical nuance and rapid
> polls. I've done a review and a bit of minor cleanup on Tero's
> excellent note-taking, and submitted the meeting minutes to the
> datatracker, copied below.
> 
> If you see any flaws or omissions, please report them by replying to
> this message (either to me privately, or on-list), and i'll publish a
> revision of the minutes.
> 
> Looking forward to more discussion here -- let's get this crypto-refresh
> draft out the door!
> 
> --dkg
> 
> 
> ---------
> 
> # 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: Compression will compress the non random padding anyways, fine with leaving with random.
> 
> 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 implemnetations can be tested by independant 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 downgrad 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: Certifice-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 favor of removing this. There is not that much implementation support for this feature. Test matrix does not have support it, it was too complicated to implement it.
> 
> 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 v6 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.
> 
> #### 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 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 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
> _______________________________________________
> openpgp mailing list
> openpgp@ietf.org
> https://www.ietf.org/mailman/listinfo/openpgp