Re: [Sip] comments on draft-kupwade-sip-iba-00

Eric Rescorla <ekr@networkresonance.com> Thu, 28 February 2008 22:42 UTC

Return-Path: <sip-bounces@ietf.org>
X-Original-To: ietfarch-sip-archive@core3.amsl.com
Delivered-To: ietfarch-sip-archive@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDE0628C741; Thu, 28 Feb 2008 14:42:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.364
X-Spam-Level:
X-Spam-Status: No, score=-0.364 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_ORG=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zyjq0i54R2Ub; Thu, 28 Feb 2008 14:42:22 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 418D028C397; Thu, 28 Feb 2008 14:42:19 -0800 (PST)
X-Original-To: sip@core3.amsl.com
Delivered-To: sip@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94A9F3A67B3 for <sip@core3.amsl.com>; Thu, 28 Feb 2008 14:42:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pR4ATZgtq3YP for <sip@core3.amsl.com>; Thu, 28 Feb 2008 14:42:17 -0800 (PST)
Received: from romeo.rtfm.com (unknown [74.95.2.173]) by core3.amsl.com (Postfix) with ESMTP id C2A1328C1D8 for <sip@ietf.org>; Thu, 28 Feb 2008 14:42:17 -0800 (PST)
Received: from romeo.rtfm.com (localhost.rtfm.com [127.0.0.1]) by romeo.rtfm.com (Postfix) with ESMTP id 8DA8D5081A; Thu, 28 Feb 2008 14:44:02 -0800 (PST)
Date: Thu, 28 Feb 2008 14:44:02 -0800
From: Eric Rescorla <ekr@networkresonance.com>
To: Harsh Kupwade <harsh_smu@yahoo.com>
In-Reply-To: <996813.24317.qm@web65505.mail.ac4.yahoo.com>
References: <20080228201720.18C455081A@romeo.rtfm.com> <996813.24317.qm@web65505.mail.ac4.yahoo.com>
User-Agent: Wanderlust/2.14.0 (Africa) Emacs/21.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Message-Id: <20080228224402.8DA8D5081A@romeo.rtfm.com>
Cc: sip@ietf.org
Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org

At Thu, 28 Feb 2008 14:00:36 -0800 (PST),
Harsh Kupwade wrote:
> Eric Rescorla <ekr@networkresonance.com> wrote:    At Thu, 28 Feb 2008 15:04:21 -0500,
> Hadriel Kaplan wrote:
> 
> > > -----Original Message-----
> > > From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Eric
> > > Rescorla
> > > Sent: Thursday, February 28, 2008 2:14 PM
> > > To: Dean Willis
> > > Cc: sip@ietf.org
> > > Subject: Re: [Sip] comments on draft-kupwade-sip-iba-00
> > >
> > > At Thu, 28 Feb 2008 12:46:21 -0600,
> > > Dean Willis wrote:
> > >
> > > Yes, and this is all equally possible with PKI systems. As I
> > > said at the beginning, the only thing that IBS is bringing
> > > to the party here is a smaller credential. As far as I'm
> > > awre, the size of the cert is not the primary reason for lack
> > > of adoption of any of these schemes
> > >
> > > Again, what does IBS bring to the party except compression? [0].
> > 
> > I agree with you in general about IBS (but I like IBE); but it's not
> > just compression that IBE brings. When you receive a PKI cert from
> > an individual, you have to do a verification step that their cert
> > was signed by the CA. Assuming you share the same CA and all,
> > you're still doing a signature validation operation of the
> > individual's cert before you can then go validate what it is they
> > signed, with that user cert. Right? If you share the same KG, you
> > skip that validation step. Although I guess you have to generate
> > the individual's public key, which is probably just as taxing an
> > operation. So maybe it's a wash.
> 
> I can't tell what your concern is? Performance?
> 
> There are a lot of different designs that trade off the
> speed of various operations. In general, at least one
> of the operations (encrypt, decrypt) requires a pairing
> operation, so IB* systems are in aggregate slower than
> comparable non-IB* systems.
>    
>   Elliptic Curve Pairing operation is faster than the usual RSA operation. 
>    
>   The bench mark program in the paring based crypto-library
>   developed by the Dan Boneh’s research group shows how Elliptic
>   curve parings ( Tate pairings) are faster than the usual RSA
>   decryption scheme.
>   - Harsh

Uh, that's not really what's at issue, since (1) RSA isn't really that
fast compared to good EC systems and (2) the RSA decrypt is the
slowest part of RSA. I'm not aware of any IB* system that has superior
aggregate performance to the state of the art EC systems. [0]

Could you please identify the exact IBS system you're talking
about and the performance you believe it has on some system
compared to RSA and ECDH or ECDSA.

-Ekr

[0] I'm assuming you're looking at the upper left hand part
of the table (type-a). This isn't the type of curve people
would usually use for PBC. More like d159 or f, which, you'll
note, are quite a bit slower than type-a. Note, however,
that I've heard that Ben's numbers aren't the fastest going
implementation of PBC, but that doesn't affect the main
point.

_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip