Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis
Gregory Maxwell <gmaxwell@gmail.com> Tue, 31 October 2017 02:29 UTC
Return-Path: <gmaxwell@gmail.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 A42041389E6 for <openpgp@ietfa.amsl.com>; Mon, 30 Oct 2017 19:29:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cm2yq3ObtjKX for <openpgp@ietfa.amsl.com>; Mon, 30 Oct 2017 19:29:55 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E3F13374A for <openpgp@ietf.org>; Mon, 30 Oct 2017 19:29:54 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id v27so10977253uav.7 for <openpgp@ietf.org>; Mon, 30 Oct 2017 19:29:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xgc5tayMIjfTiGEmPi1cMPGqH4pzbNkNyUKj+O7QWDA=; b=hVBLVP71Nm/W4TYSl9QE++fNymo/2gMtGa04vqmwzofoIFaCUliQBWlUdjIrmLrWRm 8AhkNuTLPsDB80LXg6X9cVk/bWPgFYGXsHUjBnzjtGmKbSGXoxfZUbJHfEc4HvkbjY9V jSiD1OPN2W8/H1Vp05NX18b3x6gF2tPV6VyeuO9hVBrkruWyM9okXdrOXv0pEIAKDUpz e+EwvHAikJ/hYWWgwJx+lTeg0lsGRHI/ZzbVT4WQIzyJ2JBgZwOJEXujNM9nA+ku3yRF DnHjzg3NHXRPGzBpWhebrNGO6mmITxNKoVttsd6F8LoQgaRaEwdgosdYlQ2FPWnnBmYt zhaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xgc5tayMIjfTiGEmPi1cMPGqH4pzbNkNyUKj+O7QWDA=; b=WSunMDNln57UqMdKAy2SIMTNxgFvZrlpAx49MGeXqbKEwmMZAsgjGRrsMfx+lCkXRq 4wmNEOj+NwPEhN7XM6KS0ZL1Kxak9ogdrREt5P62210C3uK07s5PzBjB2mV/g+QuPVMr dSQneI0Gr+s9rrhfm/AqzKwAgo3dkYFtdaziqjWR6mN1fnTzuPCdsa1tlcKwHgno8H2W L3c4WkdQedcoxRqv7tRMy2GuK+LHIOaOvdoaDtsnDCQBT0ZkvCBj8DahSa2nb0FMTheH cTOLLv8ekilyohDI+oMRIkzIJR9Opub/duZq7Nlq3jci9D5qd736dWIjV8dd7FvN5Elb zVOw==
X-Gm-Message-State: AMCzsaVQIyfgULnAVTHnY2ayrN5tptgm7yFP4MpnLNe0XdUGQ+SwFmMM 8daOFUkkvtYwbzxM5mZLnG0EcCmf92mhX0j980I=
X-Google-Smtp-Source: ABhQp+QYUOBob7sXIkR3Rh+pZQEWx2f20jjUOBl1cwz7lSFOBWve0rOPSdO66iVeZ3yKmvFKHiS2UGT4J4zHuPMdIFM=
X-Received: by 10.176.20.143 with SMTP id d15mr318929uae.127.1509416993893; Mon, 30 Oct 2017 19:29:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.87.93 with HTTP; Mon, 30 Oct 2017 19:29:52 -0700 (PDT)
In-Reply-To: <alpine.LRH.2.21.1710280403490.7356@bofh.nohats.ca>
References: <D0505748-E376-4CF9-8906-9AD77838FB23@ribose.com> <1508981649515.71466@cs.auckland.ac.nz> <07C9EFDF-C8C2-4433-A9F9-DC3D7AFD5499@ribose.com> <6AC83857-62D9-45DF-9DAE-928CF0E45A96@nohats.ca> <87she556tv.fsf@wheatstone.g10code.de> <1509093954061.51049@cs.auckland.ac.nz> <36023233-856C-4A6D-BAF9-28037B4DA0F7@ribose.com> <20171028003345.6y5igwx5cuxfxlkm@genre.crustytoothpaste.net> <06D50F48-26BD-4729-8071-576DA8E226AA@ribose.com> <alpine.LRH.2.21.1710280403490.7356@bofh.nohats.ca>
From: Gregory Maxwell <gmaxwell@gmail.com>
Date: Tue, 31 Oct 2017 02:29:52 +0000
Message-ID: <CAAS2fgSfY5YqT2ExhtY6MrEJxNWMN77rJTtsO1r6aixOAJexFw@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: Ronald Tse <tse@ribose.com>, "openpgp@ietf.org" <openpgp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/iiqEYCAdn5Ry7rPErRCMR659SOY>
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: Tue, 31 Oct 2017 02:29:57 -0000
On Sat, Oct 28, 2017 at 8:23 AM, Paul Wouters <paul@nohats.ca> wrote: > For protocols like IKE/IPsec or TLS, where you negotiate a cipher suite, > MAY algorithms are fine. > > For a protocol where both parties are not online at the same time, and > where one party might not know the other party's capabilities at all, > a MAY algorithm can lead to non-interoperability (with human latency > involved) This is a great argument but it does not apply here: A PGP public key lists the suites that it supports. The only way you get an incompatibility is if the far end is OCB-only and you can't support it and that failure is "realtime" not delayed. > It would have been nice to have had OCB support when it was invented. > By now, the gains are pretty minimal. While there is an argument for IIRC most or all of the popular OCB alternatives are CTR based and highly brittle to nonce reuse. SIV mode is the only currently standardized-in-any-way AEAD mode that I'm aware of that has some robustness to nonce reuse. Not that IV reuse should be a major risk factor for OpenPGP-- but I think we've all learned that brittle constructions tend to result in unwelcome surprises, that line if thinking is why AEAD modes exists in the first place. >The fact that there is a discussion and unclarity > about this at all shows that there is an issue here. Never underestimate people's ability to have a debate. > The lesson here is, don't put arbitrary restrictions on your algorithm if > you want to see widespread adoption. This seems rather moralistic rather than a practical consideration. IETF protocols routinely register encodings and codepoints for highly restricted techniques: OCB in OpenPGP would only get used when there is mutual support on both ends. I don't think the laudable effort of avoiding restricted techniques as mandatory in standardized protocols is aided by a total war on them that covers optional use of less restrictively licensed things. The standards process question should primarily be will it get use if it exists? If not, don't bother. The licensing of OCB appears to be very permissive for more than a few very broad classes (including Free Software implementations). Input from implementers on if they'd implement it if specified should be the primary metric. Also, if it gets used will it enhance or harm security (seems more like the former in this case)? I don't believe there is any 1:1 replacement for it currently, if there were that would be a consideration too. One could make an argument that the grab-bag-choose-your-own-adventure of many cryptographic options is a bad design, but I think the ship has already sailed on that one in 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