Re: [Cfrg] New Version Notification for draft-whyte-select-pkc-qsh-00.txt

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Mon, 21 September 2015 21:03 UTC

Return-Path: <prvs=6706177ae9=uri@ll.mit.edu>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66DEE1A9025 for <cfrg@ietfa.amsl.com>; Mon, 21 Sep 2015 14:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.208
X-Spam-Level:
X-Spam-Status: No, score=-4.208 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01, UNPARSEABLE_RELAY=0.001] autolearn=ham
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 9GzLi0-45KBi for <cfrg@ietfa.amsl.com>; Mon, 21 Sep 2015 14:03:11 -0700 (PDT)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3A6C81A88CA for <cfrg@irtf.org>; Mon, 21 Sep 2015 14:03:10 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t8LL37Nq018503; Mon, 21 Sep 2015 17:03:07 -0400
From: "Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu>
To: Simon Josefsson <simon@josefsson.org>
Thread-Topic: New Version Notification for draft-whyte-select-pkc-qsh-00.txt
Thread-Index: AQHQ9LDpvlduoNAqLkGv0P4PD+Aijg==
Date: Mon, 21 Sep 2015 21:03:06 +0000
Message-ID: <D225E3A1.1F4FD%uri@ll.mit.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.4.150722
x-originating-ip: [172.25.177.187]
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha256"; boundary="B_3525699780_1209746"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.14.151, 1.0.33, 0.0.0000 definitions=2015-09-21_07:2015-09-21,2015-09-21,1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1508030000 definitions=main-1509210291
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/RmY0dAJ324DnBx2Vfwx_SGeT3Dg>
Cc: CFRG <cfrg@irtf.org>
Subject: Re: [Cfrg] New Version Notification for draft-whyte-select-pkc-qsh-00.txt
X-BeenThere: cfrg@mail.ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.mail.ietf.org>
List-Unsubscribe: <https://mail.ietf.org/mailman/options/cfrg>, <mailto:cfrg-request@mail.ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@mail.ietf.org>
List-Help: <mailto:cfrg-request@mail.ietf.org?subject=help>
List-Subscribe: <https://mail.ietf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@mail.ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Sep 2015 21:03:13 -0000

On 9/21/15, 15:06 , "Simon Josefsson" <simon@josefsson.org> wrote:

>"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> writes:
>>In my 2+ decades of IETF/IRTF experience, the choice has been to stay
>>away
>> from patented non-free algorithms, period. Thus an acceptable candidate
>> algorithm must be FPARF (Free or Patented and Royalty-Free for use in
>>IETF
>> protocols :).
>
>I believe we have seen evidence that even the qualifier "for use in IETF
>protocols" is too limiting.

Maybe. 

I’d say that “free for use in IETF protocols” is the absolute minimum
required for acceptance (or even consideration). But still an acceptable
minimum - which is a whole lot better than “Reasonable and
Non-Discriminatory" licensing fee.


>Many crypto libraries cannot know for what
>purpose their APIs will be used for, so limiting the ability to use an
>algorithm for "an IETF protocol" is in practice a non-starter for
>deployment.

There’s a big difference between a library and a protocol. Not to mention
that IETF traditionally does not deal with either API or libraries.

A library may include whatever algorithm the authors/maintainers want to -
the legal issues usually fall on the lap of the user, unless the library
is a commercial product, in which case it’s a whole different ballgame. So
including a ton of algorithms in a library regardless of their patent
status is probably fine - nobody forces a commercial user of that library
to invoke what's “forbidden” instead of what’s “permitted”.  Besides, I
seldom see a library deployed by itself (especially where it could matter
- where the “license police” would come to look for your “license") -
usually it’s included as a part of a product, an application or such. In
which case there (again, usually) is a way to tell the whole thing “use
SHA256, and don’t use MD4 even if it happens to be included in the
library”. If not - I suggest deploying a product that is better designed
and implemented. :-)

A protocol is something that IETF defines, and requires those who claim
conformance to actually implement the algorithms included in that
definition. Specifying an algorithm here subjects both developer (who may
want to sell the conformant product) and user (who unsurprisingly may want
to use this conformant product) to potential legal licensing issues. Which
I personally find undesirable and inexcusable.
 

So, a library is something outside of IETF scope (or interest), and can
contain anything. A protocol is something “blessed” by IETF, and it better
not contain algorithms that require licensing fees in any shape or form
(yes I’m aware of exceptions, and want to see their number drop, not
increase).


>>P.S. I concur with Stephen: "anyone spending time here on developing or
>> reviewing proposals that involve encumbered crypto algorithms is simply
>> wasting that time."
>
>+1

:-)