Subject: Re: OpenSource vs. IETF Standards

From: Alessandro Vesely <[email-masked]>
Date: Fri, 01 Aug 2014 10:21:24 +0200

On Fri 01/Aug/2014 06:02:08 +0200 Brian E Carpenter wrote:
> On 01/08/2014 08:50, manning bill wrote:
> 
>> As you properly have tabled, some of these IETF standards are
>> subject to IPR claims, which the IETF mgmt and its sponsoring
>> organization have prudently recognized.  Publication of such
>> material, encumbered by Intellectual Property Rights, clearly
>> suggests that the IETF standard in question can not, in fact, be
>> represented in open source without violation of IP laws.
>>
>> Codec and Crypto specs tend to be owned.
> 
> If they are published as RFCs the boilerplate will indicate
> rights; but watch out for the change of rules introduced by RFC5378.

Some organizations, e.g. FSF, actively campaign against patents.  OTOH,
most SDOs seem to act as mediators between patent owners and their
clients.  I wonder whether it is at all possible to stand somewhere in
between liberty and industrial support, rather than taking a firm stand
on either side.

Of course, it would be impressive if the IETF proclaimed its stand in
that respect.  RFC 5378 doesn't seem to promise such kind of statement,
and I'm unable to even imagine how on earth consensus could be achieved
on such topic...

Ale

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 1 Aug 2014 11:16:39 +0200

Given I did when I was heavily engaged in IETF spend quite a lot of time on trying to get some common understanding (default rule), but failed, let me jump in and urge people to please be careful with what wording you use.

I see words like Open Source, Patent, IPR-encumbered etc. And even if people where careful with being careful when they say for example "patent" when in fact they are worried about "licensing terms", there are as we know different definitions of "open source".

I think personally what IETF (still) need are default licensing terms for what could be viewed as "an open standard". Which of course is not all RFCs but a subset of them. The terms I think people agree should be such that one can implement whatever the standard requests, in the way it is specified in the standard, without any need for explicit licensing from whoever might hold the rights for the invention. On top of that, it should be possible to get an explicit license if whoever is to implement what is specified in the standard wants one.

Many defensive licensing terms we have seen attached to RFCs do in fact have terms which are very close to something like this, but of course the devil is in the details.

I do though not we will be able to move forward if people for example are really scared and scream about patents, because if nothing else we have trolls out there that will do whatever they can to use whatever weakness the system has.

I do think it is right though to run and scream about licensing terms.

Then open source...I am personally a person that enjoy BSD like licensing that gives complete freedom of doing whatever one wants with some source. I know others have other views. But that is yet another discussion. Which might be what this thread was to be about. :-P

   Patrik

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Aug 2014 10:19:50 -0400

> and I'm unable to even imagine how on earth consensus could be achieved

It all depends on the work you want to do.

Most IETF work does not require the use of encumbered technology
because we have been doing Internet for 40 years now and everything we
do that is new at the TCP layer or below is merely an optimization. We
have been doing Web, email and chat 20 years so the same holds.

So the chance that there is going to be a patent that is blocking is
very small. There is not going to be a patent that allows you to do
TLS or not or allows you to do email or not. So the value of any
patent is limited to the number of bits saved on the wire.

That isn't the case for some of the work done in other SDOs. If you
want to do content protection to allow copyright holders to protect
their IPR then you are going to be dealing with a lot of IPR claims
from patent holders and some of those claims are of the type that you
either pay up or you don't do the work.

So the IETF has done patent deals in the past. We did it for RSA and
DH for example because those were the only ways to do public key
cryptography. It was agree to the patent claims or don't do the work.
But ECC which was merely an optimization did not get anything like the
same treatment and the patent holder's failure to understand that
their IPR simply wasn't anything like as valuable has killed
deployment there until last Tuesday.

