4 ms·

The politics here as I perceived them... Way back, there was a rambling and expansive process to update the OpenPGP standard. Years. So eventually it was decid

The politics here as I perceived them... Way back, there was a rambling and expansive process to update the OpenPGP standard. Years. So eventually it was decided to do a more focused "crypto refresh" that would be restricted to just important cryptography concerns. The GnuPG program was part of this. During the process the head of the GnuPG project (Werner Koch) spent a lot of time pushing back against what he considered pointless or wrongheaded changes. Eventually things seemed to stabilize and there seemed to be a consensus and people started paying less attention. Koch was one of those people. The process then wound up again and a bunch of stuff that Koch opposed ended up in the standards draft. Koch eventually noticed and ended up taking the position that the GnuPG project would not follow the new changes and would instead stay where they were. I think the very best outcome here would be if the various entities would accept that the process is working to the extent of clearly showing that consensus has not been reached and can't be reached from this point. The process will have to start yet again. The root cause here seems to be that there is no real serious issue with the existing standard, so attempts to update it lack a focus. As a result there is a tendency to try to change everything.

twiss 3y ago
The IETF aims for rough consensus [1][2], rather than full consensus. The OpenPGP Working Group chairs have deemed that GnuPG is "in the rough" of the rough consensus [3], and that there is sufficient consensus on the crypto refresh to publish it as an RFC. If GnuPG disagrees with that outcome, they can appeal it. That would be the normal "process" to follow, which - to my knowledge - hasn't happened yet. As for lacking focus, I'm obviously biased as one of the authors of the document, but the charter of the crypto refresh [4] was rather narrow, and aimed at modernizing the cryptographic primitives in OpenPGP. That's what the crypto refresh focused on; e.g. see [5]. [1]: https://www.rfc-editor.org/rfc/rfc8789.html https://www.rfc-editor.org/rfc/rfc8789.html [2]: https://www.rfc-editor.org/rfc/rfc7282.html https://www.rfc-editor.org/rfc/rfc7282.html [3]: https://mailarchive.ietf.org/arch/msg/openpgp/yz6EnZilyk_90j569KDPu4I3muY/ https://mailarchive.ietf.org/arch/msg/openpgp/yz6EnZilyk_90j... [4]: https://datatracker.ietf.org/doc/charter-ietf-openpgp/03/ https://datatracker.ietf.org/doc/charter-ietf-openpgp/03/ [5]: https://proton.me/blog/openpgp-crypto-refresh https://proton.me/blog/openpgp-crypto-refresh
- beeboobaa 3y ago
  Rough consensus doesn't have to include the people actually running the project? That sounds like a great way to publish standards that will be ignored by everyone...
  - twiss 3y ago
    Multiple OpenPGP implementations were involved in the crypto refresh, including Sequoia-PGP, OpenPGP.js, GopenPGP, and - at one point - RNP and even GnuPG itself, though those two stopped being involved at some point. GnuPG is now unhappy with some of the changes that were made after that point, which is their right. However, GnuPG is not the only implementation of OpenPGP, and not the only voice that matters. Various implementations have already implemented the crypto refresh (and personally I still hold out hope that eventually, GnuPG will do so as well, if this drama dies down and everyone can reconciliate).
    - beeboobaa 3y ago
      The thing is that I've never even heard of any of those. When people talk about PGP they mean GnuPG. All of those other projects their purpose of existence is to be compatible with GnuPG. If compatibility wasn't a concern you'd just use something new like Age.
      - twiss 3y ago
        Even if you don't know them, (and pardon my arrogance,) OpenPGP.js and GopenPGP probably have many more end users than GnuPG, due to them being used by Proton Mail (among other products). However, that shouldn't actually matter, because.. > All of those other projects their purpose of existence is to be compatible with GnuPG. That's not how the IETF process works. Technical arguments are more important than who has the most users. > If compatibility wasn't a concern you'd just use something new like Age. That being said, OpenPGP.js and GopenPGP do actually implement the old version of the draft (now dubbed "LibrePGP") as well (and everybody obviously still supports RFC4880), so there's no real risk of incompatibility. We just also implement the crypto refresh, and hope that GnuPG will do so as well, so that everyone can benefit from the improvements made there.
