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

Stephen Farrell <> Tue, 13 January 2015 21:34 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id C3CFD1B29A5 for <>; Tue, 13 Jan 2015 13:34:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id olTectYV-xYl for <>; Tue, 13 Jan 2015 13:34:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1C20E1AD481 for <>; Tue, 13 Jan 2015 13:34:22 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id D91A8BE97; Tue, 13 Jan 2015 21:34:20 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id aH_dgakQfHNA; Tue, 13 Jan 2015 21:34:19 +0000 (GMT)
Received: from [] (unknown []) by (Postfix) with ESMTPSA id 9D990BE79; Tue, 13 Jan 2015 21:34:19 +0000 (GMT)
Message-ID: <>
Date: Tue, 13 Jan 2015 21:34:19 +0000
From: Stephen Farrell <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Paul Lambert <>, Aaron Zauner <>, TLS Mailing List <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
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: Tue, 13 Jan 2015 21:34:24 -0000


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

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.


With a random hat: the OCB RFC is an IRTF informational document
and had CFRG consensus for publication. Using that in a standards
track spec would require TLS WG consensus, and then IETF consensus.
So there's no magic, just the usual IPR processing that each
participant has to do for themselves. I'd be pretty confident in
a bet that the odd encumbrance of OCB will be a hard barrier to
overcome, but who knows.