Re: [Cfrg] RG Last Call - draft-irtf-cfrg-ocb-00

"Igoe, Kevin M." <kmigoe@nsa.gov> Mon, 11 February 2013 19:52 UTC

Return-Path: <kmigoe@nsa.gov>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93ABB21F88FD for <cfrg@ietfa.amsl.com>; Mon, 11 Feb 2013 11:52:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.379
X-Spam-Level:
X-Spam-Status: No, score=-9.379 tagged_above=-999 required=5 tests=[AWL=-0.820, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24, SARE_SUB_RAND_LETTRS4=0.799]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sKPNIl6WJddk for <cfrg@ietfa.amsl.com>; Mon, 11 Feb 2013 11:51:57 -0800 (PST)
Received: from nsa.gov (emvm-gh1-uea08.nsa.gov [63.239.67.9]) by ietfa.amsl.com (Postfix) with ESMTP id E16F421F883C for <cfrg@irtf.org>; Mon, 11 Feb 2013 11:51:55 -0800 (PST)
X-TM-IMSS-Message-ID: <4e0a8c240008bb95@nsa.gov>
Received: from MSHT-GH1-UEA01.corp.nsa.gov ([10.215.227.18]) by nsa.gov ([63.239.67.9]) with ESMTP (TREND IMSS SMTP Service 7.1; TLSv1/SSLv3 AES128-SHA (128/128)) id 4e0a8c240008bb95 ; Mon, 11 Feb 2013 14:50:46 -0500
Received: from MSMR-GH1-UEA07.corp.nsa.gov (10.215.224.5) by MSHT-GH1-UEA01.corp.nsa.gov (10.215.227.18) with Microsoft SMTP Server (TLS) id 14.1.289.1; Mon, 11 Feb 2013 14:51:53 -0500
Received: from MSMR-GH1-UEA03.corp.nsa.gov ([10.215.224.3]) by MSMR-GH1-UEA07.corp.nsa.gov ([10.215.224.5]) with mapi id 14.01.0289.001; Mon, 11 Feb 2013 14:51:53 -0500
From: "Igoe, Kevin M." <kmigoe@nsa.gov>
To: 'Ted Krovetz' <ted@krovetz.net>, "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] RG Last Call - draft-irtf-cfrg-ocb-00
Thread-Index: Ac4Dspy9Udf6dIL6TC+F69Worz8/1QAVw9uAAAO0wgABGkG6wA==
Date: Mon, 11 Feb 2013 19:51:52 +0000
Message-ID: <3C4AAD4B5304AB44A6BA85173B4675CA6AAABFAA@MSMR-GH1-UEA03.corp.nsa.gov>
References: <CD36D4B4.E927%uri@ll.mit.edu> <9BBAB802-CF3A-4DA0-B092-4F45B202C54F@krovetz.net>
In-Reply-To: <9BBAB802-CF3A-4DA0-B092-4F45B202C54F@krovetz.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.215.224.46]
Content-Type: multipart/alternative; boundary="_000_3C4AAD4B5304AB44A6BA85173B4675CA6AAABFAAMSMRGH1UEA03cor_"
MIME-Version: 1.0
Subject: Re: [Cfrg] RG Last Call - draft-irtf-cfrg-ocb-00
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <http://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <http://www.irtf.org/mail-archive/web/cfrg>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <http://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 11 Feb 2013 19:52:01 -0000

For sake of completeness, here are the IETF/IRTF IPR rules (http://irtf.org/ipr):

--------------------------------------------------------------------
The IRTF follows the IETF Intellectual Property Rights (IPR) disclosure rules.
This is a summary of these rules as they relate to IRTF research group discussions,
mailing lists and Internet Drafts:

*       If you include your own or your employer's IPR in a contribution to an
         IRTF research group, then you must file an IPR disclosure with the IETF.
*       If you recognize your own or your employer's IPR in someone else's
contribution and you are participating in the discussions in the research
group relating to that contribution, then you must file an IPR disclosure
with the IETF. Even if you are not participating in the discussion, the IRTF
still requests that you file an IPR disclosure with the IETF.
*       Finally, the IRTF requests that you file an IPR disclosure with the IETF if
you recognize IPR owned by others in any IRTF contribution.

The IRTF expects that you file IPR disclosures in a timely manner, i.e., in a period
measured in days or weeks, not months. The IRTF prefers that the most liberal licensing
terms possible are available for IRTF Stream documents, see RFC 5743. You may file an
IPR disclosure here: http://www.ietf.org/ipr/file-disclosure.




As long as the mailing list and authors agree that the IPR statement clearly
lays out the IPR situation correctly and unambiguously, the IPR can pretty much
say what it wants to say.  The "liberal licensing terms" mentioned above are a
suggestion, not a requirement.

Implementers are free to leave or take the OCB and its licensing conditions as
their legal console advises. I am not a lawyer, not do I play one on TV, but a
quick look at the patent office site seems to show all of the OCB patents chaining
back to a patent filed in 2001. To the best of my understanding this means both the
patents and the licensing constraints should vanish in the year 2021 (if so, the IPR
statement should consider mentioning this).  Hence licensing concerns for OCB are
a reasonably "short term" issue.




> -----Original Message-----
> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of
> Ted Krovetz
> Sent: Tuesday, February 05, 2013 5:18 PM
> To: cfrg@irtf.org
> Subject: Re: [Cfrg] RG Last Call - draft-irtf-cfrg-ocb-00
>
> Phil has issued broad licenses for OCB, allowing open-source software
> implementations and software implementations in non-military contexts
> and non-commercial non-military hardware implementations. The licenses
> are at
>
>   http://www.cs.ucdavis.edu/~rogaway/ocb/license.htm
>
> It is my understanding -- correct me if I'm wrong -- that IP
> disclosures do not go directly in the RFC but instead get disclosed to
> the IETF along with the RFC submission. This has been done and the
> disclosures are at
>
>
> https://datatracker.ietf.org/ipr/search/?option=document_search&id_docu
> ment_tag=draft-krovetz-ocb
>
> There is a study of OCB performance vs other AE schemes which includes
> AES-NI on Westmere hardware.
>
>   http://www.cs.ucdavis.edu/~rogaway/ocb/ocb-doc.htm
>   http://www.cs.ucdavis.edu/~rogaway/ocb/performance
>
> These have not been updated for Sandy Bridge or Ivy Bridge. I can tell
> you that under Sandy Bridge OCB takes just 0.87 cycles per byte when
> processing 4KB messages. The fastest GHASH implementation I know about
> is Andy Polyakov's OpenSSL implementation that runs at 2.0 cycles per
> byte (just for GCM's hashing, you'd have to add the cost of encryption
> to get GCM's overall speed). Sandy Bridge and Ivy Bridge did not
> improve PCLMULQDQ performance but did improve AESENC performance,
> meaning that Sandy and Ivy improved OCB's performance much more than
> GCM's.
>
> -Ted
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> http://www.irtf.org/mailman/listinfo/cfrg