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

Aaron Zauner <> Wed, 21 January 2015 16:59 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B92021A1B1E for <>; Wed, 21 Jan 2015 08:59:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HUXbZcg4uqEN for <>; Wed, 21 Jan 2015 08:59:02 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BBD021A1B10 for <>; Wed, 21 Jan 2015 08:59:01 -0800 (PST)
Received: by with SMTP id bs8so34898054wib.0 for <>; Wed, 21 Jan 2015 08:59:00 -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 :subject:references:in-reply-to:content-type; bh=0rUFvFaAtZj4AAvZzUFxohsFslzWwsE9AVS6GFjuHh4=; b=Mw+/7rmRvq39ZNSRDXLxcTwgmFNgGyb9zGiKKbmTlV+WiYsRkRauIEIGQFmkQ3wmgE 6wRMiTjTkmv4RnK5OnVczk0kWZs026ZrCJsQrM+BuCJE7QHL86xOks0IVLH6dw4Vqndk n3DQrEhS/r6xyh58ONGainRn4Ro5i9L/Z2TM9jYUGvdbGWia/H7iAne8eXsbGvFjixOf mEMbYGj2aHBNRJov8cS8mPdkAmKyne9Na0C7qJnjOLaBnYgYjyz8/Wox2OY7AUG01DjD btEfkLmEYq6niCjiVm07R3nT6kwyRGN0UVfz7qHb4ZNp5hX7lWtvNO5IdWJtUR9ZGxeA sx+A==
X-Gm-Message-State: ALoCoQmrG+FZgsPs1IFHwrLj1w59I+jp+xkSqySmuabOae4EUxsc2CcMbW3xlIMdd40kkkGNHAIs
X-Received: by with SMTP id l6mr58961521wia.26.1421859540473; Wed, 21 Jan 2015 08:59:00 -0800 (PST)
Received: from [] ([]) by with ESMTPSA id gz7sm8004250wib.22.2015. for <> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 21 Jan 2015 08:58:59 -0800 (PST)
Message-ID: <>
Date: Wed, 21 Jan 2015 17:58:57 +0100
From: Aaron Zauner <>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: TLS Mailing List <>
References: <> <> <> <> <> <> <> <> <> <20150121165008.GQ2350@localhost>
In-Reply-To: <20150121165008.GQ2350@localhost>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="------------enigAB2766B570CD8AAAFB620576"
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, 21 Jan 2015 16:59:05 -0000


Salz, Rich wrote:
> We need a cipher cage match.  They call go in, and only a couple come out.

I'm not opposed to that. And am sure OCB would win over e.g. CCM. Also:
I'm not suggesting OCB mode should be MTI. That's up to the people
currently spec'ing TLS 1.3. GCM based ciphersuites seem like a good idea
to be MTI. e.g. CCM do not.

BTW: Amazed to find out that GOST is still in use (and still mandatory
for russian gov./banking?).

Nico Williams wrote:
> On Wed, Jan 21, 2015 at 08:15:45AM -0800, Eric Rescorla wrote:
>> On Wed, Jan 21, 2015 at 7:17 AM, Aaron Zauner <> wrote:
>>> Any comments on the idea of removing the following two ciphersuites from
>>> the draft?
>>>      CipherSuite TLS_DHE_PSK_WITH_AES_128_OCB = {TBD9, TBD9}
>>>      CipherSuite TLS_DHE_PSK_WITH_AES_256_OCB = {TBD10, TBD10}
>>> I don't see how these would be relevant to embedded devices.
> If DHE_PSK is relevant to an embedded device then all cipher+mode
> combinations might be as well.  Obviously OCB wouldn't be required to
> implement, but that's no reason to exclude any one subset of ciphersuits
> using OCB.

Well. No. Not really. Why would an embedded device prefer to do DHE over
ECDHE? ECC operations are sure to be more efficient on embedded
devices/IoT. That's was my reason to ask for removal.

>> If we generally think DHE_PSK is a good idea, is there a specific
>> reason why it wouldn't be a good idea for OCB?
> There isn't.  Embedded devices need not implement the full set of
> suites.


> But really, this is once more about the gross inefficiency (in terms of
> registration as well as number of bytes used on the wire) of cartesian
> explosion ciphersuites.  Can we fix this?

What's your suggestion to fixing this? I totally agree that there are
far too many ciphersuites around, which is somewhat ironical because I
just suggested adding 10-12 more. But I'd really like to see and use OCB
mode over CCM in TLS. This is also the reason I'm trying to get rid of
as many unnecessary (or insecure) ciphersuites as possible for OCB.