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

Tony Arcieri <bascule@gmail.com> Sun, 10 March 2019 20:58 UTC

Return-Path: <bascule@gmail.com>
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 EEC59128664 for <secdir@ietfa.amsl.com>; Sun, 10 Mar 2019 13:58:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, HTML_MESSAGE=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 9udZhLBxc2m1 for <secdir@ietfa.amsl.com>; Sun, 10 Mar 2019 13:58:05 -0700 (PDT)
Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (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 1F751127B50 for <secdir@ietf.org>; Sun, 10 Mar 2019 13:58:05 -0700 (PDT)
Received: by mail-ot1-x336.google.com with SMTP id t7so2237269otk.8 for <secdir@ietf.org>; Sun, 10 Mar 2019 13:58:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b/05oVhudrIJR1Bl6fNddF80sKaiBb6hl2/IBVEeirY=; b=aWCLO87OlNYtxDAHqKZRuOHtA2hEwzfS7Up9ZvG+FFLu4FSyQ0STfjO6jMW8wEO89G x6QT1ddgizjobQrWRCtzXPmCPmzpnN1mnLIyd0k1RrfDMD6zlfbEWKoLByVnLimYcir3 oW9dL5veLNH7/wxOkC4BT9guQ62QN8VCGHdFDcPW0MWB32LRVGnzxQT9ebE3cqWz9uDv bdFDunVdBAg1QejJC2B+pdzBKuS2GXGy+IVI+4gbU1FkQ0jbPhUbnK5vg8Hu1HaBnajd DtdbDGjjSgslJc0v7fWlOPUWV0+pZrr7AOdnHFMRuWdOANJ9gkIT5EH75csGsqW2HpxL chpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b/05oVhudrIJR1Bl6fNddF80sKaiBb6hl2/IBVEeirY=; b=JAr7TCUFXrY83S3SPErneY/4k5aJ0Q/0yGy3ZFW0BHolyaHvP0ESE9H+fPWV8esQAs TEdCt//q0X+kw31B6nmzW+lyHGrwkb+Lq/BclxEZhfj/zS8ifyd17ponLxHgM9R/Dxq2 mhU2CLURoTV4VhEvuqp8xrJ3VCiisFnOq2D7IBdbQFZFOcpPdfhBTkrwQV2cPY/zOfQi tcSM5dKPCZA4xPtBcyE75RYgerb0uI6lW03i8qeNjqj/cKnnBpfEjL+npKOsbz97eru/ 8EBG4cDXFpew8BKrghegivs+T4ililkl33F2wceU7AtnLj7D0USPrE8PrEBCCgfgQJAK ysEg==
X-Gm-Message-State: APjAAAWflQwngEhiV6lF0qvIQ6OI9nGBH1rGUHfPGVpeKrYRTMqVcT/S pBqxeZfm73XJIeybzrUOjRDAFDRUS3xYxFv0xc8=
X-Google-Smtp-Source: APXvYqwPjCFKm5apVlEr9f2P4s4h98rmAqKJawxlHIgScHePn2yNH8oA5MV1fj9rhsk8E7UcMO2QrV33K3hRrLfaTC0=
X-Received: by 2002:a9d:5616:: with SMTP id e22mr18834204oti.365.1552251484139; Sun, 10 Mar 2019 13:58:04 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <20190310191026.GF8182@kduck.mit.edu>
From: Tony Arcieri <bascule@gmail.com>
Date: Sun, 10 Mar 2019 13:57:53 -0700
Message-ID: <CAHOTMVJcosEgYV9caWapgyzQfh-g4k5DQry5n42bEfrkJvmdWQ@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: Ted Krovetz <ted@krovetz.net>, CFRG <cfrg@irtf.org>, "RFC ISE (Adrian Farrel)" <rfc-ise@rfc-editor.org>, secdir <secdir@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005076370583c3b665"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/JPGZqr_67zRdZA5PnqsZN0bR9Yw>
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 20:58:07 -0000

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