Subject: Re: [TLS] Document Action: 'TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode' to Informational RFC

From: Dean Anderson <[email-masked]>
Date: Fri, 27 Jun 2008 13:02:28 -0400 (EDT)

On Fri, 27 Jun 2008, Russ Housley wrote:

> >Indeed, it appears to be the case that I was correct on the principle
> >issue:  That the general public is not licenced to use these patents on
> >implementing this draft.
> 
> Right.  This is the reason the document is a candidate for the 
> standards track.  

So, you (Russ--chair of IETF) knew of the patent encumbrances, but
failed to report those facts in an IETF 'IPR' (patent) disclosure?  And
the WG failed to discuss non-patent alternatives in the working group as
required by RFC3979?  This seems to be almost the same issues as with
TLS-Authz.  It is too bad that Sam Hartman is no longer on the IESG,
this time.

> The idea of the informational specification is so that anyone that
> chooses to use this technology can do so in an interoperable way.

The above reason does not seem to be a proper use of the Informational
category.

4.2.2  Informational

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to verification
   that there has been adequate coordination with the standards process
   (see section 4.2.3).

   Specifications that have been prepared outside of the Internet
   community and are not incorporated into the Internet Standards
   Process by any of the provisions of section 10 may be published as
   Informational RFCs, with the permission of the owner and the
   concurrence of the RFC Editor.

Particularly, Section 4.2.3 states

   To ensure that the non-standards track Experimental and Informational
   designations are not misused to circumvent the Internet Standards
   Process, the IESG and the RFC Editor have agreed that the RFC Editor
   will refer to the IESG any document submitted for Experimental or
   Informational publication which, in the opinion of the RFC Editor,
   may be related to work being done, or expected to be done, within the
   IETF community.  The IESG shall review such a referred document
   within a reasonable period of time, and recommend either that it be
   published as originally submitted or referred to the IETF as a
   contribution to the Internet Standards Process.

This document is related to work that has been done within the IETF 
community.

		--Dean

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

_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jun 2008 10:35:09 -0700

At Fri, 27 Jun 2008 13:02:28 -0400 (EDT),
> This document is related to work that has been done within the IETF 

This paragraph only refers to documents which did not go through
the IETF process, as implied by the first sentence of 4.2.3.

   Unless they are the result of IETF Working Group action, documents
   intended to be published with Experimental or Informational status
   should be submitted directly to the RFC Editor.

This document was a TLS WG document, so had already been
coordinated with the IETF community.

-Ekr

---

From: Dean Anderson <[email-masked]>
Date: Fri, 27 Jun 2008 15:56:06 -0400 (EDT)

> the IETF process, as implied by the first sentence of 4.2.3.

Indeed. And this document indeed did not properly follow the IETF
process because it did not disclose IPR in accordance with RFC3979 and
because it did not discuss non-patented alternatives, also in accordance
with RFC3979.  The intent of 4.2.3 is to prevent the circumvention of
the rules, and the IETF rules are not being followed.

> coordinated with the IETF community.

That is precisely the point: it has NOT been properly coordinated with
the internet community: Not all the pertinent facts were disclosed to
the internet community.  

I think the recent events surrounding TLS-Authz at least indicate that
the internet community is keenly interested in facts of patent
encumbrance. These facts were apparently known to IESG managers and
those managers also knew these facts would be important to the
community, but kept the community in the dark, made false 
representations in the draft, and failed to follow IETF policy.

The following paragraph in the 'ecc-new-mac draft is a false
representation:

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

What was claimed to be an innocent mistake in TLS-Authz cannot be
repeated by essentially the same people and still be considered an
innocent mistake.  Twice is not a mistake. Especially after all the fuss
that was made about TLS-Authz.

		--Dean

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 27 Jun 2008 13:11:05 -0700 (PDT)

Dean,

> TLS-Authz.  It is too bad that Sam Hartman is no longer on the IESG,

  I think you are _assuming_ that there are patent encumbrances.
