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

From: "Igoe, Kevin M." <[email-masked]>
Date: Wed, 6 Feb 2013 14:43:30 +0000

Looking at the IRTF requirements (which differ slightly from the IETF's),
as described at

  http://wiki.tools.ietf.org/group/irtf/trac/wiki/IRTF-RFCs#

there are a few key phrases that need to be worked in
(see the section of Research Group Preparation).

----------------------------------------------------------------------------
There must be a statement in the abstract identifying it as the product of the RG

     How about this:  "This document is a product of the Crypto Forum Research Group (CFRG)."

----------------------------------------------------------------------------
There must be a paragraph near the beginning (for example, in the introduction) describing
the level of support for publication. Example text might read: "this document represents
the consensus of the FOOBAR RG" or "the views in this document were considered controversial
by the FOOBAR RG but the RG reached a consensus that the document should still be published".

     Aside from IPR issues (sigh), there is nothing controversial here.  I suggest putting in a phrase
    like:

         "OCB has received years of in-depth analysis previous to its submission to the CFRG
           (see [4] and [5]), and has been under review by the members of the CFRG for almost
           a year.  It is the consensus of the CFRG that the security mechanisms provided by the
           OCB AEAD algorithm described in this document are suitable for use in providing privacy
          and authentication."

    You might want to add a reference that isn't behind a paywall, say IACR ePrint 2001/026.

----------------------------------------------------------------------------
The breadth of review the document has received must also be noted. For example, was this
 document read by all the active contributors, only three people, or folks who are not "in" the
RG but are expert in the area?

   I think the text abpve covers that.

----------------+--------------------------------------------------
Kevin M. Igoe   | "We can't solve problems by using the same kind
[email-masked]  | of thinking we used when we created them."
                |              - Albert Einstein -
----------------+--------------------------------------------------

---

From: Greg Rose <[email-masked]>
Date: Wed, 6 Feb 2013 07:42:07 -0800

On 2013 Feb 6, at 6:43 , Igoe, Kevin M. wrote:

>      How about this:  “This document is a product of the Crypto Forum Research Group (CFRG).”

No, it isn't. I for one haven't even read it.
>          “OCB has received years of in-depth analysis previous to its submission to the CFRG
>           and authentication.”
>     You might want to add a reference that isn’t behind a paywall, say IACR ePrint 2001/026.   

Knowing the background and the authors, I can go along with "consensus". But in some standards bodies (I don't actually do all that much with IETF so I don't know the true position here) the word "consensus" has a defined meaning. I'm not sure we correctly can use it...

Greg.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 6 Feb 2013 11:24:37 -0500

I concur with Greg.

My opinion is - this mode is technically sound (and that's probably is
this group's consensus) but practically unusable in any serious product
(commercial or otherwise) because of its licensing terms.

This licensing makes me leery to accept this AEAD mode for standardization
(despite that it is faster than the alternatives) when we already have
acceptable standardized non-encumbered (and reasonably fast) modes such as
GCM. 

Performance isn't all, after all. :-)
--
Regards,
Uri Blumenthal
<Disclaimer>

On 2/6/13 10:42 , "Greg Rose" <[email-masked]> wrote:

>>      How about this:  ³This document is a product of the Crypto Forum
>>Research Group (CFRG).²
>
>>          ³OCB has received years of in-depth analysis previous to its
>>submission to the CFRG
>>           and authentication.²
>>     You might want to add a reference that isn¹t behind a paywall, say
>>IACR ePrint 2001/026.
>
>Knowing the background and the authors, I can go along with "consensus".
>But in some standards bodies (I don't actually do all that much with IETF
>so I don't know the true position here) the word "consensus" has a
>defined meaning. I'm not sure we correctly can use it...
>
>Greg.
>
>_______________________________________________
>Cfrg mailing list
>[email-masked]
>http://www.irtf.org/mailman/listinfo/cfrg

---

From: Ted Krovetz <[email-masked]>
Date: Wed, 6 Feb 2013 08:51:59 -0800

> practically unusable in any serious product (commercial or otherwise) because of its licensing terms.

I certainly hope that we can convince you that this is not true.

There are a huge number of serious open-source products that all fall under License 1's simple terms (linux, gnu, any project using any OSI-approved license, etc).

Note that License 1 does not have a non-military provision, meaning that open-source software need not worry about it.

And we are determined try to make License 2 workable, which would then make all software (open or closed, commercial or non-commercial) free for non-military use, and hardware implementations free for non-commercial non-military purposes.

That allows for a lot of serious products.

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Wed, 6 Feb 2013 12:00:55 -0500

>I certainly hope that we can convince you that this is not true.

I'd love to be convinced, as (contrary to how it may appear) I'm not
averse to faster AEAD modes. :)

>There are a huge number of serious open-source products that all fall
>under License 1's simple terms (linux, gnu, any project using any
>OSI-approved license, etc).
>
>Note that License 1 does not have a non-military provision, meaning that
>open-source software need not worry about it.

Let's consider a hypothetical case: a company X adds an OCB implementation
to OpenSSL (or Crypto++) and then use that library/package in their
proprietary "SuperComm" software thatthey subsequently sell to Department
of Defense and to Department of Energy.

First - are they even allowed to to that under this license?

Second - how much of the source code do they have to make available to
satisfy the terms of "License 1"? Just the OCB code? The entire OpenSSL or
Crypto++? The entire "SuperComm" source?

>And we are determined try to make License 2 workable, which would then
>make all software (open or closed, commercial or non-commercial) free for
>non-military use, and hardware implementations free for non-commercial
>non-military purposes.

Non-commercial hardware? I'd like to see an example of that, and maybe a
box of samples. :)

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 06 Feb 2013 17:13:14 +0000

> This licensing makes me leery to accept this AEAD mode for standardization

This isn't being proposed as a standard, but as an informational
IRTF-track RFC. Those aren't the same thing, even though there
are a bunch of people who regard them as being the same.

S.

PS: The header should also be fixed up to say IRTF and not
IETF, see, e.g. [1] for what it ought look like. That'd get
fixed later anyway, but no harm doing it now.

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-bpq

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 11 Feb 2013 12:18:13 +0100

Ted Krovetz <[email-masked]> writes:

>> practically unusable in any serious product (commercial or
> otherwise) because of its licensing terms.
>

The simplest way to do that is to change the license.

As far as I understand, the current license fails to meet the open
source definition used by OSI, in particular the "No Discrimination
Against Fields of Endeavor" paragraph:

  http://opensource.org/osd

Thus, and also as far as I understand, I could not implement OCB in some
of my free software packages, and have that be accepted by organisations
that require OSI-compatible licensing.

To me, anything that restrict significant implementers ability to use a
specification is a serious problem, to the point that it may be better
to find and use another specification.

Thefore I don't find it a good use of everyone's collective time to
publish specifications that aren't useful to as many as possible,
especially if there are alternatives.

/Simon

---

From: Ted Krovetz <[email-masked]>
Date: Mon, 11 Feb 2013 08:20:21 -0800

> "No Discrimination Against Fields of Endeavor"

License 1 has no such restriction. Only License 2 does. Since you are free to choose which license you wish to abide by, I don't see any reason you couldn't use OCB under License 1 in your work.

> Therefore I don't find it a good use of everyone's collective time

