Subject: Re: [TLS] Document Action: 'TLS Elliptic Curve Cipher Suites with

From: "tom.petch" <[email-masked]>
Date: Mon, 30 Jun 2008 19:21:58 +0200

----- Original Message ----- 
From: "Martin Rex" <[email-masked]>
To: "Dean Anderson" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>
Sent: Monday, June 30, 2008 7:01 PM
Subject: Re: [TLS] Document Action: 'TLS Elliptic Curve Cipher Suites with

> Dean,
> 
> I really do not understand why you're making such a big fuzz.
> 
> Discussing IPR issues burns a whole lot of resources in a useless fashion.

Martin

I am thinking that perhaps you have grasped why Dean is making such a big fuzz.

Tom Petch

> The last time we debated IPR issues on this list was about TLS-SRP,
> and while discussing it, we did _ALSO_ talk about the certicom
> patent claims for ECC and their effect on the ECC ciphersuites.
> 
> For TLS, the standards-track ciphersuites are not affected by 
> Certicoms ECC patent claims.  So there is simply no necessity to
> _discuss_ alternatives in the informational RFC on the ECC ciphersuites.
> 
> The existence of these claims could have been indicated
> more prominently.  Maybe we're just to accustomed to patent claims
> (like the expired DH and RSA patents) for TLS that we only worry
> and focus on IPR issues for the standards track.  A lot of people
> are sick of beating the dead horse -- there are parties interested
> in implementing the technology, and we let them publish a spec
> as informational, on which they can base their interoperable
> implementations.
> 
> 
> See e.g. Peter Gutmann's message:
> 
> : From: [email-masked] (Peter Gutmann)
> : To: [email-masked], [email-masked]
> : Subject: Re: [TLS] Straw poll on TLS SRP status
> : In-Reply-To: <[email-masked]>
> : Message-Id: <[email-masked]>
> : Date: Tue, 05 Jun 2007 20:48:02 +1200
> :
> : [...]
> :
> : It's irrelevant what the software has built in, if no-one's using it
> : then it may as well not be there (that's just a paraphrasing of the
> : prime directive of security UI, "If the user doesn't understand your
> : feature, it doesn't exist").  Certicom issued their "royalty-free
> : license" for ECC in TLS last year some time, and I still haven't seen
> : any use of it by anyone outside the USG and its dependents as part of
> : the Suite B mandate.  Although I can't speak for vendors like Microsoft,
> : I would imagine their only reason for putting it in IE was for
> : that particular market (I've talked to non-MS developers and they've
> : told me that's the sole reason why they added it to their product).
> :
> : (Again, I don't know about the IKE situation).
> :
> : Anyway, this is all going off on a bit of a tangent...
> 
> 
> The most irritating for me (last time I checked) about the Certicom
> license was that it was NOT royalty-free.  Instead, it used a business
> model that did not charge for the implementation (of the communication
> protocols), but instead it wants a premium for every EC certificate
> issued by a CA.
> 
> What happens if a customer / end user living in a country where the
> Certicom patent is valid purchases certificates from a CA which
> operates in a country where the Certicom patents do not exist
> (or are invalid/inapplicable, e.g. to Software)?
> 
> Who will Certicom sue in such a situation (if any)?  The end user?
> The provider of the protocol implementation?
> 
> Waiting for the patents to expire is IMHO a workable approach for
> the ECC ciphersuites.  Waiting worked for us with the DH and RSA patents,
> when there weren't any alternatives, let alone a working installed base.
> 
> 
> -Martin
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Richard M Stallman <[email-masked]>
Date: Tue, 01 Jul 2008 16:37:23 -0400

They claim that JPAKE is unencumbered, so TLS-JPAKE should be  
    unencumbered, no?  Well, we don't really know - it's hard to prove a  
    negative. If we go ahead and specify and implement TLS-JPAKE, somebody  
    might come out of the woodwork and claim we are infringing.  All the  
    discussion on the TLS or IESG mailing lists is not going to change that.

All that is true, but doesn't the IETF have ways to press the big
companies to say whether they have any patents over a proposed
standard?

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Jul 2008 14:01:09 -0700

>companies to say whether they have any patents over a proposed

No.

--Paul Hoffman, Director
--VPN Consortium

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 02 Jul 2008 00:15:17 +0200

>>companies to say whether they have any patents over a proposed

That is a rather terse answer.

The IETF has RFC 3979, in particular section 6.1, which says that IETF
participants must file a disclosure when he knows about his own patents
in IETF contributions, and is encouraged to file a disclosure for
patents owned by others.  That count as a "yes" answer to this question
for me.

To clarify, the IETF has RFC 3979 as the instrument to pressure big
companies to file these notifications, through the individuals who
participate in the IETF.

Could you elaborate on why you believe "no" is the correct answer?

/Simon

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 1 Jul 2008 15:33:41 -0700 (PDT)

Hi Simon,

  "no" is the correct answer for J-PAKE because the the creators of
the protocol said, "Since this protocol is the result of an academic
research project, we didn’t — and have no intention to — patent it."
But that says nothing about anyone else's claims.

  So if, hypothetically, one of the creators of J-PAKE wrote an I-D
specifying its use in TLS then he would not have to file anything on
that contribution since he knows he did not patent it. But "Patent
Trolls R Us (tm)" could believe it held a patent on this technique and
I am not aware of anything the IETF could do to compel them to disclose
their patent since no employee of "Patent Trolls R Us (tm)" took part
in the authorship of the I-D.

  So, I think "no" is the correct answer.

  Dan.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 1 Jul 2008 15:56:12 -0700

>That is a rather terse answer.

Good catch.

>Could you elaborate on why you believe "no" is the correct answer?

Richard said "ways to press", and I assumed that he meant what he 
said. I also assumed that he had read BCP 79. Nothing in BCP 79 
allows the IETF to press on someone who doesn't abide by it. BCP 79 
tells you how to comply with the IETF procedures of you want to. We 
want everyone to want to comply; we know that some companies don't.

The fact that two or three people want to bring this discussion up on 
as many IETF mailing lists as possible as often as possible doesn't 
change the truth.

--Paul Hoffman, Director
--VPN Consortium

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 1 Jul 2008 20:51:28 -0400

On Wed, 02 Jul 2008 00:15:17 +0200
Simon Josefsson <[email-masked]> wrote:

> participants must file a disclosure when he knows about his own
> patents in IETF contributions, and is encouraged to file a disclosure
> for patents owned by others.  That count as a "yes" answer to this
> question for me.
> 
Simon, 3979 only constrains players who choose to participate in the
IETF.  If they do not participate -- worse yet, if they choose not to
participate with the intention of using submarine patents -- there's
nothing the IETF can do.  In fact, I'm not convinced that even
conceptually there's anything the IETF could do against
non-participants, since no license is needed to implement an IETF
protocol.  How could there be, even in theory, if the RFCs are to
remain open and freely redistributable?  I don't think an
implementation would count as a derivative work under copyright law.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Yoav Nir <[email-masked]>
Date: Wed, 2 Jul 2008 10:27:13 +0300

On Jul 2, 2008, at 3:51 AM, Steven M. Bellovin wrote:

<snip>
> 		--Steve Bellovin, http://www.cs.columbia.edu/~smb

It's worse than that. There's no "IETF police" to come after  
violators, or enforce section 7 of 3979. If some individual fails to  
disclose, she will not be barred from participating in IETF  
discussions, or from posting new drafts.  If a company fails to  
disclose, definitely no action will be taken against its employees.   
The worst they can expect is an angry post to the mailing list by Dean  
Anderson.

Yoav

---

From: Simon Josefsson <[email-masked]>
Date: Wed, 02 Jul 2008 10:07:52 +0200

"Steven M. Bellovin" <[email-masked]> writes:

> nothing the IETF can do.

That's a valid point.  Still, I would claim that most big companies
actively working in this area do participate in the IETF.  It is
certainly true for the case with ECC and Certicom.

> In fact, I'm not convinced that even conceptually there's anything the
> IETF could do against non-participants, since no license is needed to
> implement an IETF protocol.  How could there be, even in theory, if
> the RFCs are to remain open and freely redistributable?  I don't think
> an implementation would count as a derivative work under copyright
> law.

I don't see how this discussion is about copyright, it is a patent
disclosure question.

I believe the IETF has appropriate rules around this today through BCP
79.  The rules in there have been an effective instrument to get both
big and small companies to file patent disclosures several times, in my
experience.  If Paul Hoffman argues that the instrument is not effective
enough, that is more subjective, but my point is that the rules in BCP
79 can and have been used to press big companies to file patent
disclosures.

/Simon

---

From: Richard M Stallman <[email-masked]>
Date: Wed, 02 Jul 2008 13:35:01 -0400

>patents owned by others.  That count as a "yes" answer to this question

That sounds like exactly the sort of thing I was thinking of.

Not all companies participate in the IETF, but I'd expect that
many do, especially large ones that are concerned about Internet
standards.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Wed, 2 Jul 2008 17:48:41 -0400

On Wed, 02 Jul 2008 10:07:52 +0200
Simon Josefsson <[email-masked]> wrote:

> >> The IETF has RFC 3979, in particular section 6.1, which says that
> >> IETF participants must file a disclosure when he knows about his
> >> own patents in IETF contributions, and is encouraged to file a
> >> disclosure for patents owned by others.  That count as a "yes"
> >> answer to this question for me.
> >> 
> > IETF.  If they do not participate -- worse yet, if they choose not
> > to participate with the intention of using submarine patents --
> > there's nothing the IETF can do.
> 

Sure.  The question is how to coerce companies that don't participate
into doing so.
> 
> > In fact, I'm not convinced that even conceptually there's anything
> > the IETF could do against non-participants, since no license is
> > needed to implement an IETF protocol.  How could there be, even in
> > theory, if the RFCs are to remain open and freely redistributable?
> > I don't think an implementation would count as a derivative work
> > under copyright law.
> 

Sorry, I wasn't clear.  I was groping for an analog to the GPL copyleft.
In essence, the GPL says "if you don't play by our rules, you can't use
this code".  But I don't see a way for the IETF to say "if you don't
tell us about your patents, you can't implement our standards".
> big and small companies to file patent disclosures several times, in
> my experience.  If Paul Hoffman argues that the instrument is not
> effective enough, that is more subjective, but my point is that the
> rules in BCP 79 can and have been used to press big companies to file
> patent disclosures.
> 
Yup.  I think we're in violent agreement.

---

From: Richard M Stallman <[email-masked]>
Date: Thu, 03 Jul 2008 06:28:02 -0400

If this is true, does it indicate that the IETF needs to take a stronger
stand in enforcing its own rules?
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 3 Jul 2008 07:31:06 -0400

On Thu, 03 Jul 2008 06:28:02 -0400
Richard M Stallman <[email-masked]> wrote:

>     violators, or enforce section 7 of 3979. If some individual fails
> to disclose, she will not be barred from participating in IETF  
> If this is true, does it indicate that the IETF needs to take a
> stronger stand in enforcing its own rules?

Based on the precedents in the Dell and Rambus cases, it was felt that
government enforcement (in the US) would suffice.  Besides, the IETF
has little recourse of its own on late discoveries; "destandardizing"
something that others are implementing isn't very practical in many
cases.

---

From: Martin Rex <[email-masked]>
Date: Thu, 3 Jul 2008 16:17:16 +0200 (MEST)

> stand in enforcing its own rules?

Keep in mind that there is no formal membership in the IETF,
and every participant participates as an individual.  Most of the time
there are employers/companies sponsoring the IETF working group or
meeting participation, but that does not automatically make participants
representatives for their sponsors (or affiliates).

There is no obligation that engineers participating the IETF know all
or any of the patents of their sponsors/affiliates.

The patents one ought to disclose (when touched) are those that one
already holds or one (or one's team) is working on, i.e. the obvious
submarine patents.

-Martin

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Thu, 3 Jul 2008 10:26:42 -0400

On Thu, 3 Jul 2008 16:17:16 +0200 (MEST)
Martin Rex <[email-masked]> wrote:

> >     violators, or enforce section 7 of 3979. If some individual
> > fails to disclose, she will not be barred from participating in
> > IETF discussions, or from posting new drafts.  If a company fails
> > to disclose, definitely no action will be taken against its
> > employees.   
> > 
> meeting participation, but that does not automatically make
> participants representatives for their sponsors (or affiliates).
> 
 
The wording in RFC 3979 is "Any Contributor who reasonably and
personally knows of IPR".  I think that that covers your description.

---

From: Richard M Stallman <[email-masked]>
Date: Fri, 04 Jul 2008 04:11:38 -0400

Based on the precedents in the Dell and Rambus cases, it was felt that
    government enforcement (in the US) would suffice.

Maybe so -- what enforcement does the government do?
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Richard M Stallman <[email-masked]>
Date: Fri, 04 Jul 2008 04:11:42 -0400

This seems like a weakness in the system.
Perhaps it should be changed so that the companies have to participate
officially and are covered by this policy.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Fri, 4 Jul 2008 09:54:57 -0400

On Fri, 04 Jul 2008 04:11:38 -0400
Richard M Stallman <[email-masked]> wrote:

>     Based on the precedents in the Dell and Rambus cases, it was felt
> that government enforcement (in the US) would suffice.
> 

Enjoined enforcement of the patent to implement the standard:
http://www.ftc.gov/opa/1995/11/dell.shtm
http://www.abanet.org/antitrust/committees/intell_property/june21.html
(I seem to recall that in the Rambus case, the government eventually
lost, but I don't remember the details or the reasoning.)

---

From: Richard M Stallman <[email-masked]>
Date: Sat, 05 Jul 2008 02:38:13 -0400

I don't think we can count on US anti-trust law very much nowadays.

---

From: Dean Anderson <[email-masked]>
Date: Sun, 6 Jul 2008 18:39:23 -0400 (EDT)

On Tue, 1 Jul 2008, Paul Hoffman wrote:

> allows the IETF to press on someone who doesn't abide by it. 

Your assertion that BCP 79 is "optional" isn't so. As demonstrated with
TLS-Authz, an RFC may be rescinded for failing to follow RFC3979.

> BCP 79 tells you how to comply with the IETF procedures of you want
> to. We want everyone to want to comply; we know that some companies
> don't.

What companies?   What RFCs?

> as many IETF mailing lists as possible as often as possible doesn't 

Those IETF WG chairs and A.D.s should follow the IETF policies, and
ensure that IETF policies are followed. If the IETF managers will not
follow the IETF rules, they must be removed.

	--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: Dean Anderson <[email-masked]>
Date: Sun, 6 Jul 2008 18:45:10 -0400 (EDT)

> disclose, definitely no action will be taken against its employees.   

Uhh, as Sam Hartman demonstrated with TLS-Authz, the IESG are the "IETF
police".

Also, Bellovin has previously made false statements about RFC3979
applying to IETF Standards at all.  
http://www.av8.net/IETF-watch/People/StevenBellovin/index.html 
The cited information may color Bellovin's statements, here.

> The worst they can expect is an angry post to the mailing list by Dean  

Gee, I hope its worse than that. ;-)

---

From: Dean Anderson <[email-masked]>
Date: Sun, 6 Jul 2008 19:06:05 -0400 (EDT)

> Sure.  The question is how to coerce companies that don't participate

We don't need to coerce non-participants to be reasonably effective.  
We just need to make sure that participants comply with RFC3979.

There are only two cases the IETF can fix:

  1. The IETF partipicant directly has an undisclosed patent.

  2. A non-participant has a patent that an IETF participant knows of,
but doesn't disclose. (e.g. Housley/Brown and TLS-Authz)

Both these cases are handled by rescinding the RFC for failure to follow
RFC3979. And of course, these bad participants are discredited in future
IETF activities---The web is a wonderful thing for a implementing a
certain level of accountability.

IETF Standards are only created by participants.  Quite obviously,
non-participants do not create IETF standards. Big company-participants
are strongly motivated not to implement technology that someone else has
patented---At least, not without factoring the license cost into the
business plan.  Those big participants therefore help make sure the
other participants are honest, and that patent disclosures are made on a 
timely basis.

The case where a non-participant has a patent that no IETF participant
knows about is still a problem, but these are truly submarine patents
that NO ONE can avoid. Except of course, by changing the patent law.

The case where a participant knows of a patent, and willfully misleads
the IETF about the patent status [with or without a profit motive] is
just a subset of (2) above.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sun, 6 Jul 2008 19:15:46 -0400 (EDT)

> lost, but I don't remember the details or the reasoning.)

There is a more recent case where deception of a standards body (the
ITU) was "aggravated litigation abuse".  If there is an interest in the
actual judgement, I'll see if I can get a copy to put online.  Here is a 
reference to WSJ article on the case:

http://www.ietf.org/mail-archive/web/ipr-wg/current/msg05089.html

Judge Rules Against Qualcomm
In Patent Fight With Broadcom
By KEVIN KINGSBURY
August 7, 2007 8:37 a.m.

A federal judge ruled that two Qualcomm Inc. patents related to video
transmission technology can't be enforced because the company
deliberately concealed the patents from a standards-setting group.

The judge, which charged Qualcomm engaged in "aggravated litigation
abuse," ruled Monday that Qualcomm waived its rights to enforce the
patents, related to the H.264 video compression standard used in some
high definition products, because of its conduct. 

The court also decided Qualcomm committed misconduct by failing to
produce thousands of documents related to the case until after the
January trial concluded. In addition, the firm was ordered to pay the
legal fees of Broadcom Corp., which was the defendant in the case.

Qualcomm sued in October 2005, alleging its rival violated video
transmission patents. A jury found Broadcom didn't violate the patents
and that Qualcomm misled the standard setting body, called the Joint
Video Team.

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Sun, 6 Jul 2008 21:34:25 -0400

On Sat, 05 Jul 2008 02:38:13 -0400
Richard M Stallman <[email-masked]> wrote:

>     (I seem to recall that in the Rambus case, the government
> eventually lost, but I don't remember the details or the reasoning.)
> 
The EU hasn't slacked off on enforcement...

---

From: Yoav Nir <[email-masked]>
Date: Mon, 7 Jul 2008 09:27:10 +0300

> Uhh, as Sam Hartman demonstrated with TLS-Authz, the IESG are the  

And again, suppose I manage to get draft-nir-tls-eap to IETF last call  
as a "proposed standard", make no disclosure, and then somebody (you?)  
find out that to implement this standard, you need to use "stateful  
inspection", for which my company holds a patent.

What would you suggest the "IETF police" do?  Just knocking the  
standard down to Informational is nice, but what else?  What sanctions  
would you suggest be taken against me?  Against Check Point?  RFC 3979  
does not authorize them to do anything.

This may sound bad, but do you really want to set up a "court of the  
IETF" to depose witnesses and make determinations as to intent?  I  
don't think we really want to go there, and we really don't want to  
create a new category of IPR where companies and individuals that  
violate IETF policy are somehow prohibited from implementing RFCs.

So yes, I believe that an angry post from you (and an Informational  
designation for the RFC) is the worst we can do to violators.

---

From: Dean Anderson <[email-masked]>
Date: Tue, 8 Jul 2008 21:50:29 -0400 (EDT)

> does not authorize them to do anything.

No one is entitled to an informational designation, either.  Failure to 
comply with RFC3979 is cause to remove the RFC designation. There are 
several consequences for failure to comply with RFC3979 at present.

In the TLS-Authz case, the IETF moniker was removed entirely.  So just
by that move by the IESG in the TLS-Authz case, Brown's company must now
remove the IETF RFC labeling on its product literature and future
marketing plans.  Furthermore, their protocol is now proprietary rather
than standardized. Some people don't want to use proprietary protocols.
Those two things seem (to me) to be significant RFC3979-related
consequences. If those consequences aren't sufficient to motivate
RFC3979 compliance, then I'd advocate stronger measures.

But, the problem we seem to have at present is the failure to uniformly
impose the current consequences of RFC3979 non-compliance.

> violate IETF policy are somehow prohibited from implementing RFCs.

One can't prohibit anyone from implementing RFC's.  But the IETF does
control the contents and approval of RFCs.

> designation for the RFC) is the worst we can do to violators.

They are not entitled to Informational designation, either.  

BTW, there is also another consequence imposed on their reputation for
the failure to disclose the patents to a standards body.

		--Dean