Subject: [openpgp] First 4880bis drafts

From: Werner Koch <[email-masked]>
Date: Wed, 04 Nov 2015 12:45:25 +0100

Hi

from your freshly appointed RFC-4880bis editor.  I talked to dkg on how
to get started and we agreed on taking my existing RFC-4880 version
which I converted to Pandoc/Markdown format some time ago.  Meanwhile I
published two I-D based on this:

  https://tools.ietf.org/id/draft-koch-openpgp-rfc4880bis-00.txt

This is RFC-4880 with errata 2270, 2271, 2242, 3298 applied and some
editorial notes:

   { This is work in progress to update OpenPGP.  Editorial notes are
   enclosed in curly braces.  The section numbers from RFC4880 are also
   indicated in curly braces. }

The second I-D is:

  https://tools.ietf.org/id/draft-koch-openpgp-rfc4880bis-01.txt

With these additional changes (cf. Appendix A):

   o  Added Camellia cipher from RFC 5581.

   o  Incorporated RFC 6637 (ECC for OpenPGP)

   I also fixed up a couple of formatting issues in case you wonder
   about the longer diff betwee -00 and -01.  I temporary moved the
   authors of RFC-4880 to an appendix to not annoy them with
   confirmation mails.  I don't know how this is usually handled; thus
   please drop me a note if I shall move you to the authors section now
   and not only in later I-Ds.

The diff between RFC-4880 and -00 can be viewed here:

  https://tools.ietf.org/rfcdiff?url2=draft-koch-openpgp-rfc4880bis-00.txt

and the diff between -00 and -01 here:

  https://tools.ietf.org/rfcdiff?url2=draft-koch-openpgp-rfc4880bis-01.txt

Please check them so we can get a stable base for our future work.

Shalom-Salam,

   Werner

p.s.
To get the source you may run

  git clone git://git.gnupg.org/people/wk/rfc4880bis.git

or follow at 

  http://git.gnupg.org/cgi-bin/gitweb.cgi?p=people/wk/rfc4880bis.git

In case anyone sees a problem hosting that under a gnupg address, dkg
will probably be able to publish his repo.  In any case the plan is to
mail diffs.  The above should be considered a clone of my working copy.

To build a new draft you would run

  pandoc2rfc abstract.mkd middle.mkd back.mkd

pandoc2rfc is availabe via https://tools.ietf.org

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

---

From: Aaron Zauner <[email-masked]>
Date: Wed, 4 Nov 2015 18:34:33 +0100

>    o  Added Camellia cipher from RFC 5581.

Hrm. I'm against this. CAMELLIA is going to be deprecated in e.g.
TLS because barely anyone uses it. I'm explicitly excluding anything
other than AES128 or 256 from my GnuPG config currently, I haven't
noticed any breakage in almost a year:
https://github.com/azet/dotfiles/blob/master/.gnupg/gpg.conf

If we're all going to choose our favorite cipher, without real
arguments as to new security features or performance, we're going to
end up like this:
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

The ECC addition makes sense, but I'd also limit the number of
possible curves to a few vetted ones instead of verbatim including
all those NIST curves. For example: do we want to keep P256? Or are
we going with a higher 'security level' alltogether? I consider this
cruft that should be removed. Why not just use Curve25519 and
Goldilocks?

(Again; sorry if that has already been discussed, I've been very
busy the last couple of months and didn't follow every e-mail
thread, though I tired to look these topics up by searching them)

Aaron

---

From: Werner Koch <[email-masked]>
Date: Wed, 04 Nov 2015 20:14:08 +0100

> Hrm. I'm against this. CAMELLIA is going to be deprecated in e.g.

You may be against it but it is a matter of fact that CAMELLIA is an
officially assigned OpenPGP cipher algorithm for 6 years.

We may latter decide to deprecate certain algorithms but that is not a
question right now.

Salam-Shalom,

   Werner

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 05 Nov 2015 08:53:33 +0900

> officially assigned OpenPGP cipher algorithm for 6 years.

As discussed in the meeting tuesday, deprecation is a tricky subject for
formats with stored data (as distinguished from on-the-wire network
traffic).  people have archives of encrypted data that may still use
this cipher.

> We may latter decide to deprecate certain algorithms but that is not a

The sense of the room in Yokohama was to deprecate as much as possible,
and encourage a limited, sensible set of algorithms for message creation
and signing.  But sensible implementations will likely continue to allow
decryption of these ciphers for years to come.

regards,

           --dkg

---

From: "brian m. carlson" <[email-masked]>
Date: Thu, 5 Nov 2015 01:30:51 +0000

