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

Dean Anderson <dean@av8.com> Wed, 25 June 2008 20:45 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2A9D3A6AD9; Wed, 25 Jun 2008 13:45:25 -0700 (PDT)
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E85A3A6AD9 for <tls@core3.amsl.com>; Wed, 25 Jun 2008 13:45:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.674
X-Spam-Level:
X-Spam-Status: No, score=-1.674 tagged_above=-999 required=5 tests=[AWL=0.925, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id McG-YaOCtuhp for <tls@core3.amsl.com>; Wed, 25 Jun 2008 13:45:24 -0700 (PDT)
Received: from cirrus.av8.net (cirrus.av8.net [130.105.36.66]) by core3.amsl.com (Postfix) with ESMTP id 536653A6AE3 for <tls@ietf.org>; Wed, 25 Jun 2008 13:45:22 -0700 (PDT)
Received: from citation2.av8.net (citation2.av8.net [130.105.12.10]) (authenticated bits=0) by cirrus.av8.net (8.12.11/8.12.11) with ESMTP id m5PKjEbR011583 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 25 Jun 2008 16:45:14 -0400
Date: Wed, 25 Jun 2008 16:45:13 -0400
From: Dean Anderson <dean@av8.com>
X-X-Sender: dean@citation2.av8.net
To: Yoav Nir <ynir@checkpoint.com>
In-Reply-To: <7033BC39-4B16-40F2-B452-A20C8DF7F494@checkpoint.com>
Message-ID: <Pine.LNX.4.44.0806251617430.17162-100000@citation2.av8.net>
MIME-Version: 1.0
Cc: tls mailing list <tls@ietf.org>, rms@gnu.org
Subject: Re: [TLS] Document Action: 'TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode' to Informational RFC
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org

Hello Yoav, 

If I understand correctly, Certicom has over 130 patents in ECC and
public key crypto and has sold 26 patents and patent applications on the
subject to the US National Security Agency. The NSA controls licening
rights on those patents, not Certicom. The licensing situation is much
more clouded by that sale.

As for the Certicom licence grant on its remaining patents, that grant
identifies specific drafts and doesn't include this draft. The grant in
'750 you mention specifically restricts the grant to the drafts listed:  
"The licence granted does not extend, either explicitly or implicitly,
to other IETF protocols".

__But none of these issues were discussed or reported on this particular
draft.__   

I think the lack of discussion and non-disclosure is really the first,
core problem.  We can discuss and debate patent issues only if people
who know or should know that the patents exist, report those patents as
required by IETF policy.

Also, in fact, I can see no consensus for this draft either: The working
group was entirely silent on the draft for its last call. The last
message I have (before today), is the IESG Last Call message.  I can see
no evidence of the consensus which is required by IETF procedures
(RFC2026 et al) for publication.

		--Dean
		

On Wed, 25 Jun 2008, Yoav Nir wrote:

> Hi Dean.
> 
> It's debatable whether or not ECC is really heavily patented,  
> considering that the original articles are from the early 80s. AFAIK  
> all the IPR claims that may matter are from Certicom. You may have  
> found this statement in your search: https://datatracker.ietf.org/ipr/750/
> 
> In that disclosure, Certicom grants a license to use their IPR for ECC  
> in all IKE, IKEv2 and TLS protocols. This may be the reason why there  
> are no disclosure specific to this draft.
> 
> Yoav
> 
> On Jun 25, 2008, at 9:53 PM, Dean Anderson wrote:
> 
> > Gentle people,
> >
> > I can find no patent disclosures on this document listed on the IETF  
> > IPR
> > search page at https://datatracker.ietf.org/ipr/search/ using
> > draft-ietf-tls-ecc-new-mac as the I-D Filename.
> >
> > Elliptic curve cryptography is a heavilly patented area, and it seems
> > impossible that this draft does not involve an existing patent.
> >
> > I also seemed to have missed the discussion of non-patented
> > alternatives, as required by RFC3979.
> >
> > Surely the IESG would not approve a document AGAIN that did not  
> > disclose
> > its patent status in violation of RFC3979 et al!?!
> >
> > I have to object to the approval of this draft on those grounds.  I am
> > very concerned that the IESG would not be more circumspect and careful
> > in light of the previous TLS-Authz scandal. See
> > http://www.av8.net/IETF-watch/People/Housley/index.html
> > http://www.av8.net/IETF-watch/People/TimPolk/index.html
> > for more information about TLS-Authz.
> >
> > 		--Dean
> >
> >
> > On Mon, 23 Jun 2008, The IESG wrote:
> >
> >> The IESG has approved the following document:
> >>
> >> - 'TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois
> >>   Counter Mode '
> >>   <draft-ietf-tls-ecc-new-mac-07.txt> as an Informational RFC
> >>
> >> This document is the product of the Transport Layer Security Working
> >> Group.
> >>
> >> The IESG contact persons are Pasi Eronen and Tim Polk.
> >>
> >> A URL of this Internet-Draft is:
> >> http://www.ietf.org/internet-drafts/draft-ietf-tls-ecc-new-mac-07.txt
> >>
> >> Technical Summary
> >>
> >>   This document describes new ECC cipher suites for TLS which
> >>   specify stronger MAC algorithms. Eight use HMAC with SHA-256 or
> >>   SHA-384 and eight use AES in Galois Counter Mode (GCM).
> >>
> >> Working Group Summary
> >>
> >>   This document is a product of the Transport Layer Security (TLS)
> >>   Working Group. The document represents the consensus of the TLS
> >>   working group.
> >>
> >> Document Quality
> >>
> >>   There has been significant review of the document by members of
> >>   the TLS working group on the document and changes were made to
> >>   improve the document based on these reviews.
> >>
> >> Personnel
> >>
> >>   The Document Shepherd for this document is Joseph Salowey, and the
> >>   responsible Area Director is Pasi Eronen.
> >>
> >> RFC Editor Note
> >>
> >>   In document title, expand "GCM" to "Galois Counter Mode (GCM)"
> >>
> >>   Abstract:
> >>   OLD:
> >>      However, all those cipher suites use SHA-1 as their MAC
> >>      algorithm.  This document describes sixteen new cipher suites
> >>      for TLS which specify stronger digest algorithms.
> >>   NEW:
> >>      However, all those cipher suites use HMAC-SHA1 as their MAC
> >>      algorithm.  This document describes sixteen new cipher suites
> >>      for TLS which specify stronger MAC algorithms.
> >>
> >>   Section 3.1
> >>   OLD:
> >>      These eight cipher suites are the same as the corresponding
> >>      cipher suites in RFC 4492 (with names ending in "_SHA" in place
> >>      of "_SHA256" or "_SHA384"), except for the hash and PRF
> >>      algorithms.
> >>   NEW:
> >>      These eight cipher suites are the same as the corresponding
> >>      cipher suites in RFC 4492 (with names ending in "_SHA" in place
> >>      of "_SHA256" or "_SHA384"), except for the MAC and PRF
> >>      algorithms.
> >>
> >> _______________________________________________
> >> TLS mailing list
> >> TLS@ietf.org
> >> https://www.ietf.org/mailman/listinfo/tls
> >>
> >>
> >
> > -- 
> > Av8 Internet   Prepared to pay a premium for better service?
> > www.av8.net         faster, more reliable, better service
> > 617 344 9000
> >
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
> > Scanned by Check Point Total Security Gateway.
> >
> 
> 
> 

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



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls