Re: [IPsec] Some comments to the draft-sheffer-ipsecme-pake-criteria-00.txt

Yaron Sheffer <yaronf.ietf@gmail.com> Sun, 21 March 2010 23:06 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: ipsec@core3.amsl.com
Delivered-To: ipsec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 849AA3A6AD7 for <ipsec@core3.amsl.com>; Sun, 21 Mar 2010 16:06:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.85
X-Spam-Level:
X-Spam-Status: No, score=-0.85 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_SORBS_WEB=0.619]
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 FZPVEmzIv89j for <ipsec@core3.amsl.com>; Sun, 21 Mar 2010 16:06:22 -0700 (PDT)
Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by core3.amsl.com (Postfix) with ESMTP id 5B1723A6956 for <ipsec@ietf.org>; Sun, 21 Mar 2010 16:06:22 -0700 (PDT)
Received: by fg-out-1718.google.com with SMTP id d23so253850fga.13 for <ipsec@ietf.org>; Sun, 21 Mar 2010 16:06:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=YxKU7TieLMiEKAF6Szdpfk0d+622ecVWetg2zpEdH90=; b=soZEo9hkjYhUW3/8D9wW/SmnxsKno8N8yroC2B5aGaZS2MZl9pTvSig5V5kiaA1iJ+ 4BCaouWoutisu5qqDTfxJ5rtFaLK/1O499GHENI7OCxL5uQWjVtQcJzlZewLWqBHwVo8 VJsnp15ePaJNyzGpeaG+ittJrL1KXe7Ssb2sM=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WSBUB834pb7Ci8w5MEoPOWh6MAcJHRusn9ql+mzG04XnUMXfUxch5WXxoKuwauPDyH mjYfExIA7iOHLSBwCOLI5p0hmdfdbPb9GLAv/v7SpPXCVBbTSFbXsCfPYUE/Lp/ufi6j Jc8B9L8dg30lAdSN4It3qVR5RDc4babavmTEo=
Received: by 10.87.1.13 with SMTP id d13mr1245535fgi.29.1269212795759; Sun, 21 Mar 2010 16:06:35 -0700 (PDT)
Received: from [10.0.0.1] (bzq-79-183-28-63.red.bezeqint.net [79.183.28.63]) by mx.google.com with ESMTPS id e3sm4134485fga.24.2010.03.21.16.06.34 (version=SSLv3 cipher=RC4-MD5); Sun, 21 Mar 2010 16:06:35 -0700 (PDT)
Message-ID: <4BA6A68C.5070301@gmail.com>
Date: Mon, 22 Mar 2010 01:06:52 +0200
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
To: Tero Kivinen <kivinen@iki.fi>
References: <19366.39859.336431.204705@fireball.kivinen.iki.fi>
In-Reply-To: <19366.39859.336431.204705@fireball.kivinen.iki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: ipsec@ietf.org, yaronf@checkpoint.com
Subject: Re: [IPsec] Some comments to the draft-sheffer-ipsecme-pake-criteria-00.txt
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 21 Mar 2010 23:06:23 -0000

Hi Tero,

thanks for your comments. Please note that some of them have already 
been addressed in -01, which at the moment is only available on 
http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs.

While not disputing the importance of the engineering criteria, I think 
there's quite a bit of differentiation between the various options on 
security and IPR.

Thanks,
	Yaron

On 22.3.2010 0:20, Tero Kivinen wrote:
> The document should list more of the engineering considerations too in
> addition to the IPR and security. The Security requirement is
> mandatory (how that is show is completely different matter). The IPR
> issue would be nice to have. So I expect we end up looking other
> properties too.
>
> The other considerations section is quite short, and for example I do
> not really care whether the protocol was specified in standards
> document or scientific paper, as in any case we are going to make sure
> our document describes the protocol in a way that alows
> interoperability. Also in some cases the standards document are WAY
> too hard to read to be able to provide interoperability... :-)
>
> Also the second point of having protocol already integrated into IKE
> does not really matter, as the only thing it does is to save us some
> time. If the protocol is good and suitable to be integrated to IKE, I
> do not really think we should leave it out just because someone has
> not yet done the work to actually write the document telling how they
> are integrated. This is the document we are going to be writing here
> anyways. More suitable criteria would be to say it must be something
> that can be easily integrated to the IKE.
>
> I think this section should also include more concrete engineering
> criteria lists, like:
>
>    - Number of round trips
>    - Cost of cryptographic processing
>    - Does it share same cryptograhic blocks already used in IKE (I.e.
>      it would be better to have protocol using MODP+SHA1, than some
>      polynominal shares plush some hash function not used in IKE).
>    - Does it share for example the Diffie-Hellman groups already used
>      in the IKE.
>    - Does it fit to the IKE PSK model (i.e for example it should not
>      rely on trusted third party)
>
> Most likely we are going to be using those engineering criteria to
> select the final protocol, as I do not expect there be that much
> difference (that we can agree on) on other security and IPR.