Re: [TLS] Inclusion of OCB mode in TLS 1.3

Aaron Zauner <> Wed, 14 January 2015 14:47 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 503981B2CD9 for <>; Wed, 14 Jan 2015 06:47:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GnnEL7Cz-9oU for <>; Wed, 14 Jan 2015 06:47:11 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C8231B2CCF for <>; Wed, 14 Jan 2015 06:46:57 -0800 (PST)
Received: by with SMTP id m14so9226184wev.0 for <>; Wed, 14 Jan 2015 06:46:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=2RqCdqjbGCPjNCfYg6yN/SiBZzFVC5j1hZYdsyget3k=; b=cQQq+46IZ5i5phMHsYF32GWw6YylP1yBGAdoTc2c6Rr+uPggYiSRIPNSTnbSpBk/Y7 VdEIq1XwWgJ1O8JwBOm4Os/MpS+zYbL1yiEZPosc8KMAr4bjzK3NSXvxqfLSuE+YY/kp 5o+lbF9fN914P1u7FG0bhdBqwJzVVf02Qb7ZDwhLyI9Yr5VCFuTf6C+k0+37Z0912ojc bSk3u/2DQy6udpDPgdruPj63o3xGrCtL6rAz68cUft9ZyzFMNh90eFt3Fbx5lK2JjwiP lavpjAQLPbeQFZgGpCm25dwIVSsXBhRAGYSAgbU6LF+RspBAPvwVJHN1XnYHf4q6cTHo xbAw==
X-Gm-Message-State: ALoCoQkxEOxOGjBI/5zavOZUc1Fn8DYNiudP0cEvZa+8lM8hl7ckA2/vmF5NR8KkbC9X9L1ccG/Z
X-Received: by with SMTP id m2mr7989551wjx.60.1421246815791; Wed, 14 Jan 2015 06:46:55 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id la10sm30360448wjc.36.2015. (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 06:46:54 -0800 (PST)
Message-ID: <>
Date: Wed, 14 Jan 2015 15:46:50 +0100
From: Aaron Zauner <>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Stephen Farrell <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="------------enig46281C79351D1F6137AA8AF1"
Archived-At: <>
Cc: TLS Mailing List <>
Subject: Re: [TLS] Inclusion of OCB mode in TLS 1.3
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 14 Jan 2015 14:47:15 -0000

Hi Stephen,

Stephen Farrell wrote:
> <no-hats>
> On 13/01/15 18:25, Paul Lambert wrote:
>> This should not stop inclusion of OCB as an optional mode in TLS,
> I don't get why additional options are at all attractive. In
> fact, I think they're ugly.
> TLS has about 327 ciphersuites. That's just stupid. (I'm not
> saying any person is stupid there btw, but we have gotten
> ourselves into a stupid place.)

Yup. Having different naming schemes for different
libraries/implementations beyond that makes it almost impossible to give
good recommendations to end-users (admins, management) as we've noticed
in the project.

> If we have a really better thing, they why not make it MTI? If
> we do not have something sufficiently better then I'd argue to
> exclude as much as possible, and certainly against adding
> anything that is just nice to have.
> I'd even like to make almost all current ciphersuites a MUST NOT
> (or start a new registry) for TLS1.3 and to not add any new
> ciphersuites at all, and just stick with two MTI ciphersuites
> that are as genetically different as possible and cover as many
> implementations (h/w AES or not) as possible.
> So my suggestion is to reduce the ciphersuite field to be
> 2 bits wide in TLS 1.3, with 00 being default, 01 backup, 02
> being "proprietary" and 03 reserved. If either 00 or 01 needs
> to be changed then I'd say rev the TLS version. (I don't care
> if we did s/default/has-AES-hw/ and s/backup/just-sw-crypto/
> that'd also be fine.)
> And yes, I realise that's not likely to get traction, but
> turning 327 into 427 is even dumber when reality shows that
> only a few of 'em are used or needed.

Just as a suggestion, how about a document that does only include
forward-secret cipher-suites that are valid for TLS 1.3? That would
drastically remove the number of OCB ciphersuites that I would have to
add in case of TLS 1.2.

One issue though: as far as I can tell (from the recent RWC presentation
by EKR) there are still going to be three block ciphers in TLS 1.3: AES,
CAMELLIA, ARIA. One could also only define ciphersuites for AES. The
original paper only talks about the merits of OCB mode with AES - so
this would make sense. Since of the other ciphers are -- to some extent
-- based on AES, OCB mode would work perfectly fine with them, but then
again; who really uses them? I certainly agree that ciphersuite
pollution is not the best way to go. But having three different AEAD
block modes to choose from is.

Is this a reasonable proposal?

As for Jake's comment: Personally I fully agree with that, but can see
why the military exception would make it hard for IETF to have this mode
as mandatory to implement. So it'd probably end up as optional. Given
that support for OCB is already present in (some) implementations; this
would, again, make sense.