Re: [Uta] Comment on TLS BCP for alternative algorithm
Kohei Kasamatsu <kasamatsu.kohei@po.ntts.co.jp> Thu, 28 August 2014 08:39 UTC
Return-Path: <kasamatsu.kohei@po.ntts.co.jp>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 770481A04CA for <uta@ietfa.amsl.com>; Thu, 28 Aug 2014 01:39:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.839
X-Spam-Level: *
X-Spam-Status: No, score=1.839 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] 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 vhiuQkUZXZj8 for <uta@ietfa.amsl.com>; Thu, 28 Aug 2014 01:39:06 -0700 (PDT)
Received: from mail12.ics.ntts.co.jp (mail12.ics.ntts.co.jp [210.232.35.65]) by ietfa.amsl.com (Postfix) with ESMTP id 027D01A0478 for <uta@ietf.org>; Thu, 28 Aug 2014 01:39:05 -0700 (PDT)
Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail12.ics.ntts.co.jp (8.14.4/8.14.4/NTTSOFT) with ESMTP id s7S8d4lZ022025; Thu, 28 Aug 2014 17:39:04 +0900 (JST)
Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (8.13.8/NTTSOFT) id s7S8d4BY018396; Thu, 28 Aug 2014 17:39:04 +0900 (JST)
Received: from ccmds32.silk.ntts.co.jp [10.107.0.32] by sadoku34.silk.ntts.co.jp with SMTP id TAA18395; Thu, 28 Aug 2014 17:39:04 +0900
Received: from mail147.silk.ntts.co.jp (ccmds32.silk.ntts.co.jp [127.0.0.1]) by ccmds32.silk.ntts.co.jp (8.14.3/8.14.3) with ESMTP id s7S8d3lB013314; Thu, 28 Aug 2014 17:39:03 +0900
Received: from mail147.silk.ntts.co.jp (localhost.localdomain [127.0.0.1]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with ESMTP id s7S8cwMU008877; Thu, 28 Aug 2014 17:38:58 +0900
Received: from ccmds32 (mail145.silk.ntts.co.jp [10.107.0.145]) by mail147.silk.ntts.co.jp (8.14.5/8.14.5/NTTSOFT) with SMTP id s7S8cwHj008874; Thu, 28 Aug 2014 17:38:58 +0900
Message-ID: <53FEEA59.8080702@po.ntts.co.jp>
Date: Thu, 28 Aug 2014 17:37:45 +0900
From: Kohei Kasamatsu <kasamatsu.kohei@po.ntts.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Leif Johansson <leifj@mnt.se>, uta@ietf.org
References: <53D18A7F.1080703@po.ntts.co.jp> <B07D6809-105A-47CF-BA2B-04874715B97B@vpnc.org> <53E0AFC0.6000107@po.ntts.co.jp> <55179996-EC4C-4F6A-B48B-46EA2D417C54@vpnc.org> <53E87E6C.9030409@po.ntts.co.jp> <53E88285.2020105@gmail.com> <53E88DF9.6020505@mnt.se>
In-Reply-To: <53E88DF9.6020505@mnt.se>
Content-Type: text/plain; charset="ISO-2022-JP"
Content-Transfer-Encoding: 7bit
X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client
X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server
Archived-At: http://mailarchive.ietf.org/arch/msg/uta/fpZBIz48ObEyZL2Z8jZv14_dR-M
Subject: Re: [Uta] Comment on TLS BCP for alternative algorithm
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Aug 2014 08:39:07 -0000
Hi Yaron and Leif, I also need a consensus about adding standby ciphers into TLS-BCP. And I understood that UTA WG focuses on getting a first version of the BCP out as soon as possible. In first, I want to point out it seems that very little interest in the idea of standby cipher that you pointed out is not fact. I heard from David that there are some interests in idea of standby ciphers. My concern is that when vulnerability related to the primitive is found it takes a lot of time to migrate from insecure primitive to secure one. In fact, it is seemed to me that it takes a lot of time to migrate to TLS1.2. (My proposal that TLS-BCP recommends standby ciphers is one of the solutions for a delay of migration.) What do you think about my concern? For example, shall we consider the procedure for review of algorithms in TLS-BCP and update of TLS-BCP in order to deal with the following events? 1. Operations of new algorithms in TLS implementations are so increasing that we cannot ignore it. 2. Vulnerability of TLS is found. Best, Kohei KASAMATSU (2014/08/11 18:33), Leif Johansson wrote: > On 2014-08-11 10:44, Yaron Sheffer wrote: >> Hi Kohei, >> >> Personally I support the idea of alternative (or "standby") ciphers, see >> http://tools.ietf.org/html/draft-mcgrew-standby-cipher-00. However there >> was very little interest in this idea when we brought it up at CFRG. >> >> IMHO for inclusion in the BCP there should be wide consensus about both >> the need for standby ciphers (and there is none, as far as I can tell) >> as well as the individual algorithms. >> > > I think that is a fair assessment. Our focus now should be on getting a > first version of the BCP out as soon as possible. > > Cheers Leif > > _______________________________________________ > Uta mailing list > Uta@ietf.org > https://www.ietf.org/mailman/listinfo/uta >
- [Uta] Comment on TLS BCP for alternative algorithm Kohei Kasamatsu
- Re: [Uta] Comment on TLS BCP for alternative algo… Ralph Holz
- Re: [Uta] Comment on TLS BCP for alternative algo… Kohei Kasamatsu
- Re: [Uta] Comment on TLS BCP for alternative algo… Ralph Holz
- Re: [Uta] Comment on TLS BCP for alternative algo… Aaron Zauner
- Re: [Uta] Comment on TLS BCP for alternative algo… Paul Hoffman
- Re: [Uta] Comment on TLS BCP for alternative algo… Leif Johansson
- Re: [Uta] Comment on TLS BCP for alternative algo… Salz, Rich
- Re: [Uta] Comment on TLS BCP for alternative algo… Kohei Kasamatsu
- Re: [Uta] Comment on TLS BCP for alternative algo… Kohei Kasamatsu
- Re: [Uta] Comment on TLS BCP for alternative algo… Kohei Kasamatsu
- Re: [Uta] Comment on TLS BCP for alternative algo… Paul Hoffman
- Re: [Uta] Comment on TLS BCP for alternative algo… Aaron Zauner
- Re: [Uta] Comment on TLS BCP for alternative algo… Yaron Sheffer
- Re: [Uta] Comment on TLS BCP for alternative algo… Paul Hoffman
- Re: [Uta] Comment on TLS BCP for alternative algo… Leif Johansson
- Re: [Uta] Comment on TLS BCP for alternative algo… Yaron Sheffer
- Re: [Uta] Comment on TLS BCP for alternative algo… Leif Johansson
- Re: [Uta] Comment on TLS BCP for alternative algo… Stephen Farrell
- Re: [Uta] Comment on TLS BCP for alternative algo… Ilari Liusvaara
- Re: [Uta] Comment on TLS BCP for alternative algo… Kohei Kasamatsu
- Re: [Uta] Comment on TLS BCP for alternative algo… Kohei Kasamatsu
- Re: [Uta] Comment on TLS BCP for alternative algo… Yaron Sheffer
- Re: [Uta] Comment on TLS BCP for alternative algo… Leif Johansson
- Re: [Uta] Comment on TLS BCP for alternative algo… Kohei Kasamatsu
- Re: [Uta] Comment on TLS BCP for alternative algo… Stephen Farrell
- Re: [Uta] Comment on TLS BCP for alternative algo… Leif Johansson
- [Uta] On cipher suites with Camellia of TLS-BCP Kohei Kasamatsu
- Re: [Uta] On cipher suites with Camellia of TLS-B… Ralph Holz
- Re: [Uta] On cipher suites with Camellia of TLS-B… Stephen Farrell
- Re: [Uta] On cipher suites with Camellia of TLS-B… Leif Johansson
- Re: [Uta] On cipher suites with Camellia of TLS-B… Nikos Mavrogiannopoulos
- Re: [Uta] On cipher suites with Camellia of TLS-B… Ralph Holz
- Re: [Uta] On cipher suites with Camellia of TLS-B… Aaron Zauner
- Re: [Uta] On cipher suites with Camellia of TLS-B… Nikos Mavrogiannopoulos
- Re: [Uta] On cipher suites with Camellia of TLS-B… Leif Johansson