Subject: Re: [openpgp] Expiration impending: <draft-ietf-openpgp-rfc4880bis-01.txt>

From: Barry Leiba <[email-masked]>
Date: Sun, 2 Jul 2017 01:55:18 +0200

On Mon, Jun 26, 2017 at 1:42 PM, IETF Secretariat
<[email-masked]> wrote:
> The following draft will expire soon:
>
> Name:     draft-ietf-openpgp-rfc4880bis
> Title:    OpenPGP Message Format
> State:    I-D Exists
> Expires:  2017-07-06 (in 1 week, 2 days)

This working group has an impressive record of inaction, evidenced by
both the impending expiration of the group's only document and the
version number's being only -01.  There's been no work done here since I
came into the chair position a little over a year ago.

The chairs have tried to push things along in the background, but it
hasn't worked.  It seems clear to me that we need to accept that
there's not enough interest in getting this done, and close the
working group.

I've CCed EKR on this by way of asking him to take action unless
there's some immediate discussion that convinces us that what I say
above is wrong, that there is interest, and that there will be
progress very soon (in which case we would set an aggressive and
firm schedule).

--
Barry, as chair

---

From: "Robert J. Hansen" <[email-masked]>
Date: Sun, 2 Jul 2017 16:49:11 -0400

> came into the chair position a little over a year ago.

I was also disheartened to see that SHA-1 is still baked into this draft
in a few places.

I personally don't feel that designing the next generation of RFC is
within my technical skillset -- I can make informed criticism, but
that's a little different from saying "trust me, I know what I'm doing."
 But I've been waiting patiently to see drafts, and for years I've been
telling people asking about SHA-1 deprecation "wait and let the Working
Group do its job."

I am absolutely sure there is interest in an RFC which gets rid of all
SHA-1 dependencies; however, the people who are interested are not
necessarily the ones who can draft a dependency-free RFC.

I feel let down.  I'm fairly sure there are others who feel similarly.

---

From: "brian m. carlson" <[email-masked]>
Date: Sun, 2 Jul 2017 23:25:42 +0000

> necessarily the ones who can draft a dependency-free RFC.

I'm happy to try to contribute more in an effort to get the WG where it
needs to be.  However, I think the WG as a whole needs to provide more
input and response to ideas and drafts, including useful text that can
be incorporated by the editors, so that we can move forward at a
reasonable rate.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 3 Jul 2017 04:45:04 +0000

Robert J. Hansen <[email-masked]> writes:

>I was also disheartened to see that SHA-1 is still baked into this draft in a
>few places.

That's not necessarily a problem, it's perfectly OK PRFs, MACs, and similar
situations, you just want to move away from it for signatures.

Peter.

---

From: "Robert J. Hansen" <[email-masked]>
Date: Mon, 3 Jul 2017 00:48:07 -0400

> That's not necessarily a problem, it's perfectly OK PRFs, MACs, and
> similar situations, you just want to move away from it for
> signatures.

Yes, but removing it cuts down on the amount of (wholly inappropriate)
fearmongering that gets thrown around by the ignorant whenever SHA-1 is
mentioned.  OpenPGP adoption is slow enough already; continued use of
SHA-1, even where it's safe, seems contraindicated.

---

From: Heiko Stamer <[email-masked]>
Date: Mon, 3 Jul 2017 21:26:24 +0200

Hey,

first of all, I am new to this mailing list. So please forgive me,
if I comment on things that have been already discussed before.

brian m. carlson wrote:

> However, I think the WG as a whole needs to provide more input

What's your opinion about defining additional (non-ECC) public-key
algorithms, e.g., Cramer-Shoup or an IND-CPA secure variant of ElGamal?

Best regards,
Heiko Stamer.

---

From: "Robert J. Hansen" <[email-masked]>
Date: Mon, 3 Jul 2017 15:29:23 -0400

> algorithms, e.g., Cramer-Shoup or an IND-CPA secure variant of ElGamal?

I would be opposed to this.  This is not the time to start adding neat
stuff to the RFC.  Now is the time to make the critical and necessary
changes to the RFC and *get it published*.

Once we have an RFC with the urgent changes published, then we can
circle back and have conversations about every neat thing under the sun.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 3 Jul 2017 19:35:38 +0000

> I would be opposed to this.  This is not the time to start adding neat stuff to
> the RFC.  Now is the time to make the critical and necessary changes to the
> RFC and *get it published*.

Strongly agree.

---

From: [email-masked]
Date: Mon, 3 Jul 2017 21:41:36 +0200

Dear List,

May I kindly ask if part of the critcal an necessary changes is
sunsetting 3DES, SHA1.
Yes I know they are still good but I think in current operation speed of
standards it is definitly time to start it.

I expierence in private an buisness live extra efforts to ensure pgp
communication is not using 3DES for example which
costs percious time in our projects.

best regards

Dirk

On 03.07.2017 21:35, Salz, Rich wrote:
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 3 Jul 2017 19:47:11 +0000

