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

Aaron Zauner <azet@azet.org> Tue, 20 January 2015 18:02 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 68B451B2B04 for <tls@ietfa.amsl.com>; Tue, 20 Jan 2015 10:02:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.099
X-Spam-Level:
X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GUARANTEED_100_PERCENT=2.699, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no
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 cbGj9jsJdSLE for <tls@ietfa.amsl.com>; Tue, 20 Jan 2015 10:02:58 -0800 (PST)
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4192E1B2B05 for <tls@ietf.org>; Tue, 20 Jan 2015 10:02:58 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id l15so16907810wiw.0 for <tls@ietf.org>; Tue, 20 Jan 2015 10:02:57 -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 :subject:references:in-reply-to:content-type; bh=t7RwwpXlgbsaPNaG1fU2pGbg10jJ4/lG5K9Ewa6A+4I=; b=DEO+EsLV5BcGuPntU8i9YYh16qeSS3EymhyjaRU1I4cJi9ihqn56oeQD53D+F66Rdy qqDBxk+MxbXbMMQ/aZ3/ldx4s9OqbsUcEt9EXWcIOUD6VjMm2Hhed5FnLb829AMysffW lVsKhVp+h3z2NP9RPJkWu5lWXwzojRYf81wB7y72KXByiqhxA//fgrsNqk3x+7KkN6J1 H3Iy+LPlZrxX1A+B5BwFC5Zlj9vq65i7GeTi7iryCc9OdHq4L3EaFWZLm/Q9i/tUPVdE N0ZNnhIWsCvwmv6sbP/DLE/dQHkv+c982w2iq0eE1zVWfLLTiYLz8rKhWuUiYY3J7rba I44A==
X-Gm-Message-State: ALoCoQn2Y6okJjCXdEsEHtDUi/OiN40WSaWOdlwy3iIWxpjF/uP4LCedvn1pZ2UGG6IHFl6bek6R
X-Received: by 10.194.24.103 with SMTP id t7mr47889151wjf.15.1421776977058; Tue, 20 Jan 2015 10:02:57 -0800 (PST)
Received: from [10.0.0.142] (chello080108032135.14.11.univie.teleweb.at. [80.108.32.135]) by mx.google.com with ESMTPSA id hn2sm22221754wjc.5.2015.01.20.10.02.55 for <tls@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 20 Jan 2015 10:02:55 -0800 (PST)
Message-ID: <54BE984B.5080002@azet.org>
Date: Tue, 20 Jan 2015 19:02:51 +0100
From: Aaron Zauner <azet@azet.org>
User-Agent: Postbox 3.0.11 (Macintosh/20140602)
MIME-Version: 1.0
To: tls@ietf.org
References: <54B5501A.4070402@azet.org> <D0DA96DB.58455%paul@marvell.com> <54B58F5B.2010704@cs.tcd.ie> <54B6815A.7060102@azet.org> <CABcZeBOkabo85Hv73MM1koeGnVYDJtPHc6uwk5b1BkPDRu=RGg@mail.gmail.com> <54B9352C.70203@azet.org> <20150120170954.GA9731@randombit.net>
In-Reply-To: <20150120170954.GA9731@randombit.net>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="------------enig17C7CE59BB5B0F3AF963BF26"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/iB8epYkMnswJJpA5V9VsMTch9aU>
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: Tue, 20 Jan 2015 18:02:59 -0000


Jack Lloyd wrote:
> 
> OCB mode as defined in RFC 7253 supports nonces of at most 120 bits.
> 
> When used in TLS both GCM and CCM use 96 bit nonces, 32 from key
> exchange and 64 explicit in the message. Given the 2^64 message limit
> (and that any sensible implementation just uses the sequence number
> for the 64 nonce bits included in each message) I don't see why OCB
> should require anything different. A 128 bit nonce isn't increasing
> the security level when it is already 100% guaranteed that the nonce
> will never repeat using just 96.
> 
> Another option would be to avoid explicit nonces entirely and
> following ChaCha20 define the nonce to always be exactly the sequence
> number in network order. This value is known to be unique for protocol
> reasons, and it avoids the wire bytes taken for any explicit value.
> 
Yes, thanks! I figured that out on my own a couple of days ago.
Unfortunately the ID I submitted still has the TAGLEN128 constructs in
it (I forgot to edit this part). So there's probably going to be a -01.
Let's see if my submission gets accepted.

Thanks for your feedback,
Aaron