Subject: Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

From: Dan Brown <[email-masked]>
Date: Fri, 5 Mar 2021 00:46:03 +0000

Sorry for foolishly forgetting about the OCB RFC, which specifies OCB3.

But that OCB3 RFC is from 2014, five-ish years before the OCB2 break.

Again, the OCB2 attack severely erodes my trust in OCB3, though maybe I'm an outlier. Maybe I'm also forgetting recent CFRG or other effort to regain trust in OCB3 relative to OCB2?

________________________________
From: Dan Harkins <[email-masked]>
Sent: Mar 4, 2021 5:29 PM
To: Dan Brown <[email-masked]>; [email-masked]
Subject: Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

  Hi Dan,

On 3/4/21 11:04 AM, Dan Brown wrote:
Deciding whether to use OCB sounds like a job for CFRG!

As I understand it, OCB2 is severely broken: https://eprint.iacr.org/2019/311<https://urldefense.proofpoint.com/v2/url?u=https-3A__eprint.iacr.org_2019_311&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=8aGCbnoSU7ozJ-QSzxHGokOgKsea7IZq6669KyaMNNA&s=bSN3q8CM03xYZRbPi2KanYD7GKxGF2HjAZ9AjTc5Nvk&e=>

That said, OCB1 and OCB3 may be just fine, but a broken OCB2 is not a good sign.  All the more reason to defer to CFRG, unless you want to play Monty Hall problem.

  CFRG already produced RFC 7253. That's really all they can
be expected to do. It's up to individual IETF WGs to define
how to use that cipher mode in their particular protocols.
That's where we come in.

  regards,

  Dan.

Dan

From: IPsec <[email-masked]><mailto:[email-masked]> On Behalf Of Dan Harkins
Sent: Wednesday, March 3, 2021 2:37 PM
To: [email-masked]<mailto:[email-masked]>
Subject: Re: [IPsec] [Cryptography] Direct public confirmation from Dr. Rogaway (fwd)

  Faster and more secure seem to be compelling reasons. Those reasons are
probably more compelling for ESP than they are for IKE.

  The license for OCB always had some caveats like the code could not be used
for military purposes which is something of a nightmare for a manufacturer of
general purpose hardware/software. Considering how difficult it would be to
ensure that your product is never used by a military anywhere in the world,
that's probably enough of a reason for TLS to not support it. Remember how
long ECC was delayed for (imagined) IP reasons?

  IP is bad news. People don't want anything to do with partially encumbered
technology. Now this technology is not encumbered at all so, yea, let's do it.

  If an individual draft was to appear would the WG adopt it as a work item?

  regards,

  Dan.
On 2/28/21 1:47 PM, Yoav Nir wrote:
IIRC the license has allowed OCB to be used for TLS for several years. They haven’t taken it up. There are no AES-OCB ciphersuites inhttps://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4

So I’m wondering right with you: It has a theoretical advantage in security and a measurable advantage in speed in software.  Neither were compelling enough for anyone to bother adding it in TLS ciphersuites.  Why should our conclusion be any different?

Yoav

On 28 Feb 2021, at 22:35, Paul Wouters <[email-masked]<mailto:[email-masked]>> wrote:

So now that OCB is finally free, do we want to implement it? :)

I'm honestly not sure if the improvements of AES-GCM are worth it.
I haven't heard of vulnerabilities in IKE/ESP wrt. IVs or counters.

Paul

---------- Forwarded message ----------
Date: Sat, 27 Feb 2021 14:37:30
From: "Salz, Rich via cryptography" <[email-masked]<mailto:[email-masked]>>
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [Cryptography] Direct public confirmation from Dr. Rogaway

https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/<https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_cfrg_qLTveWOdTJcLn4HP3ev-2Dvrj05Vg_&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=2DcLjYKtazJ6kYTZx5uowgB-qJRp6_C8W0rBOr7ZOUI&s=LZV-8STdDDeui1TmXz2JORn2wTtSrkJa_-l3hZK-AO8&e=> :

I can confirm that I have abandoned all OCB patents

and placed into the public domain all OCB-related IP of mine.

While I have been telling people this for quite some time, I don't

