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

Nikos Mavrogiannopoulos <nmav@redhat.com> Thu, 22 January 2015 08:37 UTC

Return-Path: <nmav@redhat.com>
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 4D3F51A03AB for <tls@ietfa.amsl.com>; Thu, 22 Jan 2015 00:37:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.311
X-Spam-Level:
X-Spam-Status: No, score=-6.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_64=0.6, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 LCEbOi5olJHM for <tls@ietfa.amsl.com>; Thu, 22 Jan 2015 00:37:38 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFF61A01D8 for <tls@ietf.org>; Thu, 22 Jan 2015 00:37:38 -0800 (PST)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0M8bbDZ009885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 22 Jan 2015 03:37:37 -0500
Received: from dhcp-2-127.brq.redhat.com (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0M8bZOT019851 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 22 Jan 2015 03:37:36 -0500
Message-ID: <1421915855.2723.52.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: Aaron Zauner <azet@azet.org>
Date: Thu, 22 Jan 2015 09:37:35 +0100
In-Reply-To: <54BFDAD1.6050403@azet.org>
References: <54B5501A.4070402@azet.org> <20150120191819.GA8165@typhoon.azet.org> <20150120193412.GA10140@typhoon.azet.org> <CABkgnnWSNtREGMYoT9nL9WWas5TZGqnW=qEcg9h_WvzMr8U8KQ@mail.gmail.com> <20150120225335.GA871@typhoon.azet.org> <CABkgnnWbFciZD=ja2bD+tZfFnniWWm=5zH5kL1x_UQEa4rbQ8w@mail.gmail.com> <20150121004704.GA15203@typhoon.azet.org> <54BFC326.4010302@azet.org> <CABcZeBMcsr7bnw8UmxesWC5fdiV==ZgfqoTYa-AmBmX6v5mKpw@mail.gmail.com> <20150121165008.GQ2350@localhost> <54BFDAD1.6050403@azet.org>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/it-R34ZYJkTlNsKZNCaLHRSP_1Q>
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: Thu, 22 Jan 2015 08:37:40 -0000

On Wed, 2015-01-21 at 17:58 +0100, Aaron Zauner wrote:

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

It will not. However, there will be no PFS fallback if for some reason
there is some attack on ECDHE that is not applicable on DHE. In any case
I don't find the issue critical. Even if removed it's only 2
ciphersuites saved, and we are nowhere close to believing that the
ciphersuite space is close to an end.

regards,
Nikos