Certicom has patents in ECC but it is not clear that any of them
necessarily apply to this draft. Maybe they do; maybe they don't. But
given that uncertainty there isn't a whole lot to "disclose". Keep in
mind it's hard to prove a negative ("no patents are infringed....") so
the most innocent of I-Ds could, maybe, possibly infringe on some weird
patent somewhere.

  Certicom would, of course, love to license all sorts of things to you
whether you need them or not. They would like everyone to believe that
_any_ use of elliptic curves requires licensing from them but that is
just FUD.

  regards,

  Dan.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jun 2008 13:48:01 -0700

At Fri, 27 Jun 2008 15:56:06 -0400 (EDT),
>    aware will be disclosed, in accordance with Section 6 of BCP 79.

As I've stated already, the relevant IPR claims had already been
disclosed WRT RFC 4492, which this document lists as a normative
reference, as well as explicitly mentioning it in the abstract and
throughout the document, and it just didn't occur to me to file a
separate IPR disclosure listing this document specifically. As I
indicated earlier, I'll leave it to Joe and the ADs to determine
whether such disclosure was required by the process, process
violation, but from a practical perspective, I find it hard to believe
that any significant number of people reviewing the document were
unaware of the IPR situation, given the extensive discussion on this
topic when 4492 was approved.

-Ekr

---

From: Dean Anderson <[email-masked]>
Date: Fri, 27 Jun 2008 17:43:13 -0400 (EDT)

If there is any uncertainty, the the proper course of action is to
disclose the possibility (because its relevant), and then contact the
patent holder. Infringing the patent because you "can't be certain",
doesn't exempt one from the criminal penalties of intentional
infringement, nor the civil penalties of unintentional infringement.
Otherwise, everyone would simply claim that they "weren't certain", and
just ignore patents altogether. Instead, one's obligation is to get
certainty, or get permission.  "Uncertainty" is a frivolous assertion
that also doesn't exempt one from the law or from following RFC3979.

If one wants to dispute a specific patent claim, that's your
business--there are procedures for doing that--I encourage that.  
However, deceiving the internet community into unwitting and unwilling
patent infringement is not a proper (or lawful) method of fighting
patents. But I don't think the authors or IETF managers intend to
secretly fight patents through failure to disclose these patents to the
internet community.  I don't think object of the present
misrepresentation is to get the internet community to unwittingly
infringe, and subsequently be forced to help fight the Certicom patents.

In the TLS-Authz case, at least, the author (Housley) was working
directly for the patent holder.  I don't think Housley intended to (by
the misreprentation of TLS-Authz patent status)  fight the patent by
secretly imposing the burden of disputing the TLS-Authz patent on the
internet community.

Failure to disclose the patents prevents the internet community from
looking for and finding non-infringing alternatives.  Non-infringing
alternatives is by far the cheapest method of fighting patents.  
RFC3979 requires disclosure and requires that a discussion of
non-patented alternatives take place. A submarine-patented standard
obtained through deception is the very worst scenario--except for the
patent holder--who can make a _LOT_ of money on a patented STANDARD that
they own and that everyone else is forced to use or committed to using.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Fri, 27 Jun 2008 18:16:58 -0400 (EDT)

That disclosure specifically states that it doesn't apply to any other
drafts, and this draft isn't listed.  That disclosure doesn't apply to
this document.

The failure to disclose is only the first process violation. I count:

2. No discussion of non-patented alternatives per RFC3979.

3. No consensus on WG, despite relationship to prior and future
standards-track work on TLS.

4. This is a protocol-altering document, altering TLS protocol--it is
not really an Informational document. Nor indeed is RFC4492 properly
categorized as informational.  The informational category is being used
as an end-run around the consensus requirements.

The consequence appears to be another submarine-patented standard. I
don't think this can dismissed as "it just didn't occur to me", after
TLS-Authz.

This also isn't the first time ECC patents have failed to be disclosed
to the IETF.  In 2005, I complained of DNSEXT drafts that were
describing ECC without patent disclosures. In that case, I was told by
Steven Bellovin (then chair of IPR-WG) that RFC3979 wasn't the policy of
the IETF(?!!!?).  The DNSEXT Chair (Austein) told me to drop discussion
about non-patented alternatives (?!!!?).  The IETF Lawyer later refuted
Bellovin's false claims, but the DNSEXT group continues to suppress
discussion on false pretenses.  I'm very concerned about such blatantly
false statements, and concerned by the attempt to dismiss them as mere
mistakes that 'they didn't think of'.

		--Dean

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 27 Jun 2008 16:05:50 -0700

At Fri, 27 Jun 2008 18:16:58 -0400 (EDT),
> 2. No discussion of non-patented alternatives per RFC3979.

It's not clear what that means in the context of cipher suites.
Recall that TLS has a set of mandatory to implement cipher suites
based on RSA. Those *are* the non-patented (well, patent
expired) alternatives. So, the question is really whether IETF
should issue code points to algorithms which may potentially
be encumbered. The practice of the TLS WG has been historically
to do so, but to issue the RFCs as Informational. The S/MIME
WG appears to have done the same.

> standards-track work on TLS.

Again, I'll refer this to Pasi, who ran this WGLC as chair.

> as an end-run around the consensus requirements.

I don't agree with this claim. RFC 4346, which represents the consensus
of the WG, explicitly contemplates that new cipher suite code points
may be defined via Informational documents:

   Section A.5 describes a TLS Cipher Suite Registry to be maintained by
   the IANA, and it defines a number of such cipher suite identifiers.
   Cipher suite values with the first byte in the range 0-191 (decimal)
   inclusive are assigned via RFC 2434 Standards Action.  Values with
   the first byte in the range 192-254 (decimal) are assigned via RFC
   2434 Specification Required.  Values with the first byte 255
   (decimal) are reserved for RFC 2434 Private Use.  The registry will
   initially be populated with the values from Section A.5 of this
   document, [TLSAES], and from Section 3 of [TLSKRB].

Similarly, RFC 4366 explicitly contemplates that new extensions
may be defined by IETF Consensus [RFC 2434]:

   Sections 2.3 and 5 describe a registry of ExtensionType values to be
   maintained by the IANA.  ExtensionType values are to be assigned via
   IETF Consensus as defined in RFC 2434 [IANA].  The initial registry
   corresponds to the definition of "ExtensionType" in Section 2.3.

Informational documents fall squarely within this category.

> don't think this can dismissed as "it just didn't occur to me", after

I don't really understand this paragraph. What are you suggesting?

-Ekr

---

From: Mike <[email-masked]>
Date: Fri, 27 Jun 2008 16:12:42 -0700

This will hopefully be a moot argument as the patentability
of software is being investigated at the moment by the CAFC
and will probably end up being decided by the U.S. Supreme
Court, who has in the past suggested it is not patentable.
See http://endsoftpatents.org/bilski if you are interested.

Mike

---

From: "Dan Harkins" <[email-masked]>
Date: Fri, 27 Jun 2008 16:34:24 -0700 (PDT)

Look, no one is "deceiving the internet community"! And I'm not
encouraging people to knowingly infringe on patents.

  There is no known patent necessary to implement this draft (basically
ECDH). There may be unknown ones but that possibility exists for most
every I-D and one cannot disclose the existence of an unknown patent.

  You're spreading FUD. Please stop.

  Dan.

---

From: Richard M Stallman <[email-masked]>
Date: Sat, 28 Jun 2008 09:20:35 -0400

We hope the Supreme Court will eliminate software patents in the US,
but we cannot take that for granted.  We have to prepare for other
outcomes.
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Dean Anderson <[email-masked]>
Date: Sat, 28 Jun 2008 15:19:05 -0400 (EDT)

> encouraging people to knowingly infringe on patents.

It seems you are indeed advocating knowing infringement.  No patent
lawyer would assert you can knowingly infringe a patent because you
merely claimed to be 'uncertain'.