I always think that the biggest mistake we made in the Web was not
putting support for an uncompressed audio format in the browser. The
performance would have sucked but doing that would have reduced the
value of the various compression patents to being an optimization of
an existing feature and not the ability to do audio.

---

From: Doug Barton <[email-masked]>
Date: Fri, 01 Aug 2014 09:02:29 -0700

On 08/01/2014 01:21 AM, Alessandro Vesely wrote:
> I wonder whether it is at all possible to stand somewhere in

Some of us call that, "The BSD License." :)

---

From: Jim Gettys <[email-masked]>
Date: Fri, 1 Aug 2014 14:08:55 -0400

> Some of us call that, "The BSD License." :)

​Or "The MIT License" says this person who had something to do with its
drafting... ;-)

The NSA TAO catalog of exploits from the NSA have pushed me much closer to
Stallman (I remain skeptical that you can enforce open code by license
successfully).​

Any binary blob in a software system is a problem,  from the view of
security, from the view of latent bugs (which can be catastrophic at
times), and, most subtlety, make long term support of systems very, very
difficult or impossible, often encouraging insecure systems to remain
deployed *long* after their sell by (or rotten by) date, lacking updates.

See my talk  "(In)Security in Home Embedded Devices"
 http://cyber.law.harvard.edu/events/luncheon/2014/06/gettys

You could strike the word "home" from that talk and it would very likely
apply to most of what is out there today.

