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

"Blumenthal, Uri - 0553 - MITLL" <uri@ll.mit.edu> Tue, 22 September 2015 15:37 UTC

Return-Path: <prvs=670795a046=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 B9BA71ACD41 for <cfrg@ietfa.amsl.com>; Tue, 22 Sep 2015 08:37:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mSL95NsiHKpq for <cfrg@ietfa.amsl.com>; Tue, 22 Sep 2015 08:37:09 -0700 (PDT)
Received: from mx1.ll.mit.edu (MX1.LL.MIT.EDU [129.55.12.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0511ACD42 for <cfrg@irtf.org>; Tue, 22 Sep 2015 08:37:09 -0700 (PDT)
Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx1.ll.mit.edu (unknown) with ESMTP id t8MFb46c002369; Tue, 22 Sep 2015 11:37:04 -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: AQHQ9QwDvlduoNAqLkGv0P4PD+Aijp5I0QkAgAAMzgCAABQ3gA==
Date: Tue, 22 Sep 2015 15:37:03 +0000
Message-ID: <20150922153711.17789008.58219.24410@ll.mit.edu>
References: <D225E3A1.1F4FD%uri@ll.mit.edu> <87k2rj4gjw.fsf@latte.josefsson.org> <9A043F3CF02CD34C8E74AC1594475C73F4B1953C@uxcn10-5.UoA.auckland.ac.nz> <8737y651nh.fsf@latte.josefsson.org> <20150922133900.17789008.7169.24365@ll.mit.edu> <20150922162450.52515bbc@latte.josefsson.org>
In-Reply-To: <20150922162450.52515bbc@latte.josefsson.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="===============1521423003=="
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-22_05:2015-09-22,2015-09-22,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-1509220218
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/rkDu2BPiXoD8EDQPvhCd2lxySqQ>
Cc: CFRG <cfrg@irtf.org>, Peter Gutmann <pgut001@cs.auckland.ac.nz>
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: Tue, 22 Sep 2015 15:37:11 -0000

My $0.02 worth of answer:

1. By "free use" I meant "free use within the TLS framework and implementation" (or within IETF protocols framework), so a generic crypto library maintainer could feel the need to make sure that patent holder's permission covers the *library itself* as well,  which - as you pointed out - cannot ‎know who uses its API and for what purposes. I agree that for something that is (mainly) used in the TLS protocol itself (rather than being a general-purpose crypto library usable for TLS among other things, like e.g. Botan) there shouldn't need to ask permission.

2. If the algorithm is not usable outside of (e.g.) TLS - then this whole discussion/issue is moot: if the patent holder said "free use in TLS" and it isn't suitable for anything else - just implement it. If the algorithm is usable elsewhere, but the permission covers only (e.g.) TLS - then a generic library maintainer would ask the patent holder for permission to include the algorithm. And if permission is not granted - it should be an argument for the TLS WG to avoid that algorithm.

3. NDA must not be involved. The patent holder either says "Yes our permission to use this algorithm in IETF standards such as TLS extends to your library that implements it", or not (and anything other than straight "yes" counts as "no") - in which case the algorithm is a no-go (of course). 
(I've seen enough FUD in related issues, especially with some algorithms and some patent holders. :)

It all isn't great, I know.

Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
  Original Message  
From: Simon Josefsson‎
Sent: Tuesday, September 22, 2015 10:25
To: Blumenthal, Uri - 0553 - MITLL
Cc: Peter Gutmann; CFRG
Subject: Re: New Version Notification for draft-whyte-select-pkc-qsh-00.txt
‎
> Simon, I'm not sure I understand. 
> 
> For the sake of the argument, assume company A allows free use of
> their patented algorithm B in TLS. ‎OpenSSL project notifies A that
> it's about to include B in the codebase. In which case A can answer
> "Go ahead", "No way", or "Pay us". In the two latter cases, the
> algorithm simply won't end up included. Ideally, this exchange
> happens before the TLS WG standardizes/accepts B. 

This raises several questions:

1) What do you mean by "free use"? If it is really free use, there is
no need to ask for permission, and there is no way for the company to
say "no way" or "pay us".
‎
2) If the "in TLS" part is a crucial part of there patent licensing, it
may matter how the integration works. Is the algorithm usable without
TLS or not?

3) In practice having this dialogue is difficult. NDAs is usually a
non-starter for a FOSS project. For example, I tried having a
discussion with RedPhone for the TLS Authorization extension that I
implemented in GnuTLS and that fell apart. Often the company benefits
from having projects being in the dark about whether they are allowed
to use the technology or not (FUD tactic).

/Simon

> 
> Sent from my BlackBerry 10 smartphone on the
> Verizon Wireless 4G LTE network. Original Message 
> From: Simon Josefsson
> Sent: Tuesday, September 22, 2015 03:55
> To: Peter Gutmann
> Cc: Blumenthal, Uri - 0553 - MITLL; CFRG
> Subject: Re: New Version Notification for
> draft-whyte-select-pkc-qsh-00.txt
> 
> Peter Gutmann <pgut001@cs.auckland.ac.nz> writes:
> 
> > Simon Josefsson <simon@josefsson.org> writes:
> >
> >>That is not consistent with my view or experience. If you publish a
> >>library that implements a patented algorithm, and your library is
> >>popular enough to attract attention from the patent holder, you
> >>will have a hard time.
> >
> > Only if you're using someone else's patented algorithm
> > inappropriately. My code had IDEA (for PGP 2.x support) in it, I
> > included Ascom Tech's patent statement in the docs as they
> > requested giving the T&C under which it could be used, and sent
> > them a courtesy note about it. I got a reply from them that said
> > something like "thanks for the note, and all the best with your
> > work". So provided you play by the rules (whether you agree with
> > them or not), things should be OK.
> 
> They realized they couldn't charge you, and that having IDEA in your
> product would allow them to charge others. Others ended up paying for
> IDEA, or refused to work with it (like libgcrypt). This is what I
> refer to by "having a hard time".
> 
> Going back to the original topic: I don't think what you are
> describing is a workable approach for a general patent rule when
> considering which algorithms to consider here.
> 
> /Simon
>