think I ever made a proper announcement to the CFRG or on the

OCB webpage. Consider that done.

I hope people will use the scheme to do positive things.

phil

_______________________________________________
The cryptography mailing list
[email-masked]<mailto:[email-masked]>
https://www.metzdowd.com/mailman/listinfo/cryptography<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.metzdowd.com_mailman_listinfo_cryptography&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=2DcLjYKtazJ6kYTZx5uowgB-qJRp6_C8W0rBOr7ZOUI&s=_9IPM1exZqE6F4PLBAvpqDF-bHkBi5JPiUyq3eeyfwo&e=>
_______________________________________________
IPsec mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/ipsec<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipsec&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=2DcLjYKtazJ6kYTZx5uowgB-qJRp6_C8W0rBOr7ZOUI&s=B4s3eO4jZ5UhqwAPEQu9SxQaSVWKuM4HcC1moozCyBc&e=>

_______________________________________________

IPsec mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/ipsec<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipsec&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=2DcLjYKtazJ6kYTZx5uowgB-qJRp6_C8W0rBOr7ZOUI&s=B4s3eO4jZ5UhqwAPEQu9SxQaSVWKuM4HcC1moozCyBc&e=>

--

"The object of life is not to be on the side of the majority, but to

escape finding oneself in the ranks of the insane." -- Marcus Aurelius

________________________________
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

--
"The object of life is not to be on the side of the majority, but to
escape finding oneself in the ranks of the insane." -- Marcus Aurelius

----------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Dan Harkins <[email-masked]>
Date: Thu, 04 Mar 2021 17:25:31 -0800

> But that OCB3 RFC is from 2014, five-ish years before the OCB2 break.
   It says:

"The version of OCB defined in this document is a refinement of two
    prior schemes.  The original OCB version was published in 2001 [OCB1]
    and was listed as an optional component in IEEE 802.11i.  A second
    version was published in 2004 [OCB2] and is specified in ISO 19772.
    The scheme described here is called OCB3 in the 2011 paper describing
    the mode [OCB3]; it shall be referred to simply as OCB throughout
    this document.  The only difference between the algorithm of this RFC
    and that of the [OCB3] paper is that the tag length is now encoded
    into the internally formatted nonce.  See [OCB3] for complete
    references, timing information, and a discussion of the differences
    between the algorithms."

So this RFC describes OCB3.

> Again, the OCB2 attack severely erodes my trust in OCB3, though maybe 
> I'm an outlier. Maybe I'm also forgetting recent CFRG or other effort 
> to regain trust in OCB3 relative to OCB2?

And it also says:

   "OCB has received years of in-depth analysis previous to its
    submission to the CFRG and has been under review by the members of
    the CFRG for over 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 confidentiality and
    authentication."

   So CFRG has produced a document defining OCB3 and that document
represents the consensus of the CFRG. I'm not sure what else you think
CFRG should be doing but maybe mention it on the CFRG list instead of
IPsec. Also, Phil Rogaway is on the CFRG list but I don't think he's
on this one. If you have trust issues with OCB then maybe bring them
up with him there.

   Dan.

