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

[Barry Leiba]

On Mon, Jun 26, 2017 at 1:42 PM, IETF Secretariat
<ietf-secretariat-***@ietf.org> 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

[Robert J. Hansen]

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

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.

[brian m. carlson]

On Sun, Jul 02, 2017 at 04:49:11PM -0400, Robert J. Hansen wrote:
> > 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.
>
> 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'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

[Heiko Stamer]

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.

[Robert J. Hansen]

> What's your opinion about defining additional (non-ECC) public-key
> 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.

[Salz, Rich]

> > What's your opinion about defining additional (non-ECC) public-key
> > 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*.

Strongly agree.

[Salz, Rich]

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

[Peter Gutmann]

Salz, Rich <***@akamai.com> 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.

[Kristian Fiskerstrand]

On 07/04/2017 06:01 AM, Peter Gutmann wrote:
> 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.

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

[Peter Gutmann]

Kristian Fiskerstrand <***@sumptuouscapital.com> 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.

[Werner Koch]

On Tue, 4 Jul 2017 11:06, ***@cs.auckland.ac.nz said:

> 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

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

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

[Peter Gutmann]

Werner Koch <***@gnupg.org> 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.

> And an OpenPGP profile.
> -- OpenPGP WG ?

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

Peter.

[Stephen Paul Weber]

‎> 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

[Robert J. Hansen]

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

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.

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

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.

[Robert J. Hansen]

> My interest ist simply that new keys will not use 3DES by default (but
> 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.

> I work in the Payment Industry. Next to 3DES usage in EMV Cards we use
> file encryption based on PCI, VISA, MC ... regulations. (PGP)

Ah, I understand: regulatory compliance. :)

[Werner Koch]

On Mon, 3 Jul 2017 21:51, ***@sixdemonbag.org said:

> 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

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.

[Kristian Fiskerstrand]

On 07/04/2017 10:33 AM, Werner Koch wrote:
> On Mon, 3 Jul 2017 21:51, ***@sixdemonbag.org said:
>
>> 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
>
> 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.

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

--
----------------------------
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
----------------------------
"History is a gallery of pictures in which there are few originals and
many copies."
(Alexis de Tocqueville)

[Werner Koch]

On Tue, 4 Jul 2017 11:06, ***@sumptuouscapital.com
said:

> 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

Right, that would even be easier.


Salam-Shalom,

Werner


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

[Peter Gutmann]

Robert J. Hansen <***@sixdemonbag.org> 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.

[Robert J. Hansen]

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

[Vincent Breitmoser]

Barry Leiba(***@computer.org)@Sun, Jul 02, 2017 at 01:55:18AM +0200:
> 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).

So...

- V