[openpgp] DRAFT minutes for OpenPGP at IETF 94

"Salz, Rich" <rsalz@akamai.com> Tue, 03 November 2015 09:41 UTC

Return-Path: <rsalz@akamai.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 296631B30E6 for <openpgp@ietfa.amsl.com>; Tue, 3 Nov 2015 01:41:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.011
X-Spam-Level:
X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQ4gGt6585ey for <openpgp@ietfa.amsl.com>; Tue, 3 Nov 2015 01:41:33 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 513651B30D9 for <openpgp@ietf.org>; Tue, 3 Nov 2015 01:41:33 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B9C9B42456E; Tue, 3 Nov 2015 09:41:32 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 985B2424519; Tue, 3 Nov 2015 09:41:32 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1446543692; bh=80mxdngARRYsOiKPQqiMGFfKok32KEGI8lMdjKmQ5VQ=; l=3406; h=From:To:CC:Date:From; b=qRrEatt1cFDOFso3q7ttIeHtpUsEVR8nQwtUbYup6RQGCfHgQAIUQv0OCRRy2HWv3 cBwDQZ4tEDRaow3iLxyNhiFR9qEbnv1viY5sXrzzBFoDFym3WYFy/bTM7r09kD4Cy9 PKrqsVDjIojxhCDGan4PwwAs0wAIZRQ1OzTphe4c=
Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 8C3152039; Tue, 3 Nov 2015 09:41:32 +0000 (GMT)
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1076.9; Tue, 3 Nov 2015 01:41:32 -0800
Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1076.000; Tue, 3 Nov 2015 04:41:32 -0500
From: "Salz, Rich" <rsalz@akamai.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>, "ietf@cdl.asgaard.org" <ietf@cdl.asgaard.org>
Thread-Topic: DRAFT minutes for OpenPGP at IETF 94
Thread-Index: AdEWDje/Y0w41e42QS+efNAoYRs2AA==
Date: Tue, 3 Nov 2015 09:41:31 +0000
Message-ID: <e4308a7bfcc443d5b9921babf8762a8b@usma1ex-dag1mb1.msg.corp.akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.237.146]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/openpgp/QMNaGHrINiY7ZxGatG82tqfBtS4>
X-Mailman-Approved-At: Tue, 03 Nov 2015 14:13:12 -0800
Cc: "Salz, Rich" <rsalz@akamai.com>, "openpgp@ietf.org" <openpgp@ietf.org>
Subject: [openpgp] DRAFT minutes for OpenPGP at IETF 94
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Nov 2015 09:41:35 -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