Subject: [openpgp] DRAFT minutes for OpenPGP at IETF 94

From: "Salz, Rich" <[email-masked]>
Date: Tue, 3 Nov 2015 09:41:31 +0000

WG:                     Open Specification for Pretty Good Privacy (openpgp)
Meeting:                IETF 93, Yokohama
Location:               Pacifico Yokohama Rooms 411/412
Date:                   3 November 2015
Time:                   17:10-18:40 JST
Chairs:                 Daniel Kahn Gillmor
                        Christopher LILJENSTOLPE
Minutes:                Rich Salz

- Agenda Bashing, Blue Sheets, etc (10 min)
No changes.

  - Call for an editor for 4880bis
Werner Koch volunteer (GPG lead developer)
Plan is to use git, markdown
Poll: email vs gitlab, evenly split; will take to the list.
Timing? Not yet considered; -00 and -01 that incorporate errata and ECC within a week or two. Maybe a year? Sense of the room?  No consensus.
Need to complete before CEASAR completes, will update if necessary.  

  - SEIPD -> SED attack : followup?
Magazinius pointed out you can convert symmetrically-encrypted integrity-protected data (SEIPD) to symmetrically-encrypted data (SED) without decrypting.  How to deprecate SED? We can say MUST NOT generate, but what about decrypting old stored SED data?  Bryan: do we know of any ciphers that were only ever used with SEIPD? Will follow-up on the mailing list.

- General issue of deprecration for stored data?  Possibilities (? Marks possibly-controversial)
	MD5; SHA1?; RIPE-MD
	IDEA; 3DES?; CAST5?; Blowfish?  Twofish?
	DSA? Size limits on RSA? NIST ECC? ElGamal?
What does deprecation mean?  Perhaps just encryption? Also decrypt if the content is known/believed to be not old
Is signature verification different?
There are several usability issues around this; we need to be careful.
Consensus is not to create new content with deprecated algorithms.
Perhaps address general issue of "what to do with old stuff"? And maybe answer is "lose it"
Stephen Farrell: Suggest reframe question as "everything deprecated unless shown that need to generate ones using old mechanism"
Discussion of how appropriate to put UI items in a protocol/data-format spec.
Strong consensus to start with everything removed, and then add the ones we want.

  - Fingerprint conclusion
	One format, or multiple
	Choice of digest?
	Truncation allowed?
	What is digested (creation, expiration times)?
	Distinguish v5 from v4?
	UI/UX guidance for implementers?
Hum on formats; sorry I glitched on the text and the hum results. *Please update this*
Please come to list with concrete suggestions; no opinions on roomt.  Having a concrete strawman proposal would be useful to get conclusions.

 - Symmetric crypto (Bryan Ford), draft-ford-openpgp-format  See slides in the proceedings.
Consensus to use a new packet type for AEAD-protected
FYI: Rogaway agrees to waive OCB patent for PGP (perhaps might not be sufficient)
Lots of information exposed by plaintext metadata
	Magic number -- this is an openpgp file, so its suspicious
	Cipher -- is it worth trying to crack (e.g., is it rc4 :)
	Passphrase: worth trying a password cracker
	Recipient key-id's: where to point the rubber hose?
	# of recipients: aha, it's *that* group of dissidents?
 Should we aim to protect it all (at cost of "trial" encryptions)?
Consider some padding mechanisms.

  - S2K (key derivation)
    - from https://password-hashing.net/ use Argon2i (constant time)
  Proposal by dkg: ask for early allocation; Stephen says wait for Simon's draft to appear to shake out any possible IPR issues.

 - Registry policies
To be mentioned on list

---

From: "brian m. carlson" <[email-masked]>
Date: Wed, 4 Nov 2015 01:01:22 +0000

> FYI: Rogaway agrees to waive OCB patent for PGP (perhaps might not be sufficient)

A note on using patented algorithms: Some organizations, such as Debian,
require that parts of software be able to be extracted and otherwise
used under the terms of the license.  Even if the OCB patent is waived
for OpenPGP, that would not be sufficient to allow parts of an OpenPGP
implementation that use OCB to be used in non-OpenPGP software.  That
might prevent such OpenPGP implementations from entering the main Debian
archive.  Other organizations may have similar restrictions.

This is just something to consider when discussing the use of patented
algorithms.
-- 
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: Wed, 04 Nov 2015 02:27:54 +0100

Hi Brian,

> This is just something to consider when discussing the use of patented

So in this case is non open-source software relevant at all? I don't
think so. For open-source initiative licenses, public domain and CC
there's a patent exemption anyway (since 2013):
http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf

Another one exists for non-military software implementations:
http://web.cs.ucdavis.edu/~rogaway/ocb/license2.pdf

And another one specific to OpenSSL:
http://web.cs.ucdavis.edu/~rogaway/ocb/license3.pdf

See also: http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm

Aaron

---

From: "brian m. carlson" <[email-masked]>
Date: Wed, 4 Nov 2015 02:07:52 +0000

> http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf

I suspect this is probably sufficient for Debian's purposes, although I
of course can't speak on their behalf.  Whether it is suitable for Red
Hat or other organizations with strict patent policies, I don't know.