>
> ------------------------------------------------------------------------
> *From: *Dan Harkins <[email-masked]>
> *Sent: *Mar 4, 2021 5:29 PM
> *To: *Dan Brown <[email-masked]>; [email-masked]
> *Subject: *Re: [IPsec] [Cryptography] Direct public confirmation from 
> Dr. Rogaway (fwd)
>
>
>       Hi Dan,
>
>>     As I understand it, OCB2 is severely broken:
>>     https://eprint.iacr.org/2019/311
>>     <https://urldefense.proofpoint.com/v2/url?u=https-3A__eprint.iacr.org_2019_311&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=mf6j6fOClApRsArWE9wqI1rEGUVkfxZ0aXWmn35nK_c&m=8aGCbnoSU7ozJ-QSzxHGokOgKsea7IZq6669KyaMNNA&s=bSN3q8CM03xYZRbPi2KanYD7GKxGF2HjAZ9AjTc5Nvk&e=>
>>
>>     That said, OCB1 and OCB3 may be just fine, but a broken OCB2 is
>>     not a good sign.  All the more reason to defer to CFRG, unless
>>     you want to play Monty Hall problem.
>>
>>
>
>>     *From:* IPsec <[email-masked]> *On Behalf Of *Dan Harkins
>>     *Sent:* Wednesday, March 3, 2021 2:37 PM
>>     *To:* [email-masked]
>>     *Subject:* Re: [IPsec] [Cryptography] Direct public confirmation
>>     from Dr. Rogaway (fwd)
>>
>>
>>         IIRC the license has allowed OCB to be used for TLS for
>>         several years. They haven’t taken it up. There are no AES-OCB
>>         ciphersuites
>>         inhttps://www.iana.org/assignments/tls-parameters/tls-parameters.xml#tls-parameters-4
>>         < >
>>
>>         So I’m wondering right with you: It has a theoretical
>>         advantage in security and a measurable advantage in speed in
>>         software.  Neither were compelling enough for anyone to
>>         bother adding it in TLS ciphersuites.  Why should our
>>         conclusion be any different?
>>
>>         Yoav
>>
>>
>>
>>             From: "Salz, Rich via cryptography"
>>             <[email-masked]
>>             <mailto:[email-masked]>>
>>             To: "[email-masked]
>>             <mailto:[email-masked]>"
>>             <[email-masked]
>>             <mailto:[email-masked]>>
>>             https://mailarchive.ietf.org/arch/msg/cfrg/qLTveWOdTJcLn4HP3ev-vrj05Vg/
>>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_cfrg_qLTveWOdTJcLn4HP3ev-2Dvrj05Vg_&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=2DcLjYKtazJ6kYTZx5uowgB-qJRp6_C8W0rBOr7ZOUI&s=LZV-8STdDDeui1TmXz2JORn2wTtSrkJa_-l3hZK-AO8&e=>
>>             :
>>
>>
>>
>>             [email-masked] <mailto:[email-masked]>
>>             https://www.metzdowd.com/mailman/listinfo/cryptography
>>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.metzdowd.com_mailman_listinfo_cryptography&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=2DcLjYKtazJ6kYTZx5uowgB-qJRp6_C8W0rBOr7ZOUI&s=_9IPM1exZqE6F4PLBAvpqDF-bHkBi5JPiUyq3eeyfwo&e=>
>>             [email-masked] <mailto:[email-masked]>
>>             https://www.ietf.org/mailman/listinfo/ipsec
>>             <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipsec&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=2DcLjYKtazJ6kYTZx5uowgB-qJRp6_C8W0rBOr7ZOUI&s=B4s3eO4jZ5UhqwAPEQu9SxQaSVWKuM4HcC1moozCyBc&e=>
>>
>>
>>
>>         [email-masked]  <mailto:[email-masked]>
>>
>>         https://www.ietf.org/mailman/listinfo/ipsec  <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_ipsec&d=DwMDaQ&c=yzoHOc_ZK-sxl-kfGNSEvlJYanssXN3q-lhj0sp26wE&r=qkpbVDRj7zlSRVql-UonsW647lYqnsrbXizKI6MgkEw&m=2DcLjYKtazJ6kYTZx5uowgB-qJRp6_C8W0rBOr7ZOUI&s=B4s3eO4jZ5UhqwAPEQu9SxQaSVWKuM4HcC1moozCyBc&e=>
>>
>>
>>
>>     -- 
>>     ------------------------------------------------------------------------
>>     This transmission (including any attachments) may contain
>>     confidential information, privileged material (including material
>>     protected by the solicitor-client or other applicable
>>     privileges), or constitute non-public information. Any use of
>>     this information by anyone other than the intended recipient is
>>     prohibited. If you have received this transmission in error,
>>     please immediately reply to the sender and delete this
>>     information from your system. Use, dissemination, distribution,
>>     or reproduction of this transmission by unintended recipients is
>>     not authorized and may be unlawful.
>
>     -- 
> ------------------------------------------------------------------------
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information. Any use of this information by anyone other 
> than the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and 
> delete this information from your system. Use, dissemination, 
> distribution, or reproduction of this transmission by unintended 
> recipients is not authorized and may be unlawful.