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

From: The IESG <[email-masked]>
Date: Mon, 23 Jun 2008 10:36:48 -0700 (PDT)

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
[email-masked]
https://www.ietf.org/mailman/listinfo/tls

---

From: Rob Dugal <[email-masked]>
Date: Tue, 24 Jun 2008 11:07:24 -0400

Have ciphersuite IDs for this document been assigned by IANA yet?
Same question for draft-ietf-tls-rsa-aes-gcm-03.txt

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of The IESG
> Sent: Monday, June 23, 2008 1:37 PM
> To: IETF-Announce
> Cc: Internet Architecture Board; tls mailing list; tls chair; RFC Editor
> Subject: Document Action: 'TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter
> Mode' to Informational RFC
>
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce

---

From: <[email-masked]>
Date: Wed, 25 Jun 2008 10:06:03 +0300

IANA assigns the numbers after the document has been
approved, usually within couple of weeks. Once the
assignments have been done, they're immediately visible
here:

http://www.iana.org/assignments/tls-parameters,

Best regards,
Pasi 

> From: ext Rob Dugal [mailto:[email-masked]] 
> Sent: 24 June, 2008 18:07
> To: [email-masked]
> Cc: Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: RE: Document Action: 'TLS Elliptic Curve Cipher 
> Suites with SHA-256/384 and AES Galois Counter Mode' to 
> Informational RFC
> 
> > From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of The IESG

---

From: Dean Anderson <[email-masked]>
Date: Wed, 25 Jun 2008 14:53:37 -0400 (EDT)

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

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

---

From: Yoav Nir <[email-masked]>
Date: Wed, 25 Jun 2008 22:20:11 +0300

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:

> Scanned by Check Point Total Security Gateway.
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 25 Jun 2008 16:26:39 -0400

http://www.ietf.org/ietf/IPR/certicom-ipr-rfc-3446.pdf  seem to cover 
TLS and ECC.  However, I agree that Certicom should be asked to 
update the IPR statement to cover TLS 1.2 as well as the recent 
Internet-Drafts.

Russ

---

From: Dean Anderson <[email-masked]>
Date: Wed, 25 Jun 2008 16:45:13 -0400 (EDT)

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

---

From: Russ Housley <[email-masked]>
Date: Wed, 25 Jun 2008 17:20:02 -0400

>more clouded by that sale.

You do not understand correctly. NSA and Certicom gave briefings at 
the SAAG session at the last IETF meeting held in Washington, 
DC.  The slides and other information from that session are in the proceedings.

http://www.ietf.org/proceedings/04nov/slides/saag-2/sld1.htm
http://www.ietf.org/proceedings/04nov/slides/saag-5.pdf
http://www.ietf.org/proceedings/04nov/slides/saag-4/sld1.htm

Russ

---

From: [email-masked] (Peter Gutmann)
Date: Thu, 26 Jun 2008 17:22:09 +1200

Dean Anderson <[email-masked]> writes:

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

Another issue with the various patents is that there is sufficient FUD
surrounding them that users (at least in my experience) are unwilling to go
near them because it's easier to just use unencumbered RSA (or whatever).
Specifically, given the choice between having lawyers spend forever trying to
ensure they won't get sued and just going ahead and using the de facto method,
they've all gone for the de facto one (the EKE patent mess is another example
of this in action).  So there are really two issues, whether there is
technically an issue and whether there is legally an issue, i.e. whether
people are going to be happy using this with the threat of lawsuits hanging
over them.  Without a clear and unambigous statement from any patent
stakeholders saying that nothing will happen to you for implementing this, I
can't see customers going for it, it's all risk and no benefit.

Peter.

---

From: "Blumenthal, Uri" <[email-masked]>
Date: Thu, 26 Jun 2008 10:35:00 -0400

That sums it up nicely (for the industry at least) - thanks Peter.
--
Regards,
Uri
<Disclaimer>

Peter.

---

From: <[email-masked]>
Date: Tue, 1 Jul 2008 11:09:05 +0300

Dean,

The ECC algorithms are specified in RFC 4492, not in this document. 
In other words, you cannot implement this document without reading 
and implementing large parts of RFC 4492.

When a "base document" of some protocol or feature has IPR
disclosures, it hasn't been common to submit IPR disclosures for
"extension documents" or features (which also require implementing the
base protocol/feature), unless the extension itself has some new IPRs.

For example, the SIP base protocol (RFC 3261) has an IPR disclosure, 
but when doing an IPR disclosure search for some SIP extension (say,
draft-vanelburg-sipping-served-user) on the IETF page, you get only
IPR disclosures specific to that extension. Perhaps adding a
"recursive IPR disclosure search" feature would be useful, though.

Given this, I don't find the situation at all similar to TLS-Authz;
the necessary IPR disclosures have been filed. Certicom has also
promised to update the licensing statement (which is not required
by BCP79) to make it clearer that it applies to this document as 
well. 

Non-patended (non-ECC-based) alternatives were discussed in the 
WG, and a document specifying them (TLS cipher suites that use 
non-ECC key exchange with GCM mode), draft-ietf-tls-rsa-aes-gcm,  
was approved on the same day as this document.

Best regards,
Pasi 

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of ext Dean Anderson
> Sent: 25 June, 2008 21:54
> To: The IESG
> Cc: [email-masked]; tls chair; Internet Architecture Board; tls 
> mailing list; IETF-Announce; RFC Editor
> Subject: Re: [TLS] Document Action: 'TLS Elliptic Curve 
> Cipher Suites with SHA-256/384 and AES Galois Counter Mode' 
> to Informational RFC
> 
> Gentle people,
>