Re: [IPsec] New criteria draft

Yaron Sheffer <yaronf@checkpoint.com> Thu, 11 March 2010 18:59 UTC

Return-Path: <yaronf@checkpoint.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 292253A6988 for <ipsec@core3.amsl.com>; Thu, 11 Mar 2010 10:59:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.475
X-Spam-Level:
X-Spam-Status: No, score=-3.475 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 wdhZD1Kw3e0j for <ipsec@core3.amsl.com>; Thu, 11 Mar 2010 10:58:59 -0800 (PST)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by core3.amsl.com (Postfix) with ESMTP id EEF683A6ACD for <ipsec@ietf.org>; Thu, 11 Mar 2010 10:33:13 -0800 (PST)
Received: from il-ex01.ad.checkpoint.com (il-ex01.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id o2BIXHsd012411; Thu, 11 Mar 2010 20:33:17 +0200 (IST)
X-CheckPoint: {4B9935D1-0-1B201DC2-2FFFF}
Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 11 Mar 2010 20:33:38 +0200
From: Yaron Sheffer <yaronf@checkpoint.com>
To: Dan Harkins <dharkins@lounge.org>
Date: Thu, 11 Mar 2010 20:33:37 +0200
Thread-Topic: [IPsec] New criteria draft
Thread-Index: AcrBQVVtzbfQ9T6/TJSE5bqhCbzq/AABYQyc
Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C89C@il-ex01.ad.checkpoint.com>
References: <7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C889@il-ex01.ad.checkpoint.com>, <39fb97c8009b2eefcbed01b9f77d9cea.squirrel@www.trepanning.net>
In-Reply-To: <39fb97c8009b2eefcbed01b9f77d9cea.squirrel@www.trepanning.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_7F9A6D26EB51614FBF9F81C0DA4CFEC801BE05E0C89Cilex01adche_"
MIME-Version: 1.0
Cc: "ipsec@ietf.org" <ipsec@ietf.org>
Subject: Re: [IPsec] New criteria draft
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: Thu, 11 Mar 2010 18:59:01 -0000

Hi Dan,



thanks for your comments. Please see my response inline.



   Yaron

________________________________________
From: Dan Harkins [dharkins@lounge.org]
Sent: Thursday, March 11, 2010 7:35 PM
To: Yaron Sheffer
Cc: ipsec@ietf.org
Subject: Re: [IPsec] New criteria draft

  Hi Yaron,

  One comment you might've missed was this:

     Also, the table in section 5 should include IEEE 802.11s under the
     "standards" column for SPSK. And the phrase "may or may not infringe
     on existing patents" applies to all candidates, and frankly, to
     almost everything in the IETF. It is a meaningless phrase and it
     would be better to just remove it from the "IPR" column.

That comment also received a "+1" from another commenter on the list.

<YS>

In fact, I did not miss these two comments. I did not list 802.11s because I prefer to list only standards that are primarily vetted by the security community. Hence the "Securty Standards" column in -01.



Regarding the second comment, while in principle I agree that it could apply to anything done at the IETF, unfortunately in our case it does apply. It applies because of two reasons:

- Spurious (whether legitimate or not, I cannot say) IPR statements made agaist SRP.

- The sheer amount of patents in this area that must be analysed to ensure, with a high level of confidence, that you will not be sued for implementing X.



And I disagree with your statement below, "It is not our job to prove that no patents apply to some technology." As individuals, and for many of us, as employees, it is our job to ensure ourselves that we (or our company) will not be getting into legal/financial trouble by making this choice.



And I don't think this is "proving a negative". We can think of a process to get this level of confidence. But just shouting at one another will not get us there. Please see http://tools.ietf.org/html/draft-mcgrew-fundamental-ecc-01 for a creative approach to deal with IPR in another, somewhat related, contentious area.



Having said that, if you read -01 carefully, you will see that I'd rather focus our energies on discussing the security aspects rather than endlessly discussing IPR.



And by the way, which protocol are you referring to in the last paragraph?

</YS>

  Also, I think this takes us down a particularly bad path:

   o  Ideally, the proposal should be unencumbered.  This property is
      very difficult to prove, and each WG participant should attempt to
      review the applicable patents and determine whether in fact they
      do not apply to the proposal.  Remember that independently
      invented technology might still infringe a patent.
   o  In some cases the IPR situation is clear: if the protocol relies
      on a specific patent, and believed to not require the use of any
      other.  This is mostly useful if the patent's licensing terms
      (whether free or not) are known, and/or the patent's expiration
      date is near.

  So while we start off our criteria grandly with "it should be
unencumbered" we immediately then dismiss that by saying we can't forget
it might still be patented by some unknown patent. So "ideally" is just
one of those states we cannot achieve because even if it's "unencumbered"
it might not be. So that's off, what's next? If the IPR situation is clear,
it relies on a specific patent and the patent's expiration date is near.
So I guess we're just supposed to stop here, right?

  It is unwise for anyone to say what another IP holder will say
with respect to his or her IPR. And there might be a patent that covers
everything done in the IETF, we just don't know and it's not our job to
prove a negative. So I think it would be very unfortunate if the discussion
of candidates jumped down this rathole. We would have "I'm not a lawyer
but..." followed by a contentious statement and 8 people jumping up to
the queue on the mic to precede their comments with "I'm not a lawyer
but..." and then make other contentious statements.

  I think the IPR content in this draft should be as simple as possible:

    o We live in a litigious world and patents are used as both a club
      and a shield.
    o Patents might or might not exist on every technology we discuss.
    o We should not attempt to prove or disprove whether this or that
      patent might or might not cover some technology.
    o It is not our job to prove that no patents apply to some technology.

  It would be great to choose a technology that does not require any
licensing but as we've seen in the last couple days even the most
straightforward and innocent of protocols that we choose to adopt can
still be encumbered.

  regards,

  Dan.

On Thu, March 11, 2010 1:17 am, Yaron Sheffer wrote:
> Hi,
>
> Based on mailing list comments, I have posted a revision of
> draft-sheffer-ipsecme-pake-criteria here:
> http://trac.tools.ietf.org/wg/ipsecme/trac/wiki/TempDocs. I will submit it
> as usual when the submission window reopens.
>
> Thanks,
>      Yaron
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>



Scanned by Check Point Total Security Gateway.