The deception of the internet community is found in the false
representation in the draft, as I previously quoted. There is no 
disclosure for this draft, even though the authors knew the algorithms 
were patented.

> every I-D and one cannot disclose the existence of an unknown patent.

Your statement above is plainly not true. RFC4492 has a grant of
permission on patents applying to '4492, and this work certainly uses
algorithms derived from the patented ECC algorithms used in '4492.  
There is no credible argument that this work isn't covered by the same
patents as cover '4492.

>   You're spreading FUD. Please stop.

You're spreading baseless, willful ignorance---which doesn't alter any
facts for any infringement claim. Anyone following your advice and uses
this algorithm without permission, infringes.  You have no credible
basis to assert there is no infringement.  Please stop.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Sat, 28 Jun 2008 15:52:39 -0400 (EDT)

I hate to respond to my own message, but this deserves some elaboration.

> basis to assert there is no infringement.  Please stop.

I have discussed this with lawyers. The only time you can use ignorance
as an intentional infringement defense is if you've never conducted a
patent search. Patent lawyers I've talked with advise engineers against
conducting patent searches for this reason. Once you conduct a patent
search, that is enough evidence to show that you knew of the
patent---even if you actually incompetently performed the patent search
and really, truly didn't find the patent due to incompentence.  
Performing a patent search is evidence of knowledge of the patent.  A
self-serving claim that one didn't find what was actually there is not
going to be very credible. In this case, you actually know specifics of
the patents.

Willful ignorance is no defense to intentional infringement--it would
probably be used to support the plaintiff, in fact. Unreasonable
actions--those that vary from what a hypothetical reasonable person
(usually the jury) would do, are usually evidence supporting the
complaint.  Reasonable people respect the law, and are expected to
perform their lawful duties to their fellow citizens, even when they
don't like to.  Indeed, unreasonble actions and a disregard for the law
are the foundation of criminal intent. Just ask Bernie Ebbers.

If you want to argue a patent doesn't apply to your work, you better
have very solid reasons that will stand up in court---Something that
proves that it is reasonably impossible that the patent could apply to
your activities. And you obviously don't have that in this case.

		--Dean

---

From: "Dan Harkins" <[email-masked]>
Date: Sat, 28 Jun 2008 18:30:36 -0700 (PDT)

On Sat, June 28, 2008 12:19 pm, Dean Anderson wrote:
>                                                      There is no

  What's the patent then? And please don't just regurgitate Certicom's
list of patents it asserts are necessary. For you to make such a specific
statement ("the algorithms were patented") you must know which specific
claim in what specific patent applies. So, what is it?

  Dan.

---

From: Dean Anderson <[email-masked]>
Date: Mon, 30 Jun 2008 09:21:52 -0400 (EDT)

> claim in what specific patent applies. So, what is it?

There is already general agreement that the RFC4492 algorithms are
patented, and covered by 26 patents. The algorithms in the current draft
are derived from those in RFC4492.  Derived algorithms are covered by
the patent on the original algorithms.  It is up to you to prove that
these new algorithms are NOT derived from the patented algorithms. Given
the obvious derivation, you can't show the current algorithms to be
original, and thus have no reason to doubt their patent status.

I also note that Rescorla's 2001 TLS book has a paragraph on Elliptic
Curve cipher suites. In the book, Rescorla describes the patent status
as vague and notes the cipher itself may be patented. It seems that 7
years is plenty of time to get clarity. In fact, there seems to be some
greater clarity on the patent status since 2001. But in any case, one
can't pretend to be uncertain forever.  

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Mon, 30 Jun 2008 09:51:59 -0400 (EDT)

And by the way, if you really do want to dispute the patent status,
_you_ have to sit down with all 26 patents, go through every claim, and
show that each claim is either not overlapped in the draft, or invalid
through prior art.