My personal view is that using patented algorithms[0] will prevent at
least some adoption of the OpenPGP standard, even if that's overly
cautious and defensive, and that there are sufficient secure
alternatives such that we don't have to use patented algorithms.  The
less we can make implementers get lawyers involved, the better.

> http://web.cs.ucdavis.edu/~rogaway/ocb/license2.pdf

Clearly this is not suitable for Debian's purposes, as they prohibit
restrictions on fields of endeavor.

[0] By "patented algorithms," I mean those that don't grant a flat
royalty-free license.  SHA-2 is patented, but available under such a
royalty-free license.
-- 
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: Wed, 04 Nov 2015 11:31:13 +0100

Hi Brian,

> Hat or other organizations with strict patent policies, I don't know.

Not sure either. Probably best to ask them?

> restrictions on fields of endeavor.

I know. I signed the Debian social contract a while ago as well. This
was just for reference - I'm not sure that license is particularly
useful to anyone.

> royalty-free license.  SHA-2 is patented, but available under such a

The only problem I currently see is with commercial, military software
or hardware implementations. I'm not sure that is relevant to any
open-source project though. Would be interesting to hear Fedora/RedHat
people comment on this.

Aaron

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 05 Nov 2015 15:25:31 +0100

"brian m. carlson" <[email-masked]> writes:

> of course can't speak on their behalf.

I'm not convinced that license is sufficient given how the term "Open
Source Software" is defined.

One right that a user has with, for example BSD or GPL licensed code, is
to modify the code and sell/distribute the result to a third party (and
in the case of GPL, provide source code) and not publish the code
elsewhere.  This is how many proprietary products use FOSS code, for
example Microsoft Windows or your random Android app.  The license only
gives right to the patent for software projects which are publicly
available through the wording "by anyone":

   “Open Source Software” means software whose source code is published
   and made available for inspection and use by anyone because ...

So, no, I don't think that license is sufficient, and that patent
licensing terms in general, unfortunately, hampers wider adoption
because evaluating whether they are permissible or not is too hard.

/Simon

---

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

Hi,

> because evaluating whether they are permissible or not is too hard.

A bit later in the same paragraph it says:

```
All licenses certified by the Open Source Initiative at opensource.org
as of January 9, 2013 and all Creative Commons licenses identified on
the creativecommons.org website as of January 9, 2013, including the
Public License Fallback of the CC0 waiver, satisfy these requirements
for the purposes of this license.
```

OSI licenses include BSD, MIT et cetera: http://opensource.org/licenses

Don't get me wrong, I'm not trying to push this block cipher mode for
OpenPGP, I'm just commenting because I've worked on a TLS related draft
for OCB mode. IANAL.

Aaron

---

From: ianG <[email-masked]>
Date: Fri, 6 Nov 2015 02:00:55 +0000

Thanks Rich, adding my 2 yen.

> What does deprecation mean?  Perhaps just encryption? Also decrypt if the content is known/believed to be not old

Yes - practically, deprecated in the standard means no encryption, and 
implementations are free to decrypt older stuff.

> Is signature verification different?

No signing using old algos.

> Consensus is not to create new content with deprecated algorithms.

+1

> Perhaps address general issue of "what to do with old stuff"? And maybe answer is "lose it"

No, download an old copy of gpg or pgp2.3 and decrypt it.

> Strong consensus to start with everything removed, and then add the ones we want.

the one :)

> Consensus to use a new packet type for AEAD-protected

yes.

>   Should we aim to protect it all (at cost of "trial" encryptions)?

Yes - indistinguishable from random is the target.

This might not be achievable, but it should be the target.  We won't get 
there unless we start on the journey.

iang

---

From: Lutz Donnerhacke <[email-masked]>
Date: Fri, 6 Nov 2015 09:58:26 +0100

> No, download an old copy of gpg or pgp2.3 and decrypt it.

I oppose that.
One important use case for PGP is to sign binary blobs in archives in order
to verify their integrity. (take for instance the distribution of software)

Requiring the user to stick with old, unmaintained software (which might not
even run on it's current system and can't be compiled for the new
environment) is a no go.

---

From: Werner Koch <[email-masked]>
Date: Fri, 06 Nov 2015 15:11:40 +0100

Hi Lutz,

> even run on it's current system and can't be compiled for the new

We promised to keep on maintaining GnuPG 1.4, which is that old copy:
all RFC-4880 features.  You would need that for VMS anyway ;-).

Thus there is at least one maintained old software.

Shalom-Salam,

   Werner

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

---

From: ianG <[email-masked]>
Date: Sun, 8 Nov 2015 10:54:55 +0000

> Thus there is at least one maintained old software.

Exactly.  It doesn't matter what we write in the standard - some 
software maintainers will do the right thing because their users will 
revolt if they don't.

However, the "right thing" is a slippery concept.  It isn't a universal 
good, it's not a UN-mandated personal right.  Werner's right thing is 
not the right thing for the future and not the right thing for new users 
or other users or even for his users - all of them or all of the time.

If we want everyone in 2025 to be using the good stuff we design today 
in 2015, then *we have to be fierce* about chopping away the old 2.3 
cruft every chance we get.

iang