Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis
Ronald Tse <tse@ribose.com> Mon, 30 October 2017 23:58 UTC
Return-Path: <tse@ribose.com>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C8613FC76 for <openpgp@ietfa.amsl.com>; Mon, 30 Oct 2017 16:58:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ribose.onmicrosoft.com
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 RDdZdFpfZkd0 for <openpgp@ietfa.amsl.com>; Mon, 30 Oct 2017 16:58:22 -0700 (PDT)
Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-pu1apc01on0069.outbound.protection.outlook.com [104.47.126.69]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 900E5CD15 for <openpgp@ietf.org>; Mon, 30 Oct 2017 16:50:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ribose.onmicrosoft.com; s=selector1-ribose-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=I2av92G0OCGUJkMvGVLLxYEBC2GC2IiDKM6kKFizTXk=; b=vm64jHZGWE2mRHE0BomZe3+4tvCgh7JJYvCUzjSWT6I50FEYZNoKkhq8EBo9VCs49U5bmWBfE/FEbNQhetOIJieBwTPX3jwjFOaF7llqUAPdaxQ7lwR/Jbh99BgmSYwyl1aTr9T/vGnuz3BoG2G81cw73s6v4EYwXxFwj8VNgtY=
Received: from PS1PR01MB1050.apcprd01.prod.exchangelabs.com (10.165.210.30) by PS1PR01MB1052.apcprd01.prod.exchangelabs.com (10.165.211.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.178.6; Mon, 30 Oct 2017 23:50:01 +0000
Received: from PS1PR01MB1050.apcprd01.prod.exchangelabs.com ([fe80::38f5:8fb:9da0:a038]) by PS1PR01MB1050.apcprd01.prod.exchangelabs.com ([fe80::38f5:8fb:9da0:a038%14]) with mapi id 15.20.0178.012; Mon, 30 Oct 2017 23:50:01 +0000
From: Ronald Tse <tse@ribose.com>
To: "openpgp@ietf.org" <openpgp@ietf.org>
Thread-Topic: [openpgp] Proposal to include AEAD OCB mode to 4880bis
Thread-Index: AQHTTXH5xYQNIsRUz0C1s+LLoU2hJaL0wWoAgAAFh4CAB8PBK4AAAg8AgAAqYYCAAAUMgIAAEeeAgAAICYCAAAqCgIAACyiAgAAs7AA=
Date: Mon, 30 Oct 2017 23:50:01 +0000
Message-ID: <3BD06D06-2CDF-4D76-AA6B-F767B8E54C2E@ribose.com>
References: <D0505748-E376-4CF9-8906-9AD77838FB23@ribose.com> <alpine.LRH.2.21.1710251219190.18006@bofh.nohats.ca> <59F0C015.2050303@openfortress.nl> <sjmbmko1x4i.fsf@securerf.ihtfp.org> <59F74542.5080409@openfortress.nl> <37D92E03-5071-42AC-B057-AA3C18B0762A@nohats.ca> <c67d205fcc8d65c48dd7f3af01e03684.squirrel@mail2.ihtfp.org> <alpine.LRH.2.21.1710301516360.31082@bofh.nohats.ca> <704d117e3b4f3b093d2846d8433ebbf2.squirrel@mail2.ihtfp.org> <alpine.LRH.2.21.1710301606430.31082@bofh.nohats.ca> <f33b464975d7f08fb74999de94e4348c.squirrel@mail2.ihtfp.org>
In-Reply-To: <f33b464975d7f08fb74999de94e4348c.squirrel@mail2.ihtfp.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=tse@ribose.com;
x-originating-ip: [220.246.174.191]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; PS1PR01MB1052; 6:jeVKkFo0QJHJW6+FfUFcM4NVhusqJ3VllnqHfpJDCOKj546MNcGNNfioFfgEKk1eIoWxFynnKUiFi9n8Qiy63kA87t+BEBly7+SKvQhRq6cdv314pSmFYTC8QafumE/cF6kjSdOiiYZlMEnteGTEIf0AdqdhL2/vYH2OiG2b/MVE0LDtc+HRNSaF28ssGiHtT5VV4ZtFLdMLwIBt4CqE1wt4l10KdZlzqx6qxGh4CLJF2u4+EOx2IhNdmg0mQmnsMjJBAAUF1myITfxz3Nww4/0ibk3FuF6BtEyQgmOtvk9DoTReDwvZQ5Edl2opS9mUzleoQ0QDK3gcMu/U3pp9d/BZ726DLFR2FKYqmoLaM6k=; 5:MqE+IWdniWnBaj+7FD+4HoDeMEremsQ4L95nZkAeOkUXzfmKAuFWPzzR+u1KOR14rR30vBnhQDwhAWp1AvTLUSdYFHde1VnDHPUnGO3NJx7eayRrdlXdiC8ZKXeGxa7O5v/s3XBhoz+p2i9+Jchu+YfE2HxL+BMoC8F+AA2gl+I=; 24:N2WzoaEkRwcBkr4TIUkY9IQ6XemLMYaoH516fWJUXKsBbYsgqM/UANf3F8SmXudMbRa03VeLA6/pTuJYv5i09ljLEnj0zzoNq4KtqHxkjEQ=; 7:H75YlfOjQKujSikqNirE8rSMCzsHb/+sRQK7FmJGMMYZEiFmbOnr5pfM1X7qNw5a5rzwzb8+CU+tbzterE52QY8ew4FSaMfis0U5YwW3US+pScQYpANcDiSAeXq3Kht1+zbrvZq8CM8Fp6Qf8uXJT4GFOo8aYDIFGw/qSes27LxALM7F7CdypXK2xH0nRbs5668+cKFc6w0dgICQeQ+gPd+iboNYZp60lPpIJPpfuZNA+hMDx8MzPiJiIJJMRfGq
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: bab2d5df-d56b-49d9-7bf4-08d51ff0efd6
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(2017052603199); SRVR:PS1PR01MB1052;
x-ms-traffictypediagnostic: PS1PR01MB1052:
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-microsoft-antispam-prvs: <PS1PR01MB105296B0F43A0E39B37E1D48D7590@PS1PR01MB1052.apcprd01.prod.exchangelabs.com>
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231020)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(6041248)(20161123558100)(2016111802025)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:PS1PR01MB1052; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:PS1PR01MB1052;
x-forefront-prvs: 0476D4AB88
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(376002)(346002)(189002)(24454002)(199003)(50986999)(101416001)(106356001)(2900100001)(25786009)(76176999)(3846002)(6116002)(99286003)(33656002)(102836003)(54896002)(53946003)(6306002)(6512007)(236005)(478600001)(105586002)(6246003)(53936002)(66066001)(6506006)(6486002)(2351001)(54356999)(36756003)(6436002)(189998001)(82746002)(1730700003)(97736004)(83716003)(68736007)(5640700003)(5660300001)(2950100002)(229853002)(2906002)(81166006)(8676002)(81156014)(8936002)(6916009)(316002)(966005)(2501003)(3280700002)(5250100002)(3660700001)(93886005)(86362001)(14454004)(606006)(53546010)(7736002)(217873001)(579004)(559001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:PS1PR01MB1052; H:PS1PR01MB1050.apcprd01.prod.exchangelabs.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: ribose.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_3BD06D062CDF4D76AA6BF767B8E54C2Eribosecom_"
MIME-Version: 1.0
X-OriginatorOrg: ribose.com
X-MS-Exchange-CrossTenant-Network-Message-Id: bab2d5df-d56b-49d9-7bf4-08d51ff0efd6
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 23:50:01.6716 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: d98a04ff-ef98-489b-b33c-13c23a2e091a
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PS1PR01MB1052
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/VuSfTDbjg64sOPyQuEHZmS0IA68>
Subject: Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 30 Oct 2017 23:58:25 -0000
Thank you Derek for the insightful comments. I fully agree with them. The “algorithm registries” (including the AEAD registry) exist to allow multiple algorithms, whether optional or mandatory, to exist. Otherwise there should just be one big MUST and we all get on with it. The point of a standard is to allow independent implementations to interoperate — the usage of private numbers defeats that intention. OpenPGP is already used in more places than just email exchanges, take file signature verification as an example. It should not be up to the workgroup to decide that such usage should now be prohibited. In fact within the entire RFC 4880, there is no mention that OpenPGP is intended for email exchange — the spec was intended to be a generic message format allowing people to use it as they see fit. To answer the patent concerns of OCB: Rogaway is willing to provide a royalty-free license for all implementers and users of OpenPGP, served alongside the draft as an IETF IPR. This means that the previous points of “military-use” or linkage to “closed-source” software are resolved. Ron _____________________________________ Ronald Tse Ribose Inc. On Oct 31, 2017, at 5:09 AM, Derek Atkins <derek@ihtfp.com<mailto:derek@ihtfp.com>> wrote: On Mon, October 30, 2017 4:29 pm, Paul Wouters wrote: On Mon, 30 Oct 2017, Derek Atkins wrote: On Mon, October 30, 2017 3:22 pm, Paul Wouters wrote: It was an example of how some people having IDEA and other not having it causes interop issues to the point that I need to manually hack my implementation to talk to those people. Yes, and IMHO, IDEA should get added back in. In this day and age there is zero reason to prohibit it. You miss my point. Implementors made decisions and as a result, non-expert endusers ended up not being able to send each other encrypted email. I am sayong don't repeat that mistake. And you're saying the mistake is that IDEA was included in the first place? Or that IDEA was removed? Or...??? Note that it's not "PEOPLE" who are choosing them, per se. It's the implementers, who one would think would have a better idea of what to implement and why. That still does not help much against someone using a new algorithm and someone else using old software that does not have that algorithm. Sure. Just like you're not going to be able to run Linux on an Apple ][ How long does it take for any now added algorithm to be commonly supported? By paranoid people who dont want to upgrade their offline systems? :) Probably a few years at least, which is a good reason to get it into the spec NOW for the hope that in 3-5 years it'll be more widely deployed. Maybe that implementer is doing something privately, but still wants to do it in a standard way. We should let them. That's what private number ranges are for. That's not "in a standard way". It also only works for experimentation. If you ever expect to deploy it you should NOT use a private number range, because MY private numbers and YOUR private numbers may conflict. Maybe the implementer who wants to add OCB doesn't care if your implementation can read it, because your implementation is very unlikely to ever see an OCB message. Why do you want to say that they may not do that (which is what you're saying by implying that your implementation must support every feature and that the protocol may not support features that your implementation does not support). As long as you can detect the support when you have the public key, that's probably okay. You can. The self-signature on a key encodes that. But that's still a weak argument to allow vanity algorithms, as it will still increase the chance that multiple parties don't share those in their implementation. Perhaps, but that's a different argument and unrelated to whether the spec should specify a code point. You seem to be arguing that if it's not 100% in use everywhere then we shouldn't allocate a code point. I'm suggesting that code points are relatively cheap and should be open to most all comers with reasonable requests. And how does this work when my phone supports some algorithms, and my laptop supports other. How do I announce that in my public key? It looks like you'd be forced to only publish the shared algorithms. I wouldn't even know how to announce that. How are you sharing your keypairs across your devices? But if the protocol does NOT support some methods it might prevent some users from using the protocol. Which is a good thing? No. It's not. We should encourage people to use OpenPGP. It's a great protocol, and anything we do that prohibits adoption is a bad thing. Swiss army knives are great tools. Raise your hand if you never cut yourself with one. * Raises his hand * You're right, they are great tools, and they are great because they include so many tools, even tools that not everyone needs. And even better, there are different models of swiss army knifes (SAK) that include different sets of tools. So my knife probably has a different set than yours. And that's a good thing. If every SAK contained the same set of tools then it would probably be less useful. When I was a kid I used the magnifying glass all the time, but never the saw. Later on I found uses for the saw, but kind of lost a use case for the magnifying glass. I'm running OpenPGP specifically because the data formats are smaller and easier to generate/parse than X.509, so I *CAN* actually run it in an IoT device. Of course I'm extremely limited in what methods I support, but I happen to control both ends of the communication so I can work in an enclave and control the implementation. This is exactly why we should be open in what we accept. In my case, I don't care if your implementation does not support my methods, but I want to ensure that I can implement my methods in a standard way such that it wont interfere with you (and you wont interfere with me). Ok, well if all of that needs to be supported I guess we will be cursed with an amount of failure as the price to pay for the freedom to shoehorn openpgp on everything. I still think it is wise to try and limit the number of algorithms with similar cryptographic and architectural properties. I think you're continually conflating the OpenPGP Specification / Protocol with various implementations. We already have the case that different implementations include different crypto methods. In fact we've lived with that case for the past two decades and the world has not ended. I'm saying that the SPEC should allow the freedom. I also feel it's fine if GPG chooses not to implement something that I want in my implementation (or, vice versa). I also feel it's fine if you choose even different. This is exactly the purpose of MUST, SHOULD, and MAY in the spec. You KNOW that a compliant implementation will overlap in the MUST methods. Paul -derek -- Derek Atkins 617-623-3745 derek@ihtfp.com<mailto:derek@ihtfp.com> www.ihtfp.com<http://www.ihtfp.com/> Computer and Internet Security Consultant _______________________________________________ openpgp mailing list openpgp@ietf.org<mailto:openpgp@ietf.org> https://www.ietf.org/mailman/listinfo/openpgp
- [openpgp] Proposal to include AEAD OCB mode to 48… Ronald Tse
- Re: [openpgp] Proposal to include AEAD OCB mode t… Werner Koch
- Re: [openpgp] Proposal to include AEAD OCB mode t… Paul Wouters
- Re: [openpgp] Proposal to include AEAD OCB mode t… Rick van Rein
- Re: [openpgp] Proposal to include AEAD OCB mode t… Peter Gutmann
- Re: [openpgp] Proposal to include AEAD OCB mode t… Ronald Tse
- Re: [openpgp] Proposal to include AEAD OCB mode t… Ronald Tse
- Re: [openpgp] Proposal to include AEAD OCB mode t… brian m. carlson
- Re: [openpgp] Proposal to include AEAD OCB mode t… Paul Wouters
- Re: [openpgp] Proposal to include AEAD OCB mode t… Werner Koch
- Re: [openpgp] Proposal to include AEAD OCB mode t… Peter Gutmann
- Re: [openpgp] Proposal to include AEAD OCB mode t… Ronald Tse
- Re: [openpgp] Proposal to include AEAD OCB mode t… Hanno Böck
- Re: [openpgp] Proposal to include AEAD OCB mode t… Werner Koch
- Re: [openpgp] Proposal to include AEAD OCB mode t… Werner Koch
- Re: [openpgp] Proposal to include AEAD OCB mode t… Ronald Tse
- Re: [openpgp] Proposal to include AEAD OCB mode t… brian m. carlson
- Re: [openpgp] Proposal to include AEAD OCB mode t… Ronald Tse
- Re: [openpgp] Proposal to include AEAD OCB mode t… Paul Wouters
- Re: [openpgp] Proposal to include AEAD OCB mode t… Derek Atkins
- Re: [openpgp] Proposal to include AEAD OCB mode t… Derek Atkins
- Re: [openpgp] Proposal to include AEAD OCB mode t… Derek Atkins
- Re: [openpgp] Proposal to include AEAD OCB mode t… Rick van Rein
- Re: [openpgp] Proposal to include AEAD OCB mode t… Paul Wouters
- Re: [openpgp] Proposal to include AEAD OCB mode t… Derek Atkins
- Re: [openpgp] Proposal to include AEAD OCB mode t… Paul Wouters
- Re: [openpgp] Proposal to include AEAD OCB mode t… Derek Atkins
- Re: [openpgp] Proposal to include AEAD OCB mode t… Paul Wouters
- Re: [openpgp] Proposal to include AEAD OCB mode t… Derek Atkins
- Re: [openpgp] Proposal to include AEAD OCB mode t… Ronald Tse
- Re: [openpgp] Proposal to include AEAD OCB mode t… Gregory Maxwell
- Re: [openpgp] Proposal to include AEAD OCB mode t… Paul Wouters
- Re: [openpgp] Proposal to include AEAD OCB mode t… Ronald Tse
- Re: [openpgp] Proposal to include AEAD OCB mode t… Paul Wouters
- Re: [openpgp] Proposal to include AEAD OCB mode t… Salz, Rich
- Re: [openpgp] Proposal to include AEAD OCB mode t… Werner Koch
- Re: [openpgp] Proposal to include AEAD OCB mode t… brian m. carlson
- Re: [openpgp] Proposal to include AEAD OCB mode t… Derek Atkins
- Re: [openpgp] Proposal to include AEAD OCB mode t… brian m. carlson