Re: [openpgp] Proposal to include AEAD OCB mode to 4880bis

"Derek Atkins" <derek@ihtfp.com> Mon, 30 October 2017 21:10 UTC

Return-Path: <derek@ihtfp.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 1EE0113FB7F for <openpgp@ietfa.amsl.com>; Mon, 30 Oct 2017 14:10:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Level:
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ihtfp.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 cRgJ99HYxWLz for <openpgp@ietfa.amsl.com>; Mon, 30 Oct 2017 14:10:03 -0700 (PDT)
Received: from mail2.ihtfp.org (MAIL2.IHTFP.ORG [204.107.200.7]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3285B13FB99 for <openpgp@ietf.org>; Mon, 30 Oct 2017 14:09:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id 0260DE2035; Mon, 30 Oct 2017 17:09:17 -0400 (EDT)
Received: from mail2.ihtfp.org ([127.0.0.1]) by localhost (mail2.ihtfp.org [127.0.0.1]) (amavisd-maia, port 10024) with ESMTP id 06168-03; Mon, 30 Oct 2017 17:09:14 -0400 (EDT)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id D4394E2049; Mon, 30 Oct 2017 17:09:13 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1509397753; bh=6XWEFHXSzTRfMjo7nZRwPijUiPFDu/AqldWy3sbxnQA=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=Us5U7f7e0GazymCmwRmAoeh2i218iBGPFxrNBPOHHLwSbd8HB51+RpZqB3E2R43mm RwZN5frq6KJDLZTKVyp2tTkRyAak0KOqdi8zA/HbtzpAUSCbFbEHyX7mciWtMZ8Hvb wU/qXXns9hqgezJT6+Zo9+yFvE9OYBPs1XqvVLT4=
Received: from 192.168.248.250 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 30 Oct 2017 17:09:13 -0400
Message-ID: <f33b464975d7f08fb74999de94e4348c.squirrel@mail2.ihtfp.org>
In-Reply-To: <alpine.LRH.2.21.1710301606430.31082@bofh.nohats.ca>
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>
Date: Mon, 30 Oct 2017 17:09:13 -0400
From: "Derek Atkins" <derek@ihtfp.com>
To: "Paul Wouters" <paul@nohats.ca>
Cc: "Rick van Rein" <rick@openfortress.nl>, "openpgp@ietf.org" <openpgp@ietf.org>
User-Agent: SquirrelMail/1.4.22-14.fc20
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: 8bit
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: Maia Mailguard 1.0.2a
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/nkmG8oovdZjB3rXh9WBWrjBuVo8>
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 21:10:15 -0000

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             www.ihtfp.com
       Computer and Internet Security Consultant