Unfortunately, home routers (and related devices such as modems) arrive
woefully out of date and rot in your house thereafter.  This is also true
for most of the other devices you buy for your home network (with a few
exceptions: I've seen pretty regular updates for my Nest thermostats, for
example, but wonder for how many years I'll see them).  As to why, see my
talk.

Also read Bruce Schneier's and Dan Geer's articles linked to from that
abstract; both articles I instigated by presenting them with the material
that
talk covers.  Had Dan's article been available at the time I submitted the
abstract, I would have also highlighted it.

"Friends don't let friends run factory firmware"....
                                             - Jim

---

From: Leif Johansson <[email-masked]>
Date: Fri, 1 Aug 2014 21:32:05 +0200

> 1 aug 2014 kl. 18:02 skrev Doug Barton <[email-masked]>:
> 

+1

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Aug 2014 21:49:29 +0200 (CEST)

> cryptography. It was agree to the patent claims or don't do the work.

Weird.  That's not how I remeber the situation with RSA.  I'm *NOT* aware
of any patent deal of the IETF for RSA.  IIRC, the DH patent expired in
late 1997 and the RSA patent expired in the 2nd half of 2000.
(The RSA patent existed only in a few countries, since the technology
 had been publicly described prior to patent application, excluding it
 from patentability in several jurisdictions).

TLSv1.0 (rfc2246) was published in January 1999 with the "official"
mandatory-to-implement TLS cipher suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

  https://tools.ietf.org/html/rfc2246#section-9

i.e. *NO* RSA, because there was *NO* IETF patent deal about RSA.
Defacto, SSL & TLSv1.0 were pretty much exclusively used with RSA
server certificates from 1995 through today, and several vendors simply
waited until the RSA patent had expired before shipping crypto with
RSA (including SSL/TLS) implementations in their product.

What I remember from back then is more closely described/captured in
Google search results like these:

a Baltimore White Paper, excerpt from page 4:
  ftp://59.152.90.8/Softwere,%20Music%20&%20Others/EBooks/RSA_patent_expiry_developer_white_paper.pdf

  Intellectual property

  The final barrier to using public key cryptography has been a series
  of patents on the basic techniques -- the Diffie-Hellman algorithm,
  the RSA algorithm, the idea of public-key cryptography itself.
  Although patents are a useful way of rewarding inventors for their
  ideas, the RSA patent in particular has been used in ways that make
  it hard to develop good cryptographic software.

  Import

  RSA Security Inc (formerly known as RSA Data Security Inc, or RSADSI),
  which claimed exclusive rights to the exploitation of the patent,
  sells a software toolkit, called BSAFE Crypto-C ("BSAFE" for short),
  which implements many popular cryptographic algorithms. This is the
  only software implementation of the RSA algorithm which they are willing
  to see used in the US.

  Not only has this given them a monopoly of the market for basic
  cryptography in the US; it's made it difficult for software companies
  from other countries to sell to the US. The RSA algorithm is not
  patented outside North America, so developers there have been free
  to develop their own public key cryptography applications.
  But importing them into the US has mean re-engineering them to use
  BSAFE -- essentially, entirely unnecessary effort

  Toolkits: Lock-in

  In both their toolkits and their standards development, RSADSI have
  attempted to develop lock-in to the RSA algorithm. In BSAFE,
  Diffie-Hellman is supported differently from any other public key
  algorithm. BSAFE is deliberately written so that it's impossible
  to store a long-term Diffie-Hellman keypair, or use a Diffie-Hellman
  private key for more than one session. The Diffie-Hellman private key
  in BSAFE is held within an algorithm object, and can't be extracted
  from it; neither can algorithm objects be cloned, so there is simply
  no way of preventing the private key from expiring with the
  algorithm object.

  What are the effects of this? A developer using BSAFE who was tempted
  to implement a non-RSA based PKI would, quite simply, find it impossible.
  There is no straightforward way to publish a Diffie-Hellman public key
  in a database for future use by a correspondent. IETF standards, like
  S/MIME v3, cannot be implemented.

snippet from a length discussion thread:
  https://groups.google.com/forum/#!search/Gamal$20el$20Gamal$20can$20we$20resume$20$3F$3F/sci.crypt/M18NGuXQBP4/VFGbWgYsZJkJ

    RSA[DSI] offered Netscape a deal in which this hungry little startup got
  an unrestricted license to use RSA's BSAFE code, cash-free, in exchange for
  a legendary 1 percent of Netscape. What isn't clear in Mr. Schlafly's
  summary was that that deal merely settled -- on relatively generous
  terms, I think -- what was always a foregone conclusion. D-H was simply
  a non-starter in 1994, according to most informed observers.

    Mr. Shlafly offers a malovalent interpretation of the fact that RSADSI
  preferred to license its BSAFE toolkit -- to Netscape and everyone else
  -- as opposed to allowing OEMs a full patent license to roll their own
  RSApkc (and/or other RSA cryptosystems.) 

or this:
  http://marc.info/?l=openssl-users&m=94383534822859

-Martin

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Aug 2014 22:02:35 +0200 (CEST)

Following up to my own mail:

> late 1997 and the RSA patent expired in the 2nd half of 2000.

I should have read through the end of the Baltimore Whitepaper,
here's more from its last page.

-Martin

Baltimore White Paper, excerpt from page 5:
ftp://59.152.90.8/Softwere,%20Music%20&%20Others/EBooks/RSA_patent_expiry_developer_white_paper.pdf

Standards

To take one well-known example, consider the development of the SSL and TLS 
protocols, which originally used the RSA algorithm. Netscape decided to use 
the RSA algorithm to secure SSL in their browsers for good reasons. It was 
twice as fast as equivalent-strength Diffie-Hellman for decryption, and two 
hundred times as fast for encryption. Using RSA meant that a single algorithm 
could support both authentication (signing/verifying) and confidentiality 
(encryption/decryption).

But this choice, made for good technical reasons, would cause great political 
difficulty in years to come. SSL was a proprietary technology, invented and 
implemented by Netscape. As Netscape became more committed to open Web 
standards, they turned stewardship of SSL over to the Internet Engineering 
Task Force (IETF), the voluntary organization which has defined and managed 
all the fundamental protocols that run the Internet today. One of the IETF's 
core values is to avoid the use of proprietary technology when at all 
possible. TCP, UDP, IP are non-patented and freely available for use, and the 
IETF is careful to ensure that new protocols can be implemented in a 
patent-free way. The presence of the RSA algorithm in SSL (and in S/MIME, the 
secure email protocol, developed by RSADSI in the mid-90s as an alternative 
to PGP and adopted by both Microsoft and Netscape) was a considerable 
headache for the standards bodies. In fact, before 1997 the presence of any 
public key cryptography at all would have been an obstacle, because of the 
Diffie-Hellman patent on the concept of public key cryptography. Once that 
patent expired, though, there was a clear course of action for the IETF. In 
all cryptographic protocols which had used RSA, they mandated Diffie-Hellman 
for encryption and DSA for signing.

There was no other decision that could have been made, given the IETF's 
strict guidelines. But the effect was to sow confusion among developers who 
were committed to supporting the Internet standards work of the IETF. RSA was 
the de-facto standard: it was in all the browsers and all the secure mailers. 
But the standards mandated DSA and Diffie-Hellman. An implementation of TLS 
or S/MIME could be fully compliant with the standard, but unable to talk to 
the browsers that everyone was using.  And RSADSI's patent licensing policy 
and litigiousness meant there was no chance that the IETF could bend the 
rules; if the standards had mandated the RSA algorithm, or even put it on an 
equal footing with the non-patented algorithms, anyone who naively read and 
implemented the standard would end up getting sued.

With the expiry of the RSA patent, the official standard and the de facto 
standard can move back into alignment with each other.

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Aug 2014 22:34:58 +0200 (CEST)

I'm sorry for bothering with yet another (clarifying) followup:

> ftp://59.152.90.8/Softwere,%20Music%20&%20Others/EBooks/RSA_patent_expiry_developer_white_paper.pdf

I just realized that this ftp URL to an IPv4 addr looks somewhat "fishy".

The google search keywords that led me to the above URL of the PDF:
rsa netscape bsafe license rsadsi algorithm end rsa patent

The whole text seems to have originally been published here (as HTML):

http://web.archive.org/web/20010617072207/http://www.baltimore.com/devzone/patentexpiry/whitepaper.html

but www.archive.org does not have the PDF download, only the HTML variant.

-Martin

---

From: joel jaeggli <[email-masked]>
Date: Sun, 03 Aug 2014 12:09:37 -0700

> -------- Original Message --------
> Subject: 	OpenSource vs. IETF Standards
> Date: 	Mon, 28 Jul 2014 15:03:50 -0400
> From: 	Massimiliano Pala <[email-masked]>
> Organization: 	OpenCA Labs
> To: 	[email-masked]
> 
> 
> 
> Dear IETF-ers,
> 
> At the last ietf (90), it was mentioned that extensive discussions about
> the relationship between IETF standards and OpenSource have taken
> place.. and I was wondering if anybody could point me to the archives of
> that thread.

My CO-AD is on a well deserved vacation, however, it think that this is
probably in relations to ops area activities.

So, both the subsequent discussion and your question, seem to elide what
the discussion in the plenary, and in some working groups is really about.

The question at hand, in some working groups (netconf/netmod in
particular) is about development models and the way the the work is
organized. The current way of working that produces a yang model for
example in 3-5 years is at best, way too slow.

When we look at some opensource development models and proto or actuals
standards activities in use elsewhere we see room for improvement. this
involves:

	empowering them through the tooling used for document collaboration.

	focusing on shorter term goals associated with particular documents or
document sets

	not organizing the work around 3 meetings a year.

	not letting waterfall style development of problems/requirements get in
the way of
	work already being done where appropriate.

	pulling in new contributors

some work internal to the ops area to describe this problem which we
workshopped (largely written by Benoit) can be viewed here.

http://nagasaki.bogus.com/joelja/IETF-still-relevant-OPS-chairs.pdf

> I am asking because I definitely do not agree with what has been said at
> the meeting -

Not sure to what you are refering.

> but I would like to understand the reasons for those
> statements by reading about what was discussed.
> 
> 
> 
>