Re: [Cfrg] RFC 5742 conflict review for draft-dolmatov-kuznyechik

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

On 2/3/16, 5:23 , "Simon Josefsson" <[e-mail]> wrote:

>"Blumenthal, Uri - 0553 - MITLL" <[e-mail]> writes:
>>>>I see a problem with publishing descriptions of national ciphers
>>>>without
>>>guidance on suitable use and relevant applicability statements.
>>
>> The only guidance I see is: if you need "it" or are required to use
>>"it" -
>> do so, but be aware that people outside of your policy domain may not
>> interoperate with you using “it” because they may not have “it”
>> implemented. Implementing “it” is not required to be <whatever
>> protocol>-compliant.
>
>Where do you see this guidance?  I can't find anything like that in the
>draft.  

Ach… I meant “I see” like “I envision”, not like “it’s already in the
document”. :-(

>   The cryptographic algorithms specified in this Standard are designed
>   both for hardware and software implementation.  They comply with
>   modern cryptographic requirements, and put no restrictions on the
>   confidentiality level of the protected information.
>
>   The Standard applies to developing, operation, and modernization of
>   the information systems of various purposes.
>
>To me this suggests broad applicability.

Frankly, I don’t see why “it” (those other-than-AES algorithms) shouldn’t
be “broadly applicable”. AES is mandatory to implement to provide
interoperability. There’s nothing inherently holy about it. If two
communicating entities (which both must have AES support to be compliant)
happened to implement, e.g., Camellia, and want to communicate using it -
it’s not my business (and not your business) to tell them not to.

>I would expect to find a discussion on applicability in the Introduction
>or in the Security Considerations.

Introduction - yes.

Security Considerations??? That would apply if there were specific
weaknesses or vulnerabilities exposed by using the given algorithm - in
which case you want to inform the reader/implementor of what those are,
and how best to avoid/mitigate them. In the given case, for all we know
these ciphers are as good as AES. Unless you found (or have read about) an
attack and care to share it here..?

So AFAIS the only thing one can add there (and stay honest/unbiased) is
something like “this algorithm is relatively new, and enjoyed less
attention of the cryptographic community and academia than AES. Thus it is
likelier that a problem could be found in it, than in AES who has been
under scrutiny for the last 16 years."

>For those who didn't read, the security considerations is:
>
>   6.  Security Considerations
>
>   This entire document is about security considerations.
>
>Which leaves a lot to desire.

Hmm, yes. See above - would that make you happier? ;)


>>Do you envision some other kind of guidance?
>
>Yes, see the last paragraph of:
>https://www.ietf.org/mail-archive/web/cfrg/current/msg07876.html

No. Disagree with that email in general, and especially its last
paragraph. Will object against adding it.