RcouF1uZ4gsC 3y ago
[flagged]
- upofadown 3y ago
  >...old, potentially vulnerable cyphers... Examples? Specifically, old potentially vulnerable ciphers that would actually allow the NSA to crack encrypted emails? IDEA and 3DES for example are perfectly secure for that usage. ... and just having something in the standard is not going to force anyone to use it. These days it is all AES and RSA or Curve25519.
  - nmadden 3y ago
    > IDEA and 3DES for example are perfectly secure for that usage. I wouldn’t use the phrase “perfectly secure”. They are both 64-bit block ciphers so vulnerable to generic collision attacks like https://sweet32.info/ https://sweet32.info/. This is why NIST deprecated 3DES and reduced the allowed limit of data encrypted with a single key to 2^20 blocks = 8MB. Many emails with attachments exceed that size. Now, you may say that such attacks are largely theoretical and the actual amount of (known plaintext) that needs to be captured is much larger in practice, but this is quite a step from “perfectly secure”, especially when you are considering the NSA as your adversary. Edit: spelling/typos
    - upofadown 3y ago
      >...reduced the allowed limit of data encrypted with a single key to 2^20 blocks = 8MB. Is that is from here? * https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-of-TDEA https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-De... I can't find any indication that this has transitioned from the proposal stage to an actual recommendation. But at any rate, this proposal is based on sweet32[1] which was a oracle attack which required 785 GB of traffic to demonstrate. Off the top of my head, recommendations for things like email (and file encryption), which are not vunerable to that sort of oracle attack, suggest a maximum for 64 bit block length ciphers of something like 4 GB. Email tends to be a maximum of 50 MB. That would be after base64 encoding. [1] https://sweet32.info/ https://sweet32.info/
Valodim 3y ago
This is actually pretty accurate. Worth noting is that the choice to move on with the rfc process was made very deliberately: there was a large thread on the mailing list to try and find a compromise. In this discussion, Werner Koch's negotiation standpoint basically required things to go 100% his way. The choices for the working group chairs ultimately boiled down to: 1. Closing down the wg with no result. 2. Moving on as a mostly functioning working group, at the cost of leaving Werner/GnuPG in the rough. 3. Reverting everything to the way Werner preferred. None of those were great options, obviously. Note that for option 3, the draft that is now LibrePGP and which was edited by Werner until circa 2020, had spectacularly failed to gather support and achieve consensus back then, and effectively stalled the working group for years. The LibrePGP project now claims that this draft was "the last consensus" of the working group, but at that time the reality was that Werner had gotten pretty used to just committing to master of the spec draft whatever he felt like, instead of seeking group consensus. At the moment there doesn't seem to be a chance for the parties to come to an agreement. I'm curious to see how this develops.
- jll29 3y ago
  People should agree that if there is no consensus reachable within the group of experts, an external advisor (e.g. Bruce Schneier, Ross Anderson) should be consulted. They may not be automatically "right", but such an agreement could re-stablish focus and avoid division or, worse, ending the worthwhile group's activities. Nothing is worse than open source people not reaching consensus and moving on, because nothing will make the enemy of privacy more happy.
throw0101b 3y ago
See also 'A Critique on “A Critique on the OpenPGP Updates”': * https://blog.pgpkeys.eu/critique-critique https://blog.pgpkeys.eu/critique-critique Which goes over the concerns/critiques that Koch posted at: * https://librepgp.org/ https://librepgp.org/

twiss 3y ago

The IETF aims for rough consensus [1][2], rather than full consensus. The OpenPGP Working Group chairs have deemed that GnuPG is "in the rough" of the rough consensus [3], and that there is sufficient consensus on the crypto refresh to publish it as an RFC. If GnuPG disagrees with that outcome, they can appeal it. That would be the normal "process" to follow, which - to my knowledge - hasn't happened yet. As for lacking focus, I'm obviously biased as one of the authors of the document, but the charter of the crypto refresh [4] was rather narrow, and aimed at modernizing the cryptographic primitives in OpenPGP. That's what the crypto refresh focused on; e.g. see [5]. [1]: https://www.rfc-editor.org/rfc/rfc8789.html https://www.rfc-editor.org/rfc/rfc8789.html [2]: https://www.rfc-editor.org/rfc/rfc7282.html https://www.rfc-editor.org/rfc/rfc7282.html [3]: https://mailarchive.ietf.org/arch/msg/openpgp/yz6EnZilyk_90j569KDPu4I3muY/ https://mailarchive.ietf.org/arch/msg/openpgp/yz6EnZilyk_90j... [4]: https://datatracker.ietf.org/doc/charter-ietf-openpgp/03/ https://datatracker.ietf.org/doc/charter-ietf-openpgp/03/ [5]: https://proton.me/blog/openpgp-crypto-refresh https://proton.me/blog/openpgp-crypto-refresh

