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
>