IETF Logo Mail Archive

Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts

Uri Blumenthal <uri@mit.edu> Sun, 10 March 2019 21:42 UTC

Return-Path: <uri@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AE081277E6; Sun, 10 Mar 2019 14:42:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 cXxBBSP72AV7; Sun, 10 Mar 2019 14:42:45 -0700 (PDT)
Received: from outgoing-exchange-5.mit.edu (outgoing-exchange-5.mit.edu [18.9.28.59]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AADA127287; Sun, 10 Mar 2019 14:42:45 -0700 (PDT)
Received: from oc11exedge2.exchange.mit.edu (OC11EXEDGE2.EXCHANGE.MIT.EDU [18.9.3.18]) by outgoing-exchange-5.mit.edu (8.14.7/8.12.4) with ESMTP id x2ALhFC1027022; Sun, 10 Mar 2019 17:43:36 -0400
Received: from W92EXHUB14.exchange.mit.edu (18.7.73.25) by oc11exedge2.exchange.mit.edu (18.9.3.18) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Sun, 10 Mar 2019 17:41:28 -0400
Received: from OC11EXPO28.exchange.mit.edu ([169.254.1.251]) by W92EXHUB14.exchange.mit.edu ([18.7.73.25]) with mapi id 14.03.0439.000; Sun, 10 Mar 2019 17:41:53 -0400
From: Uri Blumenthal <uri@mit.edu>
To: Tony Arcieri <bascule@gmail.com>
CC: Benjamin J Kaduk <kaduk@mit.edu>, Ted Krovetz <ted@krovetz.net>, CFRG <cfrg@irtf.org>, "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>, secdir <secdir@ietf.org>
Thread-Topic: [secdir] [Cfrg] ISE seeks help with some crypto drafts
Thread-Index: AQHU1d8we5ehKkr/YUmHIR9Gehv2BKYCboEAgAMHO4CAAAoAgIAAAWuAgAAeBICAAAxIgA==
Date: Sun, 10 Mar 2019 21:41:52 +0000
Message-ID: <2B472CCB-4414-41FB-8806-E18D916C73F7@mit.edu>
References: <1d8de489fc976b63a911573300a431d4.squirrel@www.amsl.com> <alpine.LRH.2.21.1903081227200.30421@bofh.nohats.ca> <CAHOTMVLtjVxZNy3bFRn09xH+cOw+tPi2CL3BkaQuJEqxAzGOJg@mail.gmail.com> <edca701b-21f3-c80c-d754-fc333f1e2e04@cs.tcd.ie> <20190310182935.GE8182@kduck.mit.edu> <B876B124-7EDE-4E20-A878-3AAD3FA074BC@krovetz.net> <20190310191026.GF8182@kduck.mit.edu> <CAHOTMVJcosEgYV9caWapgyzQfh-g4k5DQry5n42bEfrkJvmdWQ@mail.gmail.com>
In-Reply-To: <CAHOTMVJcosEgYV9caWapgyzQfh-g4k5DQry5n42bEfrkJvmdWQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; boundary="Apple-Mail-ECEB2413-2B79-4DBA-B8F4-90B00E4DB708"; protocol="application/pkcs7-signature"; micalg="sha-256"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/mj6tGJdX0dDjS5ouxOyykrFOa0A>
Subject: Re: [secdir] [Cfrg] ISE seeks help with some crypto drafts
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 10 Mar 2019 21:42:47 -0000

Completely agree with your OCB points. It looks like the IPR issues would be resolved fairly quickly.

As for the wideblock mods - I'm perfectly willing to champion it at CFRG, if a champion is needed.  As I said, while it's not likely to apply to, e g., TLS  1.4 - there are use cases today, and I expect to see more in the future.

Sent from my test iPhone

> On Mar 10, 2019, at 16:58, Tony Arcieri <bascule@gmail.com> wrote:
> 
>> On Sun, Mar 10, 2019 at 12:10 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
>> > I would like to remind everyone that OCB is not a "new mode". It is specified in RFC 7253. This work generalizes the specification -- without changing the 128-bit block case -- to allow other block cipher block lengths.
>> 
>> It's still a "distinct choice that a protocol designer (or user) picking a
>> cipher has available to choose from", which is where the perceived downside
>> of new things comes from.  My apologies for conflating the technical term
>> with the generic.
> 
> I think there are significant compelling reasons to prefer OCB mode over pretty much all other existing modes:
> 
> - Recent CAESAR winner (one of many in the portfolio, but)
> - Fast anywhere AES is fast. No CLMUL required (good for embedded)
> - Well-studied: IMO OCB is more likely than not be covered in classes/textbooks on symmetric cryptography
> 
> I think the IPR concerns are the main reason it has not seen more widespread adoption.
> 
> If you were to ask me "Is it better than AES-GCM?", my answer is yes. OCB hits the sweet spot of being a construction which is "fast everywhere", as opposed to the split between AES-GCM and AES-CCM we see between desktops/servers/high-end mobile vs embedded devices.
> 
> The wide block modes are a different question. I think they're potentially interesting in use cases I'm not particularly familiar with (e.g. mixnets). I'm not going to be the one to champion those through the CFRG, though.
> 
> That said, the inability to use OCB mode in IETF protocols (due to IPR concerns) is a travesty, and hopefully one we can clear up.
> 
> --
> Tony Arcieri
> _______________________________________________
> secdir mailing list
> secdir@ietf.org
> https://www.ietf.org/mailman/listinfo/secdir
> wiki: http://tools.ietf.org/area/sec/trac/wiki/SecDirReview

v2.29.0 | Report a Bug | By Email | System Status