[TLS] Inclusion of OCB mode in TLS 1.3

Aaron Zauner <azet@azet.org> Tue, 13 January 2015 17:04 UTC

Return-Path: <azet@azet.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374E91A901E for <tls@ietfa.amsl.com>; Tue, 13 Jan 2015 09:04:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 Sv_hNPge9GJA for <tls@ietfa.amsl.com>; Tue, 13 Jan 2015 09:04:32 -0800 (PST)
Received: from mail-wg0-f45.google.com (mail-wg0-f45.google.com [74.125.82.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 844391A1EEF for <tls@ietf.org>; Tue, 13 Jan 2015 09:04:32 -0800 (PST)
Received: by mail-wg0-f45.google.com with SMTP id y19so4192041wgg.4 for <tls@ietf.org>; Tue, 13 Jan 2015 09:04:31 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=iYklQPqrB62bTc6/HJYeq1gFtOoPrMNxn8Tth+D3Nx8=; b=HrHzOEA80G5gQTeHEYWOeTDlZDAkJeVC3Cn6dK6tmytbrgxBdWrho+1oQhX9wYP/ET G+Y3lzaS9GSw4CpM3UtsZ2q50msTphDKG4Xdsykc9al9JFNk22tI0Oq2u7lFYhfyZa/4 hpMCm8XNK1/fnuFvjSDFuqPFMkn+kcZYEHRSCBoWq9bmZMd6BKCkQqjBoxAldK6bz+6M KXYYs0nrQ+Dtv49VCER/lhCdXQAgoMcKXiKV6u7wrqK1KjDBjpGAGlwq1w4LqGp0JWBT 0Nni1+ZHCXdvfaWl0KuCuUg6eQwUVLMSFWiy4T18P8tZbssbUNO3rrPOplJuwzdAJAhB W67Q==
X-Gm-Message-State: ALoCoQkwp8mLWxXO2FLgMqQ6KcMUE62M73zcdblP6IHZzIt4+y6aZLcFvuA9E9Zw2Bphz3ef0bf/
X-Received: by 10.180.72.199 with SMTP id f7mr576927wiv.58.1421168671015; Tue, 13 Jan 2015 09:04:31 -0800 (PST)
Received: from [192.168.23.139] (chello084112076043.34.11.vie.surfer.at. [84.112.76.43]) by mx.google.com with ESMTPSA id dp8sm15012111wib.20.2015.01.13.09.04.29 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 13 Jan 2015 09:04:30 -0800 (PST)
Message-ID: <54B5501A.4070402@azet.org>
Date: Tue, 13 Jan 2015 18:04:26 +0100
From: Aaron Zauner <azet@azet.org>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: TLS Mailing List <tls@ietf.org>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="------------enig50A0D33EBD0ACAF1223F5C65"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/qZiGzQiePuURYTZrd3bHUFKrtD4>
Subject: [TLS] Inclusion of OCB mode in TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Jan 2015 17:04:35 -0000

Hi TLS-WG,

Over the last couple of days I've again looked into OCB, read the
original paper as well as quite some literature on it, patents, CFRG
discussion et cetera.

OCB looks like an elegant and parallel mode for inclusion in TLS.
I've searched through recent TLS-WG discussion, OCB has been
mentioned in passing as has EAX(2). When first looking into that my
main concerns were:

   * IPR/patents: the authors have granted access to OSI licensed
     software as well as to commercial (non military!) software for
     all use [0] [1].

   * IETF applicability: an informational RFC has been written by
     the original author of OCB mode, reviewed and accepted by CFRG
     and published by IESG in May 2014 [RFC7253].

   * Software implementations: OCB mode is available in various
     cryptographic libraries:

      - OpenSSL's 1.0.2 branch

(https://github.com/openssl/openssl/blob/0c1bd7f03fcd1cc8256f89f4962d91b78432c74a/crypto/modes/ocb128.c)

      - Bouncy Castle
        (https://www.bouncycastle.org/specifications.html)

      - Botan

(https://github.com/randombit/botan/tree/74522169a907715d4d41b3680f20b6f866733de7/src/lib/modes/aead/ocb)

      - Soon; dynamic languages linking to these libraries.

      - I might have left out a few, where I couldn't find a
        clear indication that they intend to support OCB mode.

From looking at [RFC7253] it would make sense to have;
`AEAD_AES_128_OCB_TAGLEN64` and `AEAD_AES_256_OCB_TAGLEN128` in TL3
1.3 ciphersuites.

Now I'm a bit clueless as to how new AEAD modes are supposed to be
added to TLS 1.3. In the past there have been various documents
extending TLS ciphersuites by a certain block cipher/AEAD mode:
[RFC5288] [RFC6367] [RFC6655] [RFC5528] [RFC6209]. There is a
general document for an interface for AEAD modes [RFC5116] which the
authors have used for their informational RFC [RFC7253]. I'd like to
ask for a bit of guidance how this can be done more efficiently for
all ciphers that will end up in TLS 1.3. Having a seperate RFC for
every cipher and thus ciphersuite seems a bit confusing. Is this the
intended approach still?

I'd be willing to author such a document or make the necessary
changes to the TLS 1.3 draft in order to get OCB mode into TLS 1.3.
Currently we're limited to GCM (with known issues on mobile
plattforms) and CCM (CBC-MAC, which is one of the reasons the OCB
authors started work on this mode, because it's more elegant and
efficient).


Recent developments regarding OCB mode are documented here:
http://web.cs.ucdavis.edu/~rogaway/ocb/news/

All and any input appreciated.

Thanks,
Aaron

[0] https://www.ietf.org/mail-archive/web/cfrg/current/msg03301.html
[1] http://web.cs.ucdavis.edu/~rogaway/ocb/ocb-faq.htm#patent:phil