beeboobaa 3y ago
Rough consensus doesn't have to include the people actually running the project? That sounds like a great way to publish standards that will be ignored by everyone...
- twiss 3y ago
  Multiple OpenPGP implementations were involved in the crypto refresh, including Sequoia-PGP, OpenPGP.js, GopenPGP, and - at one point - RNP and even GnuPG itself, though those two stopped being involved at some point. GnuPG is now unhappy with some of the changes that were made after that point, which is their right. However, GnuPG is not the only implementation of OpenPGP, and not the only voice that matters. Various implementations have already implemented the crypto refresh (and personally I still hold out hope that eventually, GnuPG will do so as well, if this drama dies down and everyone can reconciliate).
  - beeboobaa 3y ago
    The thing is that I've never even heard of any of those. When people talk about PGP they mean GnuPG. All of those other projects their purpose of existence is to be compatible with GnuPG. If compatibility wasn't a concern you'd just use something new like Age.
    - twiss 3y ago
      Even if you don't know them, (and pardon my arrogance,) OpenPGP.js and GopenPGP probably have many more end users than GnuPG, due to them being used by Proton Mail (among other products). However, that shouldn't actually matter, because.. > All of those other projects their purpose of existence is to be compatible with GnuPG. That's not how the IETF process works. Technical arguments are more important than who has the most users. > If compatibility wasn't a concern you'd just use something new like Age. That being said, OpenPGP.js and GopenPGP do actually implement the old version of the draft (now dubbed "LibrePGP") as well (and everybody obviously still supports RFC4880), so there's no real risk of incompatibility. We just also implement the crypto refresh, and hope that GnuPG will do so as well, so that everyone can benefit from the improvements made there.

RcouF1uZ4gsC 3y ago

[flagged]

upofadown 3y ago
>...old, potentially vulnerable cyphers... Examples? Specifically, old potentially vulnerable ciphers that would actually allow the NSA to crack encrypted emails? IDEA and 3DES for example are perfectly secure for that usage. ... and just having something in the standard is not going to force anyone to use it. These days it is all AES and RSA or Curve25519.
- nmadden 3y ago
  > IDEA and 3DES for example are perfectly secure for that usage. I wouldn’t use the phrase “perfectly secure”. They are both 64-bit block ciphers so vulnerable to generic collision attacks like https://sweet32.info/ https://sweet32.info/. This is why NIST deprecated 3DES and reduced the allowed limit of data encrypted with a single key to 2^20 blocks = 8MB. Many emails with attachments exceed that size. Now, you may say that such attacks are largely theoretical and the actual amount of (known plaintext) that needs to be captured is much larger in practice, but this is quite a step from “perfectly secure”, especially when you are considering the NSA as your adversary. Edit: spelling/typos
  - upofadown 3y ago
    >...reduced the allowed limit of data encrypted with a single key to 2^20 blocks = 8MB. Is that is from here? * https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-Deprecation-of-TDEA https://csrc.nist.gov/News/2017/Update-to-Current-Use-and-De... I can't find any indication that this has transitioned from the proposal stage to an actual recommendation. But at any rate, this proposal is based on sweet32[1] which was a oracle attack which required 785 GB of traffic to demonstrate. Off the top of my head, recommendations for things like email (and file encryption), which are not vunerable to that sort of oracle attack, suggest a maximum for 64 bit block length ciphers of something like 4 GB. Email tends to be a maximum of 50 MB. That would be after base64 encoding. [1] https://sweet32.info/ https://sweet32.info/

Valodim 3y ago

This is actually pretty accurate. Worth noting is that the choice to move on with the rfc process was made very deliberately: there was a large thread on the mailing list to try and find a compromise. In this discussion, Werner Koch's negotiation standpoint basically required things to go 100% his way. The choices for the working group chairs ultimately boiled down to: 1. Closing down the wg with no result. 2. Moving on as a mostly functioning working group, at the cost of leaving Werner/GnuPG in the rough. 3. Reverting everything to the way Werner preferred. None of those were great options, obviously. Note that for option 3, the draft that is now LibrePGP and which was edited by Werner until circa 2020, had spectacularly failed to gather support and achieve consensus back then, and effectively stalled the working group for years. The LibrePGP project now claims that this draft was "the last consensus" of the working group, but at that time the reality was that Werner had gotten pretty used to just committing to master of the spec draft whatever he felt like, instead of seeking group consensus. At the moment there doesn't seem to be a chance for the parties to come to an agreement. I'm curious to see how this develops.

jll29 3y ago
People should agree that if there is no consensus reachable within the group of experts, an external advisor (e.g. Bruce Schneier, Ross Anderson) should be consulted. They may not be automatically "right", but such an agreement could re-stablish focus and avoid division or, worse, ending the worthwhile group's activities. Nothing is worse than open source people not reaching consensus and moving on, because nothing will make the enemy of privacy more happy.

throw0101b 3y ago

See also 'A Critique on “A Critique on the OpenPGP Updates”': * https://blog.pgpkeys.eu/critique-critique https://blog.pgpkeys.eu/critique-critique Which goes over the concerns/critiques that Koch posted at: * https://librepgp.org/ https://librepgp.org/