We are asking that the draft be blessed as a good technical description of some good innovative cryptography. I believe CFRG is the best place to make such a request (regardless of OCB not being free enough for some people's taste).

-Ted

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Mon, 11 Feb 2013 11:33:04 -0500

On 2/11/13 11:20 , "Ted Krovetz" <[email-masked]> wrote:

>License 1 has no such restriction. Only License 2 does. Since you are
>free to choose which license you wish to abide by, I don't see any reason
>you couldn't use OCB under License 1 in your work.

I'd still like to see clarifications (answers to my example questions)
regarding License 1. To make it easier to track, here it is:

Let's consider (an updated) hypothetical case: company A adds an OCB
implementation
to OpenSSL (or Crypto++). Company X then uses that library/package in their
proprietary "SuperComm" software that they subsequently sell to Department
of Defense and to Department of Energy.

Third - if there's a violation of the license terms in the above example,
which entity is considered responsible?

---

From: Jon Callas <[email-masked]>
Date: Mon, 11 Feb 2013 08:41:40 -0800

On Feb 11, 2013, at 8:33 AM, "Blumenthal, Uri - 0558 - MITLL" <[email-masked]> wrote:

> * PGP - S/MIME Signed by an unverified key: 02/11/2013 at 08:33:04 AM
> 

But that's A Corp's problem, not the IETF's. It's the purpose of a standard to describe things for the purposes of interoperability. Arguably, it's also a layer 8 problem and we're layer 9.

A Corp can very likely make the problem go away by throwing cash at the problem, as well. At PGP, we liked EME2, another Rogaway protocol with similar IP issues. We bought a license from the University of California. It was reasonably priced. We got on with our lives.

	Jon

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Mon, 11 Feb 2013 11:44:19 -0500

License 1 is Open Source, and A may not be a Corp (like PGP, Inc. is). And
if (for example) I were to develop and release some free code - I sure
wouldn't want to throw cash at this problem.
--
Regards,
Uri Blumenthal
<Disclaimer>

On 2/11/13 11:41 , "Jon Callas" <[email-masked]> wrote:

>But that's A Corp's problem, not the IETF's. It's the purpose of a
>standard to describe things for the purposes of interoperability.
>Arguably, it's also a layer 8 problem and we're layer 9.
>
>A Corp can very likely make the problem go away by throwing cash at the
>problem, as well. At PGP, we liked EME2, another Rogaway protocol with
>similar IP issues. We bought a license from the University of California.
>It was reasonably priced. We got on with our lives.
>
>	Jon
>

---

From: Ted Krovetz <[email-masked]>
Date: Mon, 11 Feb 2013 10:25:08 -0800

> regarding License 1.

I'm going to pass your thorny license questions off to Phil. I'll continue to manage any comments on the RFC draft itself.

Any comments on the draft?

Thanks,
Ted

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 11 Feb 2013 20:34:31 +0100

> Any comments on the draft?

The references [OCB1], [OCB2], [OCB3] are not found in the References
section.  Maybe they are [5], [4], and [3] respectively?

/Simon

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 11 Feb 2013 20:50:50 +0100

Ted Krovetz <[email-masked]> writes:

> free to choose which license you wish to abide by, I don't see any
> reason you couldn't use OCB under License 1 in your work.

License 1 explicitly does not cover implementations in "embedded
systems", presumably leaving such use unlicensed.  My implementations
are frequently used in embedded systems, and I want my license to permit
that.

Thus, I cannot read license 1 in any other way than that some fields of
endeavor (e.g., embedded systems) are discriminated against.

As a consequence, neither license 1 nor license 2 appear to be usable by
my implementations.

While the intent may have been good, I believe the wording of the
current license is a problem for anyone contemplating using OCB.

/Simon

---

From: Jon Callas <[email-masked]>
Date: Mon, 11 Feb 2013 12:12:36 -0800

On Feb 11, 2013, at 8:44 AM, "Blumenthal, Uri - 0558 - MITLL" <[email-masked]> wrote:

> * PGP - S/MIME Signed by an unverified key: 02/11/2013 at 08:44:19 AM
> 

Sure, but accurate documentation of a protocol for the purposes of interoperability is orthogonal to suitability for a given business purpose.

As a standards body, we're interested in the first. Obviously, if something is so dodgy in the second that we'd be wasting our time, then there's no need to waste our time. Saying that we're not interested and call us back in 2021 is not a horrible position. Given that OCB is already used in a number of places and that we're seeing movement towards liberalization of licensing, I think going forward with the draft is a good thing. 

Me -- I would like to use OCB, and am presently using CCM because of the licensing. I am hopeful that we could discuss the use strictly on technical merits.

	Jon

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Tue, 12 Feb 2013 12:52:32 +0000

Hi Ted,

On 2/11/13 1:25 PM, "Ted Krovetz" <[email-masked]> wrote:

>I'm going to pass your thorny license questions off to Phil. I'll
>continue to manage any comments on the RFC draft itself.
>

I did another read of the draft, and put down some thoughts.

This is a nicely written draft; it reads well.  It clearly deserves to be
published as an RFC.

It would be good to have more prescriptive text about nonce use in the
algorithm description.

I think "OCB encryption and decryption employ a nonce N, which must be
selected as a new value for each message encrypted." can be said more
clearly.   Perhaps "a nonce N; the value of the nonce MUST be distinct for
each distinct invocation of the OCB encryption operation".

In Section 4.2., after "This function computes a ciphertext (which
includes a bundled authentication tag) when given a plaintext, associated
data, nonce and key." I suggest adding "For each invocation of
OCB-ENCRYPT, the value of the Nonce input MUST be distinct."

In the security considerations, why not say 2^64 instead of 2^{128/2}?

Paragraphs 3 and 4 of the Security Considerations section have a good
description of the security degradation due to nonce reuse.   I think it
would be a good idea to make these paragraphs a separate subsection, so
that they show up in the table of contents.

Thanks,

David