One can't ignore a patent simply because you think that is too much work
for _the_infringer_ to do, or that the patent holder has to _prove_
something before the patent applies to the _infringer_. The patent
holder only has show to the court that the patent claims overlap the
infringer's work. And if the infringer can't prove there is no overlap
or invalidate the claims, then patent holder is _entitled_ to get
penalties, restitution, injunction [Well, that is, absent some egregious
conduct by the patent-holder, such as fraud on a standards body, as
happened in a court case involving a patented ITU standard]. Intentional
violation of a patent is a criminal offense that is prosecuted on people
who know of the patent but infringe anyway; its a crime in order to
deter people from doing that.

		--Dean

---

From: Martin Rex <[email-masked]>
Date: Mon, 30 Jun 2008 19:01:53 +0200 (MEST)

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.
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

---

From: Matthew Campagna <[email-masked]>
Date: Mon, 30 Jun 2008 13:08:54 -0400

In regards to the recent email activity concerning Certicom's IPR and the 'TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode', it is Certicom's continuing intention to foster the adoption of elliptic curve cryptography.  As such we will be extending the IETF grant to cover TLS 1.2 as specified in http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-10.txt,  when used with
      A. "ECC Cipher Suites for TLS" draft http://www.ietf.org/rfc/rfc4492.txt or,
        B. The ECC cipher suites with SHA256/384 and AES Counter Mode http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-new-mac-07.txt,

under the same terms that appear in the January 2006 IETF Contribution Letter.  This letter and an FAQ concerning that letter can be found at, http://www.certicom.com/index.php/ip-contributions

Once the updated letter has been finalize we will post it to the TLS Working Group.

Regards,
   Matthew Campagna

Matthew Campagna
Certicom Research
[email-masked]

---

From: Richard M Stallman <[email-masked]>
Date: Mon, 30 Jun 2008 19:03:37 -0400

Since "IPR" refers to a congeries of different laws, any general
statement about "IPR issues" is almost always an overgeneralization.
Your statement is one.

Copyright issues and trademark issues generally do NOT cause serious
problems for a proposed technique, because it is easy enough to work
around them.  To discuss them here at length would probably be
superfluous.

By contrast, patent problems are often fatal, and there is no remedy
except to wait as much as 20 years.  Thus, discussing whether a
proposed technique is patented is absolutely crucial.

Lumping together things which are so different in their effects is
encouraging confusion.  Thus, using the term "IPR" does only harm.
Avoiding it is easy, so let's avoid it.  When referring to patent
issues, let's call them "patent issues".
_______________________________________________
TLS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: "Mark Tillinghast" <[email-masked]>
Date: Mon, 30 Jun 2008 23:21:42 -0700

Hello,
I did want to encourage people to have a look at Matthew Campagna's post.
I am not sure that people hav seen this. And it is authoritative-- I 
instigated this though my contacts at certicom to clarify their position on 
this issue in the hope that we could marshall our way past these issues..
Please have a look as it should alay doubts or misgivings; surely those 
related to Certicom's "patent issues" involvement in ECC.
Thank You,
Mark

---

From: Yoav Nir <[email-masked]>
Date: Tue, 1 Jul 2008 09:10:18 +0300

OK, but Martin is correct about patent issues as well. We can discuss  
patent issue on and on, but we can't really get to any solid  
conclusions.

None of us on the TLS mailing list is a lawyer, definitely not a  
patent lawyer, and even if we were, the discussion about whether or  
not a patent applies will usually never terminate. The only way to  
really know is to implement, wait for the lawsuit, and see who wins.  
Unfortunately, most implementers, especially commercial ones are not  
willing to take this route.

Looking for unencumbered alternatives is even more tricky.  We know  
(or think) that TLS-SRP is encumbered. Suppose we took these guys'  
proposal to create an unencumbered alternative:
http://www.lightbluetouchpaper.org/2008/05/29/j-pake/

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.

On Jul 1, 2008, at 2:03 AM, Richard M Stallman wrote:

> Scanned by Check Point Total Security Gateway.
>