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

["Dan Harkins" <[e-mail]>]

On Thu, February 4, 2016 11:00 am, Watson Ladd wrote:
> On Feb 4, 2016 9:18 AM, "Dan Harkins" <[e-mail]> wrote:
>>
>> On Wed, February 3, 2016 8:09 am, Blumenthal, Uri - 0553 - MITLL wrote:
>> > On 2/3/16, 5:23 , "Simon Josefsson" <[e-mail]> wrote:
>> >
>> >>   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.
>>
>>   Amen! Agree. +1 and all that.
>
> Is that what actually happens? Or do administrators and programmers have
> no
> clue about which primitives are secure, and assume that the protocols will
> provide security no matter how configured? We can also add in the disaster
> that is the usual API for using these standards, thanks to all the
> complexity that implementations feel a need to offer.

  I'm sure you can find anecdotal evidence that runs the gamut of
experience and clue.

> We got very badly bitten by making experimental RFCs for MD5 and RC4.
> Negotiation of options has only recently been analyzed and is still
> something of a dark art, despite wide consensus ylthst it is necessary.

  As the author of RFC 2409 I know all about the problems with options.
You can negotiate the Tiger hash function in IKE. Why? No reason at all!
There are 2 kinds of authentication using public key encryption that
can be negotiated in IKE. Why? Long, ugly, story. Options... ugh.

> We probably shouldn't endorse NONE, and probably should seek out more
> review of ciphers are are considering adopting, especially if it is an AES
> lookalike.

  That's the thing, we're not "endorsing" anything. There is no imprimatur
of the IETF, or the CFRG, to this publication. As Uri noted, it is none
of our business if two people want to use a non-MTI cipher to communicate
to each other.

  Dan.