> May I kindly ask if part of the critcal an necessary changes is sunsetting 3DES,
> SHA1.

Yes.  See https://datatracker.ietf.org/wg/openpgp/about/ for a list of what this WG was supposed to be working on.

The WG has been stalled for a very long time and it's not clear this "last minute" flurry of interest would fundamentally change that.

---

From: "Robert J. Hansen" <[email-masked]>
Date: Mon, 3 Jul 2017 15:51:05 -0400

> May I kindly ask if part of the critcal an necessary changes is

The latest draft minimizes (but does not eliminate) SHA-1.  3DES is
still a MUST-implement algorithm, and will likely be so for the ongoing
future.  3DES has been a MUST algorithm since RFC2440, way back when;
there's a lot of data encrypted with it and the RFC will continue to
require 3DES be supported in order to help interoperate with old traffic.

> costs percious time in our projects.

Why?  What problem is presented by using 3DES for your work, which is so
severe that you have to ensure 3DES isn't used?

Seriously: it's still believed to be a strong cipher, there are no
practical attacks on it, and no new attacks are looming on the horizon.
3DES is slow and it only has a 64-bit block size, but for the vast
majority of OpenPGP usage that's not a problem.

---

From: [email-masked]
Date: Mon, 3 Jul 2017 22:34:42 +0200

> require 3DES be supported in order to help interoperate with old traffic.

Not being a  crypto devoloper I fully agree to keep the 3DES key for
backward compatbility.
My interest ist simply that new keys will not use 3DES by default (but
if user wishes it could be added).

> severe that you have to ensure 3DES isn't used?
I work in the Payment Industry. Next to 3DES usage in EMV Cards we use
file encryption based on PCI, VISA, MC ... regulations. (PGP)
I experienced several projects where we had to again and again request
clients(not necessarily crypto professionals) to regenerate keys because
3DES was still enabled.
I asked our key manager why exactly this is a problem. He pointed me to
some regulations where a concrete do not use 3DES for file crypto is not
written.

But he also mentioned that in the professional community within PCI it
is more or less clear to base on also rock solid more modern an more
long living ciphers like AES Family and remove 3DES for every new key.
As well it is expected that one or more regulators would disapprove 3DES
in near future.
I give you that is hear/say but It seems to me time to say slowly good
bye to old technology and base on new also proofen algorithms. Therefore
3DES for backward compatibility and opt in if wanted.
But not any more as a default.
> majority of OpenPGP usage that's not a problem.
I'm also very fund of my old Diesel VW. Great car - never had a problem
(touch on wood). But if I look at the news here where I live it is clear
my next cars will be another motor technology.
Saying if something suitable new is here and you can choose - then
choose new and proofen over old and proofen.

best regards

Dirk

---

From: "Robert J. Hansen" <[email-masked]>
Date: Mon, 3 Jul 2017 16:40:09 -0400

> if user wishes it could be added).

This will likely be left up to implementors.  It's worth noting that
most of the major OpenPGP implementations already shifted to AES for new
keys ages ago.

> file encryption based on PCI, VISA, MC ... regulations. (PGP)

Ah, I understand: regulatory compliance.  :)

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 4 Jul 2017 04:01:45 +0000

Salz, Rich <[email-masked]> writes:

>The WG has been stalled for a very long time and it's not clear this "last
>minute" flurry of interest would fundamentally change that.

A complaint I heard many years ago about PGP 2 was that it wasn't obviously
flawed.  What I'd say is that it was too good enough.  There were problems,
but none of them were sufficiently fatal (at the time) to motivate any kind of
expedited move to a new version.  OpenPGP is still too good enough, there's
lots of things there that you can nitpick but nothing really fatal, or even
close to fatal.  For example the MDC is a rather a kludge compared to an HMAC,
but it's good enough.  The weird CFB mode is kind of a mess, but it's good
enough. The whole thing is just too good enough.

If you wanted to update OpenPGP now, you'd be breaking compatibility with vast
amounts of data stored in the current format, and lots of deployed PGP
implementations that aren't GPG and that can't readily be updated.  In
addition, since what we've got now is too good enough, there are no obvious
bits that need to be replaced, just a huge pile of everyone's favourite trendy
things to add that no two people can agree over.

Or you could throw everything out and start again, get rid of the hand-
Huffman-code of lengths, replace the kludgy KDF with Argon2, replace the MDC
with HMAC, and so on, and suddenly you've got a totally new protocol.  Sort of
what the HTTP WG did with HTTP 2.0, or the TLS WG did with TLS "1.3".  The
HTTP WG essentially forked HTTP, it's too early to tell what the TLS WG will
achieve but it's probably the same thing.

So, I'd say leave it as it is.  It's already too good enough, and having two
incompatible versions floating around will do the exact opposite of helping
with PGP adoption.

Peter.

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Tue, 4 Jul 2017 09:29:10 +0200

On 07/04/2017 06:01 AM, Peter Gutmann wrote:
> OpenPGP is still too good enough, there's
> close to fatal. 

