Subject: Re: [Cfrg] ISE seeks help with some crypto drafts

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Apr 2019 05:19:29 -0700

These drafts seem quite low value to publish:

The existing OCB document [RFC 7253] is cited by exactly zero RFCs (
https://datatracker.ietf.org/doc/rfc7253/referencedby/), so having a
specification for ciphers with block size != 128 seems of particularly low
value.

The existing RC5 document [RFC 2040] has 6 RFC-level citations, but as far
as I know, RC5 has practically no usage in IETF protocols. AFAICT, RC6
isn't even specified in an RFC. Thus, test vectors for these algorithms
don't seem that interesting.

-Ekr

On Fri, Mar 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) <
[email-masked]> wrote:

> Hi CFRG and SecDir,
>
> Ted Krovetz has asked for publication of ...
>
> https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/
> ...and...
> https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/
>
> ...in the Independent Stream.
>
> These are both currently in expired state, but available in the archive.
>
> At this stage I am looking to know whether anyone feels that publication
> would be a bad thing:
> - at this stage
> - ever
>
> Please send me your opinions direct (I am not subscribed to this list, but
> will check the archives).
>
> Please also let me know if you would be willing to be a detailed reviewer
> of this work.
>
> Thanks,
> Adrian
> --
> Adrian Farrel (ISE),
> [email-masked]
>
>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 8 Apr 2019 12:30:17 +0000

Well, we *are* interested in OCB and ciphers with block size != 128 bits, even if we won't necessarily document our use in another RFC.

Thus, I see your point but disagree with it's apparent conclusion. IMHO the OCB draft should be published. 

Not sure about RC{5,6} - not my cup of tea.

Regards,
Uri

Sent from my iPhone

> On Apr 8, 2019, at 08:21, Eric Rescorla <[email-masked]> wrote:
> 
> The existing OCB document [RFC 7253] is cited by exactly zero RFCs (https://datatracker.ietf.org/doc/rfc7253/referencedby/), so having a specification for ciphers with block size != 128 seems of particularly low value. 
> 
> The existing RC5 document [RFC 2040] has 6 RFC-level citations, but as far as I know, RC5 has practically no usage in IETF protocols. AFAICT, RC6 isn't even specified in an RFC. Thus, test vectors for these algorithms don't seem that interesting.
> 
> -Ekr
> 
> 
> 
> 
> 
>> On Fri, Mar 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) <[email-masked]> wrote:
>> Hi CFRG and SecDir,
>> 
>> ....and...
>> ....in the Independent Stream.
>> 
> _______________________________________________
> Cfrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 8 Apr 2019 12:36:55 +0000

P.S. Regardless, the Value/Cost of publishing approaches infinity. ;-)

Regards,
Uri

Sent from my iPhone

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 8 Apr 2019 05:39:49 -0700

On Mon, Apr 8, 2019 at 5:30 AM Blumenthal, Uri - 0553 - MITLL <
[email-masked]> wrote:

> Well, we *are* interested in OCB and ciphers with block size != 128 bits,
> even if we won't necessarily document our use in another RFC.
>

Why does having it documented in an RFC assist that? It's not difficult to
find a description of OCB.

-Ekr

---

From: mcgrew <[email-masked]>
Date: Mon, 8 Apr 2019 09:32:08 -0400

Hi Uri,

> On Apr 8, 2019, at 8:30 AM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> 

