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

"Derek Atkins" <derek@ihtfp.com> Mon, 30 October 2017 19:52 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 5D53113F65D for <openpgp@ietfa.amsl.com>; Mon, 30 Oct 2017 12:52:27 -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 RV9DsV_uOncm for <openpgp@ietfa.amsl.com>; Mon, 30 Oct 2017 12:52:25 -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 262EF13FAFF for <openpgp@ietf.org>; Mon, 30 Oct 2017 12:51:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail2.ihtfp.org (Postfix) with ESMTP id D33A2E2047; Mon, 30 Oct 2017 15:51:43 -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 04007-03; Mon, 30 Oct 2017 15:51:41 -0400 (EDT)
Received: by mail2.ihtfp.org (Postfix, from userid 48) id 24298E2064; Mon, 30 Oct 2017 15:51:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ihtfp.com; s=default; t=1509393101; bh=XTG2x5FoCVZGiZMvgEzowMslU9UYsTHKkcCDUZ+8h8A=; h=In-Reply-To:References:Date:Subject:From:To:Cc; b=PAN1rZ34NrQl8FHvqh5DOa5QBIjm2B9qBlQM59pe0J8bJ6nZopY/it9Lg4L6Am1A+ 3ykLLb8dS7pjZZ1XCopACbeRU1xqHsKto+X0+3eeQIeMQ5r7qhnDkVSK8PLyArcT8u zrzp0YPDtbRoAcpvlDfpsbhWdL2rBkCMLzpz/Z2U=
Received: from 192.168.248.250 (SquirrelMail authenticated user warlord) by mail2.ihtfp.org with HTTP; Mon, 30 Oct 2017 15:51:41 -0400
Message-ID: <704d117e3b4f3b093d2846d8433ebbf2.squirrel@mail2.ihtfp.org>
In-Reply-To: <alpine.LRH.2.21.1710301516360.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>
Date: Mon, 30 Oct 2017 15:51:41 -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/jnwCIqqrNoi9a9MVRaU7alUIcBE>
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 19:52:27 -0000

Paul,

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.

>     That's something you want to
> avoid more then giving people a list of 6 sexy algorithms to choose
> from.

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.

>> But the real point is that there are so few methods that people want to
>> support *IN THE PROTOCOL* that there is little reason, IMNSHO, to
>> prevent
>> them from doing so in a standard way.
>
> I don't understand that sentence.

Okay, let me try again.

How many public key methods are there?  Not many.
How many ciphers are there?   Again, not many.
Similarly, how many AEAD methods are there?   Again... not many.

Even moreso, there are even fewer methods people are proposing to include
in the OpenPGP protocol than the limited number of methods that are out
there.

There are SO FEW methods that, indeed, if even one implementer wants to do
it in a standard way we should let them.

Maybe that implementer is doing something privately, but still wants to do
it in a standard way.  We should let them.

Maybe they feel that it'll be years before someone else is interested, but
they want to ensure their code written today will work down the road.   We
should let them.

In other words, we should be accepting in relinquishing protocol numbers.

>> Remember, just because the protocol supports a method does not mean
>> implementations will.
>
> If you add things to the protocol that the vast majority will not
> implement, you have lost already and that added thing becomes useless.

You've clearly never worked on (or in) a private enclave.  The IETF should
not be in the position to say that private enclaves MAY NOT exist.  But
you seem to be implying that by your stance.

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).

>> 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.

>    Do you think most users can make a meaningful
> decision about which algorithms to trust or not and for how long?

That's irrelevant to this discussion.

> The reason for a lot variance with TLS or IKE/IPsec with protocols is
> that performance does matter. For openpgp, performance hardly matters.
> You're not doing 1Gbps or running on an IoT device with 32kb RAM or
> require less then 25ms latency.

I'm afraid you're wrong here.  I *AM* running OpenPGP on an IoT device,
and in fact that IoT device has less than 32kB RAM.  (I'm assuming you
meant 32kB, and not 32kb == 4KB, which is exactly how much RAM my device
has).

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).  Moreso, in a
few years, my messages might escape my enclave, which is yet another
reason I'd like to do it in a standard way.

(And yes, I've moved well beyond OCB in this discussion).

> Paul

-derek

-- 
       Derek Atkins                 617-623-3745
       derek@ihtfp.com             www.ihtfp.com
       Computer and Internet Security Consultant