Re: [Cfrg] I updated 3 drafts related to a FSU KeyEX

KATO Akihiro <kato.akihiro@po.ntts.co.jp> Thu, 28 April 2016 10:18 UTC

Return-Path: <kato.akihiro@po.ntts.co.jp>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBEDE12D620 for <cfrg@ietfa.amsl.com>; Thu, 28 Apr 2016 03:18:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level:
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.996, SPF_PASS=-0.001] 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 DgTn_Gn4rMrj for <cfrg@ietfa.amsl.com>; Thu, 28 Apr 2016 03:18:18 -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 57C5D12D614 for <cfrg@irtf.org>; Thu, 28 Apr 2016 03:18:18 -0700 (PDT)
Received: from sadoku34.silk.ntts.co.jp (sadoku34 [10.7.18.34]) by mail12.ics.ntts.co.jp (unknown) with ESMTP id u3SAIEtu005903; Thu, 28 Apr 2016 19:18:14 +0900 (JST)
Received: (from root@localhost) by sadoku34.silk.ntts.co.jp (unknown) id u3SAIERA016895; Thu, 28 Apr 2016 19:18:14 +0900 (JST)
Received: from unknown [10.107.0.33] by sadoku34.silk.ntts.co.jp with SMTP id VAA16894; Thu, 28 Apr 2016 19:18:14 +0900
Received: from mail137.silk.ntts.co.jp (ccmds33.silk.ntts.co.jp [127.0.0.1]) by ccmds33.silk.ntts.co.jp (unknown) with ESMTP id u3SAIEoQ021286; Thu, 28 Apr 2016 19:18:14 +0900
Received: from mail137.silk.ntts.co.jp (localhost [127.0.0.1]) by mail137.silk.ntts.co.jp (unknown) with ESMTP id u3SAIDro018524; Thu, 28 Apr 2016 19:18:13 +0900
Received: from ccmds33 ([10.107.0.135]) by mail137.silk.ntts.co.jp (unknown) with SMTP id u3SAIDBo018520; Thu, 28 Apr 2016 19:18:13 +0900
References: <57208A04.4070804@po.ntts.co.jp> <7a3f5420-db18-496b-af32-e490bf6d0d80@akr.io> <CAEseHRqYNGhGaA+8HhUFDNxLc2WU=5GJf+om52RRuWwtEHUhmg@mail.gmail.com> <5721D74E.3010407@cs.tcd.ie> <5721DED5.8090608@po.ntts.co.jp> <5721E08D.7060905@cs.tcd.ie>
From: KATO Akihiro <kato.akihiro@po.ntts.co.jp>
Message-ID: <5721E349.6010100@po.ntts.co.jp>
Date: Thu, 28 Apr 2016 19:17:45 +0900
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2
MIME-Version: 1.0
In-Reply-To: <5721E08D.7060905@cs.tcd.ie>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-CC-Mail-RelayStamp: CC-Mail-V4.3-Client
X-CC-Mail-RelayStamp: CC-Mail-V5.2.1-Client-Relayed
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Michael Scott <mike.scott@miracl.com>, "cfrg@irtf.org" <cfrg@irtf.org>
X-TM-AS-MML: No
X-CC-Mail-RelayStamp: CC-Mail-V4.3-Server
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/_g4HiLAHmHBgfi1PB0xTHfKtGYc>
Subject: Re: [Cfrg] I updated 3 drafts related to a FSU KeyEX
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Apr 2016 10:18:20 -0000

Hi Stephen,

Slide 4 shows generic case on IBE scheme. After "FSU Key Exchange 
Protocol" slide shows FSU key exchange specific. We made the FSU protocol 
that care about the protection of the session key very much.

Regards.

On 2016/04/28 19:06, Stephen Farrell wrote:
>
>
> On 28/04/16 10:58, KATO Akihiro wrote:
>> Hi Stephen,
>>
>> At FSU case, the KGC cannot get session key.
>>
>> Look the page 7 and 8 of
>> https://www.ietf.org/proceedings/94/slides/slides-94-cfrg-0.pdf . The
>> session key encrypted ephemeral public key. If the KGC have all static
>> secret key, that cannot see session key and plain text.
>>
>> There is no key escrow on FSU key exchange.
>
> Eh? Doesn't slide 4 show that the KGC can fake anyone since
> it generates their secret keys? That's close enough to mandatory
> key escrow for me though sure, perhaps a better term for the
> KGC rules-them-all would have been better:-)
>
> S.
>
>>
>> Regards.
>>
>> On 2016/04/28 18:26, Stephen Farrell wrote:
>>>
>>> Hi Mike,
>>>
>>> On 28/04/16 09:35, Michael Scott wrote:
>>>> Maybe the more accurate phrase "n uniquely attractive targets" where
>>>> n=2,3,4... doesn't carry quite the same punch!
>>>
>>> I'm sorry, but for me, it does have exactly the same
>>> punch. If there are key generators, they can collude
>>> or be coerced. Or even more likely, in a realistic
>>> commercial Internet-scale deployment, it's quite likely
>>> all of them (even if operated by different entities)
>>> may be running on one or two mega-hosting platform,
>>> so there may well be only one thing to break into
>>> even if it looks like N things.
>>>
>>>   From my POV, the mandatory key escrow aspect of IBE
>>> is basically fatal for all but possibly some small
>>> set of niche applications.
>>>
>>> Cheers,
>>> S.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Cfrg mailing list
>>> Cfrg@irtf.org
>>> https://www.irtf.org/mailman/listinfo/cfrg
>>>
>>
>>
>>
>