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

Aaron Zauner <azet@azet.org> Wed, 14 January 2015 16:52 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 7CC9D1A90D4 for <tls@ietfa.amsl.com>; Wed, 14 Jan 2015 08:52:07 -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 VcUl2xbpvfOT for <tls@ietfa.amsl.com>; Wed, 14 Jan 2015 08:52:02 -0800 (PST)
Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270051A90E9 for <tls@ietf.org>; Wed, 14 Jan 2015 08:52:02 -0800 (PST)
Received: by mail-wi0-f177.google.com with SMTP id l15so12254612wiw.4 for <tls@ietf.org>; Wed, 14 Jan 2015 08:52:00 -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 :cc:subject:references:in-reply-to:content-type; bh=KBrwMS/HyvpRMI2Xm6tVOk0h+0zCMZSRiNexK53NpRE=; b=e712JA/Pf07nhz7GcgXNRDfys6U/fORrEOY0CbksnJ9eaT9kCIgXw0OBEZibNLj4OD tTLyKKdRYyQxfgDp3wb1l6xD6Mh0jHlt7dByvNbLnhleRzzAdmhO0lQ7rBlraA6RXYdL BL1/Yh9Y796DnkC8nIk5n28OLjcOm2c8FexX1KwHHcZjPG/O3qNsKiatU1Y5P+StZOwp b8u1zxPK4TaOHnFcXJoHRaGy3dfGjgFHDfcZU/E1GgJlx+elzYnZsQ9AIanqPGtxmVmq sI8bsKND23rYxJSz4jDUYJTC1WAa2seJtrrEEggQW9nLU6GNO1QhUvjdOKVrzojM3gPM yDEg==
X-Gm-Message-State: ALoCoQl6gz8bkmutetmKAY2yug6XHeg3ue7HCE5Cs+aJkNlW+zFCNFq4SDlt3tx1DRS7mTzwtPkE
X-Received: by 10.180.101.131 with SMTP id fg3mr44153590wib.36.1421254320649; Wed, 14 Jan 2015 08:52:00 -0800 (PST)
Received: from [10.60.20.30] ([193.170.94.190]) by mx.google.com with ESMTPSA id q10sm30784096wjx.34.2015.01.14.08.51.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 14 Jan 2015 08:51:59 -0800 (PST)
Message-ID: <54B69EAB.4060904@azet.org>
Date: Wed, 14 Jan 2015 17:51:55 +0100
From: Aaron Zauner <azet@azet.org>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <nmav@redhat.com>
References: <54B5501A.4070402@azet.org> <D0DA96DB.58455%paul@marvell.com> <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org> <54B68A97.3010007@azet.org> <1421250687.2899.2.camel@redhat.com> <54B69514.9000508@azet.org> <1421253834.21577.7.camel@redhat.com>
In-Reply-To: <1421253834.21577.7.camel@redhat.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="------------enig1C25391296086EEAD1A4CD1A"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/sQt4WCcO1i3SfdlRykOqGRcKqnM>
Cc: TLS Mailing List <tls@ietf.org>
Subject: Re: [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: Wed, 14 Jan 2015 16:52:07 -0000


Nikos Mavrogiannopoulos wrote:
> I don't see why OCB has to be tied to TLS 1.3. The last time such move
> was made with having GCM/AEAD restricted to TLS 1.2, it proved quite
> wrong (in the sense that not doing it would have avoided the majority of
> the problems we saw the last years). TLS 1.3 is a draft document to be
> deployed in 2-3 years after published (in the best case scenario). There
> is no reason the existing implementations cannot take advantage of OCB,
> if ever defined. 
> 
I'm trying to find a compromise between having to pollute the TLS
ciphersuite registry with tons of ciphersuites (as has been pointed out
to me is not desirable) and OCB being deployable in the real world for
implementors that would like to use it (and are allowed to w.r.t. it's
licensing).

If the majority is for a) dropping the idea b) having OCB in >= TLS 1.2,
and thus tons of ciphersuites or c) for TLS 1.3 applicable ciphersuites
only - I'll draft it that way.

Having this discussion beforehand will also save time on editing the
draft all the time, in case on is to be written.

I'm open for any suggestions and some consensus on the topic would be nice.

Aaron