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

[mcgrew <[e-mail]>]

Hi Uri,

Please see inline:

> On Apr 8, 2019, at 5:38 PM, Blumenthal, Uri - 0553 - MITLL <[e-mail]> wrote:
> 
> Hi Uri,
> 
> 
>> On Apr 8, 2019, at 8:30 AM, Blumenthal, Uri - 0553 - MITLL <[e-mail] <mailto:[e-mail]>> 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.
>  
> 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>).   
>  
> 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).

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

> 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.
>  
> It looks like the drafts haven’t been updated since they were first posted, though Ted expressed a willingness to update them.
>  
> 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!
>  
>  
>>  
>> 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 <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>>> 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/ <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) <[e-mail] <mailto:[e-mail]>> wrote:
>>>> Hi CFRG and SecDir,
>>>> 
>>>> Ted Krovetz has asked for publication of ...
>>>> 
>>>> 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/>
>>>> 
>>>> ....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),
>>>> [e-mail] <mailto:[e-mail]>_______________________________________________
>>> Cfrg mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>
>> _______________________________________________
>> Cfrg mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.irtf.org/mailman/listinfo/cfrg
> 
> 
> 
> _______________________________________________
> Cfrg mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>