This sentiment seems similar to my own considerations with regards for
need to change. If we are to change, lets do it right, not just some
small nitpick, in particular with regards to removing some complexity
since it is breaking backwards compatibility anyways (I'd propose e.g
getting rid of trust signatures for V5). The most common complaint I'm
hearing about OpenPGP is that it is too complex, as such I'm beginning
to change my mind as to whether protocol agility is only a good thing,
maybe we should work more on getting to consensus and reduce
implementation complexity in order to make it possible for better
auditing of implementations etc.

-- 
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Nil satis nisi optimum
Nothing but the best is good enough

---

From: Werner Koch <[email-masked]>
Date: Tue, 04 Jul 2017 10:33:03 +0200

> still a MUST-implement algorithm, and will likely be so for the ongoing

The problem with TripleDES is that it is the only implicit symmetric
algorithm preference.  This makes it hard to remove.  However there is a
way to do that: We should define a new key flag requesting the use of
the to-be-specified new Symmetrically Encrypted Data Packet.  That new
data packet will require the use of a 128 bit block length algorithm and
can also require that AESnnn is the new implicit symmetric algorithm
preference.

Salam-Shalom,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 4 Jul 2017 09:06:09 +0000

Kristian Fiskerstrand <[email-masked]> writes:

>The most common complaint I'm hearing about OpenPGP is that it is too
>complex, as such I'm beginning to change my mind as to whether protocol
>agility is only a good thing, maybe we should work more on getting to
>consensus and reduce implementation complexity in order to make it possible
>for better auditing of implementations etc.

The easiest way to do that would be through a profile of 4880.  So instead of
opening up giant can of worms and trying to redo 4880 itself, where everyone
will want their own favourite change applied, publish a profile of 4880 with a
standard feature set for file encryption, email encryption, signed data, and
maybe one or two other things.  

For example for file encryption you might have MUST AES, MUST MDC, MUST
Iterated and Salted S2K (why do the other options even exist?), MUST either
five-octet or partial lengths... I think that's about it.  Then you can do PGP
file encryption in a pretty minimal amount of code rather than having to
include an entire protocol suite to deal with every obscure option in the
spec.

The profile option, rather than rewrite-the-RFC, is fully compatible with
existing implementations while allowing us to move forward on best-practice
mechanisms and ciphers and, above all, simplify implementation and testing.

Peter.

---

From: Kristian Fiskerstrand <[email-masked]>
Date: Tue, 4 Jul 2017 11:06:25 +0200

> can also require that AESnnn is the new implicit symmetric algorithm

Given that we're introducing a new keyblock version anyways, can't this
just be the default for v5 keys, which anyways requires updating on
implementations to support? iirc something similar is done in RFC6637
for ECC keys already

"History is a gallery of pictures in which there are few originals and
many copies."
(Alexis de Tocqueville)

---

From: Werner Koch <[email-masked]>
Date: Tue, 04 Jul 2017 11:25:02 +0200

> just be the default for v5 keys, which anyways requires updating on

Right, that would even be easier.

Salam-Shalom,

   Werner

---

From: Werner Koch <[email-masked]>
Date: Tue, 04 Jul 2017 11:36:23 +0200

> Iterated and Salted S2K (why do the other options even exist?), MUST either

Well we should actually have a dummy S2K for the case that you take a
full entropy passphrase from a database.  Lacking that the Simple S2K is
the next best choice.

> The profile option, rather than rewrite-the-RFC, is fully compatible with

In fact there is already a profile for Suite B in the draft (from
RFC6637).  The German spooks want their Brainpool instead.  Me and many
others would prefer Chicago curves.  Thus, do we need to chnage your
well-know quote to

                    You can't be a real country unless you have a beer and an
                    airline.  It helps if you have some kind of a football
                    team, or some nuclear weapons, but at the very least you
                    need a beer.
                        -- Frank Zappa
                    And an OpenPGP profile.
                        -- OpenPGP WG ?

;-)

Shalom-Salam,

   Werner

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 4 Jul 2017 10:14:56 +0000

Werner Koch <[email-masked]> writes:

>In fact there is already a profile for Suite B in the draft (from RFC6637).
>The German spooks want their Brainpool instead.  Me and many others would
>prefer Chicago curves.

The idea isn't necessarily to come up with new or alternative algorithms but
to codify current practice, where it makes sense.  So if 99% of the
implementations out there do, say, AES + x + y, then make the profile "AES + x
+ y", so that implementing just that one option is all that's required to give
you 99% coverage.

>                        -- OpenPGP WG ?

Ugh, the X.509 folks already did that badly enough :-).

Peter.

---

From: Stephen Paul Weber <[email-masked]>
Date: Tue, 04 Jul 2017 08:02:02 -0500

‎> The easiest way to do that would be through a profile of 4880. 

I started work on such a thing once:
https://github.com/singpolyma/openpgp-spec

---

From: Vincent Breitmoser <[email-masked]>
Date: Wed, 12 Jul 2017 14:59:43 +0200

> progress very soon (in which case we would set an aggressive and

So...

 - V