Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

Russ Housley <housley@vigilsec.com> Mon, 17 October 2016 16:08 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8331F129892 for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 09:08:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.899
X-Spam-Level:
X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 rkhWaWk345RM for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 09:08:49 -0700 (PDT)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2415712989C for <tls@ietf.org>; Mon, 17 Oct 2016 09:08:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 68522300A9E for <tls@ietf.org>; Mon, 17 Oct 2016 12:08:48 -0400 (EDT)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Ea7yhKkCjLhD for <tls@ietf.org>; Mon, 17 Oct 2016 12:08:46 -0400 (EDT)
Received: from [10.59.2.154] (unknown [195.77.81.228]) by mail.smeinc.net (Postfix) with ESMTPSA id 4DB8A30050E; Mon, 17 Oct 2016 12:08:45 -0400 (EDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_A0EC47A5-5A24-4D2F-9E02-137B4814C70A"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <CADZyTkmU1uadugpsD+_o8zog0DG8s_mzvKN98m19-4-egWp-NA@mail.gmail.com>
Date: Mon, 17 Oct 2016 12:08:42 -0400
Message-Id: <560A7514-572F-4391-9348-40E42DE7DFCC@vigilsec.com>
References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> <CABkgnnVYt_-SwRbO3Jm0ngpOEccL4UNV6wvgZFMco1G9z0uwfw@mail.gmail.com> <D41FA10A.52E40%john.mattsson@ericsson.com> <CABkgnnXKYrop5OA3CNSA6CocJ88esMUM47zcw3g1BJc+LrXXbQ@mail.gmail.com> <CADZyTkmU1uadugpsD+_o8zog0DG8s_mzvKN98m19-4-egWp-NA@mail.gmail.com>
To: Daniel Migault <daniel.migault@ericsson.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dpC7pbpJusDCLmhkexcaao3lFk4>
Cc: IETF TLS <tls@ietf.org>
Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Mon, 17 Oct 2016 16:08:51 -0000

I would like to see these included:

> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x01};
> TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x02};

I am fine with including these as well if someone wants to use them:

> TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x05};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x06};

I do not really see a reason to include the ones with the shorter MAC:

> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD; 0xTBD} {0xD0,0x03};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 = {0xTBD; 0xTBD} {0xD0,0x04};

Russ


On Oct 17, 2016, at 12:03 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:

> Hi, 
> 
> I am not clear what the consensus is for the following points. Is there any consensus for requesting the following ones?
> 
> BR, 
> Daniel
> 
> TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x01};
> TLS_ECDHE_PSK_WITH_AES_256_GCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x02};
> TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256 = {0xTBD; 0xTBD} {0xD0,0x03};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_8_SHA384 = {0xTBD; 0xTBD} {0xD0,0x04};
> TLS_ECDHE_PSK_WITH_AES_128_CCM_SHA256   = {0xTBD; 0xTBD} {0xD0,0x05};
> TLS_ECDHE_PSK_WITH_AES_256_CCM_SHA384   = {0xTBD; 0xTBD} {0xD0,0x06};
> 
> 
> 
> On Sun, Oct 9, 2016 at 7:11 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
> I'm mainly just looking to economize on different configurations.
> 
> On 9 October 2016 at 16:32, John Mattsson <john.mattsson@ericsson.com> wrote:
> > Hi Martin,
> >
> >
> > AES_256_CCM_8 was not in the first versions of the draft but added later
> > after request from IoT people (probably afraid of quantum computers).
> >
> >
> > While I think it makes very much sense to have short tags in wireless
> > radio, I do not know how large need there is for AES-256 in IoT for
> > constrained devices, or how large the need would be to truncate the tag in
> > these cases.
> >
> >
> > My current understanding is that Grover’s algorithm may never be more
> > cost-effective than a cluster of classical computers, and that quantum
> > computers therefore likely do not affect the lifetime of AES-128.
> >
> >
> > I do not have any strong opinions regarding keeping AES_256_CCM_8 or not.
> > We should not give the impression that AES-256 is needed for practical
> > resistance to quantum computers anytime soon, it is however a requirement
> > for use by US government. Agree that AES_128_CCM_8 and AES_256_CCM seems
> > like the best choices in most cases.
> >
> >
> > Cheers,
> > John
> >
> >
> >
> > On 12/08/16 08:29, "TLS on behalf of Martin Thomson" <tls-bounces@ietf.org
> > on behalf of martin.thomson@gmail.com> wrote:
> >
> >>Looking at those emails, I am prompted to wonder if anyone can justify
> >>the existence of a ciphersuite with a double-sized key and half-sized
> >>authentication tag.  RFC 6655 doesn't really explain how that is a
> >>useful thing.
> >>
> >>On 10 August 2016 at 19:33, Nikos Mavrogiannopoulos <nmav@redhat.com>
> >>wrote:
> >>> On Tue, 2016-08-09 at 14:45 -0400, Sean Turner wrote:
> >>>> All,
> >>>>
> >>>> We've received a request for early IANA assignments for the 6 cipher
> >>>> suites listed in https://datatracker.ietf.org/doc/draft-ietf-tls-ecdh
> >>>> e-psk-aead/.  Please respond before August 23rd if you have concerns
> >>>> about early code point assignment for these cipher suites.
> >>>
> >>> I have previously raised an issue [0] on these ciphersuites. The same
> >>> requirement was noted also by Peter Dettman as something special in
> >>> [1]. However, there has been no reaction from the authors (now in CC).
> >>>
> >>> regards,
> >>> Nikos
> >>>
> >>> [0].
> >>>https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ
> >>> [1].
> >>>https://mailarchive.ietf.org/arch/msg/tls/onEkdgH30eZgWs8v5Rp-CUqCHds
> >>>
> >>> _______________________________________________
> >>> TLS mailing list
> >>> TLS@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/tls
> >>
> >>_______________________________________________
> >>TLS mailing list
> >>TLS@ietf.org
> >>https://www.ietf.org/mailman/listinfo/tls
> >
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls