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

Viktor Dukhovni <> Wed, 14 January 2015 00:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3CDD21ACE0F for <>; Tue, 13 Jan 2015 16:25:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M5XEf-Vjfj38 for <>; Tue, 13 Jan 2015 16:25:39 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 07BC11ACDD3 for <>; Tue, 13 Jan 2015 16:25:39 -0800 (PST)
Received: by (Postfix, from userid 1034) id 0E833282CC8; Wed, 14 Jan 2015 00:25:38 +0000 (UTC)
Date: Wed, 14 Jan 2015 00:25:38 +0000
From: Viktor Dukhovni <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
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 00:25:41 -0000

On Tue, Jan 13, 2015 at 09:34:19PM +0000, Stephen Farrell wrote:

> I don't get why additional options are at all attractive. In
> fact, I think they're ugly.

Yes, except that OCB might well have been the most attractive AEAD
mode to implement, were it not for IPR and the history of how we
got here.  On a purely technical basis it appears superior to GCM.

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

It would be nice to get there some day.  However we're still actively
discovering what works:

	* Which EC curves and signature schemes to use

	* Which modes to use

	* Which stream ciphers to use (have we settled on ChaCha20 yet?)

	* Which block ciphers to use (must TLS support CAMELLIA? SEED?)

	* Which hash functions to use (though SHA-2 is holding up well)

Plus of course TLS is used in a rather diverse set of applications
whose needs vary.

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

This would then require per-application TLS "profiles", with
per-application definitions of the two ciphersuites in question.
I don't think that'll work just yet.

We might be able to get away with approximately two choices per
degree of freedom:

    * Two public key systems (RSA and ECDSA and/or EdDSA, drop DSA?).

    * A couple of block ciphers (AES and CAMELLIA, drop SEED, IDEA, RC2, ...?).

    * Two key lengths 128 and 256.

    * One or two stream ciphers (ChaCha20 and ???).

    * A couple of AEAD variants (GCM, Poly1305, OCB?)


Which should still be a smaller set of possible outcomes that the
current ~327, but I think we are sadly far from having just two be