> https://github.com/azet/dotfiles/blob/master/.gnupg/gpg.conf

As Werner pointed out, Camellia has been around for some time.  It's
also good to have enough diversity that if someone comes out with a
major attack against AES, we're not totally sunk.  Camellia is a Feistel
cipher, while AES is a substitution-permutation network, which means
that attacks are unlikely to work against both.

Currently, if AES were to be broken, TLS implementations would not
interoperate at a 128-bit or higher security level.  OpenPGP would
continue to function without much thought, which is a major asset.

I'm for deprecating algorithms which provide less than a 128-bit
security level, such as SHA-1 and 3DES.

> cruft that should be removed. Why not just use Curve25519 and

I believe Google's End-to-End is using the NIST curves, and there are
already keys using these curves.  I think Curve25519 and Goldilocks
would be valuable due to their rigidity and the CFRG endorsement.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 05 Nov 2015 19:14:52 +0100

Hi,

Apparently my message came of the wrong way (and I'm to blame for that,
because of my wording):

> traffic).  people have archives of encrypted data that may still use

Totally agree there. And PGP implementations will support these ciphers
for years because of stored data that might have been encrypted with one
of these ciphers.

> decryption of these ciphers for years to come.

Yes. But we should discourage further use. I'm not sure if the right
place is the updated RFC or another document entirely. My concern is
that we'll end up with a unmanageable 'cipher-zoo'. I'm happy to help
with such a document and am _not_ trying to get in the way of updating
the current OpenPGP spec.

Hope that clears things up a bit,
Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 05 Nov 2015 19:19:07 +0100

> that attacks are unlikely to work against both.

Ok - so what's the threat model here? Are we really expecting AES to be
broken anytime soon? Really? And we're suggesting to keep ciphers around
that have seen far less cryptanalysis?

...

> would be valuable due to their rigidity and the CFRG endorsement.

Wasn't aware that end2end already has a userbase (after all, for a very
long time the GitHub repo stated 'experimental code - do not use').
Likewise Curve25519 is available in GnuPG expert mode (it says use is
discouraged though - and keyservers won't accept it).

Aaron

---

From: "Robert J. Hansen" <[email-masked]>
Date: Thu, 5 Nov 2015 14:30:19 -0500

> broken anytime soon? Really?

As a police officer friend of mine is fond of saying, nobody wakes up in
the morning and says "today I think I'll need my body armor."

I doubt that anyone working on the RFC really expects AES to be broken
any time soon.  The inclusion of Camellia as a hedge against unpleasant
surprises, though, seems wise.

---

From: Ian G <[email-masked]>
Date: Thu, 5 Nov 2015 19:30:52 +0000

On 05/11/2015 01:30, brian m. carlson wrote:
>> Hrm. I'm against this.

++1++

>> CAMELLIA is going to be deprecated in e.g.
> As Werner pointed out, Camellia has been around for some time.

Whatever - let implementations provide Camellia if they want to; they 
will to handle archives and so forth.

The *standard* should do better, work for the benefit of all.

The standard should have an aggressive role in deprecation.

> It's
> major attack against AES, we're not totally sunk.

This is hypothetical.  It's never happened in our time.  Our 
cryptographers are better than that, let's rely on them.

> Camellia is a Feistel

Sorry - can we worry about realistic user problems not hypothetical 
academic issues?

> continue to function without much thought, which is a major asset.

? AES isn't going to be broken.  Software is going to be buggy - let's 
reduce complexity. Protocols might be flawed, let's make it simpler.  
But AES broken?  No.  Get realistic.

> security level, such as SHA-1 and 3DES.

It is the case that we face a threat around the 80 bit mark.  Sure.

So, I'd suspect we're going to set a mark for future OpenPGP at the 256 
bit level.  This would have been a no-brainer until recent NSA Suite B 
news.  Does anyone have a feeling for where we'd like to draw the line now?

iang

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 05 Nov 2015 22:32:07 +0100

> the morning and says "today I think I'll need my body armor."

He still packs a firearm, pepper-spray and baton, I guess? :)

> surprises, though, seems wise.

I'm not saying that having alternatives to AES is a bad idea, I'm just
saying that CAMELLIA may not be the best choice there. It has not seen a
lot of cryptanalysis over the last couple of years (primarily because
there's almost no interest in it).

Aaron

---

From: Aaron Zauner <[email-masked]>
Date: Thu, 05 Nov 2015 22:33:10 +0100

> there's almost no interest in it).

Also - having /too many/ alternatives is certainly a bad idea.

Aaron