The draft on OCB with general block size needs more usage guidance, as I discussed with Ted and you when the drafts were first discussed last year (please see https://cfrg.irtf.narkive.com/QRDFp12y/rfcs-for-wider-block-rc6-and-ocb#post5).   It is really important that an RFC provide strong guidance to users, as their target audience is implementers and users that might not understand the security ramifications.   I am not opposed to publishing this draft, but I see it as a critical next step to fully document the interest that you mention, either in draft-krovetz-ocb-wideblock or in a document that can be referenced by that one, along with usage guidance on when it is a good idea to do AEAD with a wide block cipher or a small block cipher.   

The general block size draft would be more appealing if it could be tied to a w != 128 cipher that has withstood significant significant cryptanalysis.   For smaller block sizes, this could be one of the modern 64-bit ciphers like PRESENT, SIMON, or SPECK, though I don’t think we should be promoting the use of 64-bit modes of operation for general-purpose use.   For implementation environments where a 64-bit cipher fits better than AES, it would be really attractive to use an AEAD mode that is secure beyond the birthday bound, as a way to compensate for the significant security degradation due to short blocks.   It would be great if we could leverage whatever interest there is in small block ciphers into some momentum towards higher-security modes of operation.  

It looks like the drafts haven’t been updated since they were first posted, though Ted expressed a willingness to update them.

Thanks

David

> On Apr 8, 2019, at 08:21, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> The existing OCB document [RFC 7253] is cited by exactly zero RFCs (https://datatracker.ietf.org/doc/rfc7253/referencedby/ <https://datatracker.ietf.org/doc/rfc7253/referencedby/>), so having a specification for ciphers with block size != 128 seems of particularly low value. 
>> 
>> On Fri, Mar 8, 2019 at 9:20 AM RFC ISE (Adrian Farrel) <[email-masked] <mailto:[email-masked]>> wrote:
>> Hi CFRG and SecDir,
>> 
>> https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/ <https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/>
>> ....and...
>> https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/ <https://datatracker.ietf.org/doc/draft-krovetz-rc6-rc5-vectors/>
>> 
>> [email-masked] <mailto:[email-masked]>
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 8 Apr 2019 21:38:15 +0000

Hi Uri,

The draft on OCB with general block size needs more usage guidance, as I discussed with Ted and you when the drafts were first discussed last year (please see https://cfrg.irtf.narkive.com/QRDFp12y/rfcs-for-wider-block-rc6-and-ocb#post5).   

Yes I remember. I will remind Ted.

It is really important that an RFC provide strong guidance to users, as their target audience is implementers and users that might not understand the security ramifications.  

Yes I agree with your point here. 

I am not opposed to publishing this draft, 

Thanks

but I see it as a critical next step to fully document the interest that you mention, either in draft-krovetz-ocb-wideblock or in a document that can be referenced by that one, along with usage guidance on when it is a good idea to do AEAD with a wide block cipher or a small block cipher.

I think it would not be proper to document *my* interest. What IMHO would be good is documenting use cases, benefits and caveats of using blocks wider and shorter than 128 bits.

The general block size draft would be more appealing if it could be tied to a w != 128 cipher that has withstood significant significant cryptanalysis.   

Shorter blocks are for special applications only (or for classroom exercises). Longer blocks weren’t 

For smaller block sizes, this could be one of the modern 64-bit ciphers like PRESENT, SIMON, or SPECK, though I don’t think we should be promoting the use of 64-bit modes of operation for general-purpose use.   

When AES-NI is in most every moderately large CPU? Nah, I’m not suggesting that we promote *general-purpose* use of 64-bit blocks. As I said, special applications only. In general, “you cannot get fired for selecting 128-bit block AES (and in my case – with 256-bit key)”. 😉

For implementation environments where a 64-bit cipher fits better than AES, it would be really attractive to use an AEAD mode that is secure beyond the birthday bound, as a way to compensate for the significant security degradation due to short blocks.   It would be great if we could leverage whatever interest there is in small block ciphers into some momentum towards higher-security modes of operation.  

That I’d need to discuss with Phil and Ted. I did not consider wide/generic use of short blocks.

I’ll need to get hold of Ted. Somehow his email eludes me right now (thanks, IT, for restoring only part of my email folders after the crash).

Thanks!

Regards, 

Uri

Sent from my iPhone

-Ekr

 

Hi CFRG and SecDir,

Thanks,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

---

From: mcgrew <[email-masked]>
Date: Mon, 8 Apr 2019 17:59:10 -0400

Hi Uri,

Please see inline:

> On Apr 8, 2019, at 5:38 PM, Blumenthal, Uri - 0553 - MITLL <[email-masked]> wrote:
> 
> Hi Uri,
> 
> 
>> On Apr 8, 2019, at 8:30 AM, Blumenthal, Uri - 0553 - MITLL <[email-masked] <mailto:[email-masked]>> wrote:
>>  
> The draft on OCB with general block size needs more usage guidance, as I discussed with Ted and you when the drafts were first discussed last year (please see https://cfrg.irtf.narkive.com/QRDFp12y/rfcs-for-wider-block-rc6-and-ocb#post5 <https://cfrg.irtf.narkive.com/QRDFp12y/rfcs-for-wider-block-rc6-and-ocb#post5>).   
>  
> Shorter blocks are for special applications only (or for classroom exercises).

OCB with a w < 128 bit block cipher is a authenticated encryption mechanism, not a length-preserving cipher, so I don’t understand what special applications there are.  

Classroom exercise don’t need an RFC.  If there is no real-world use case where we would recommend that someone use OCB with a w < 128 bit block cipher, then we shouldn’t include that option in an RFC.   

> Longer blocks weren’t 

Essentially the same issue arises with w > 128; what block ciphers have seen enough cryptanalytic scrutiny at that width such that we would feel good recommending their use in some situations?   

Thanks

David

>>>> https://datatracker.ietf..org/doc/draft-krovetz-ocb-wideblock/ <https://datatracker.ietf.org/doc/draft-krovetz-ocb-wideblock/>
>>>> ....and...
>>>> [email-masked] <mailto:[email-masked]>_______________________________________________
>>> Cfrg mailing list

---

From: Ted Krovetz <[email-masked]>
Date: Mon, 8 Apr 2019 15:13:43 -0700

> On Apr 8, 2019, at 6:32 AM, mcgrew <[email-masked]> wrote:
> 

I have not updated anything as of now because my sense is that the consensus will not be there for CFRG to adopt this project. Additionally, there appears to be some agreement that crypto should not go through the independent stream. That leaves this route as a likely dead end.

If this work does not become an RFC, I'd still like to publish it in some stable way so that people could use it. Any suggestions?

---

From: Benjamin Kaduk <[email-masked]>
Date: Mon, 8 Apr 2019 17:29:58 -0500

> If this work does not become an RFC, I'd still like to publish it in some stable way so that people could use it. Any suggestions?

There are probably a lot of options, including self-hosting (if you have a
stable web space already) and publishing an I-D with a "tombstone" notice
about "this document is not intended for publication as an RFC, but this
revision is expected to be the final revision, and it is intended to have
some use cases in this form".

-Ben