IETF Logo Mail Archive

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

Watson Ladd <watsonbladd@gmail.com> Thu, 04 February 2016 19:00 UTC

Return-Path: <watsonbladd@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC3C1ACD8A for <cfrg@ietfa.amsl.com>; Thu, 4 Feb 2016 11:00:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U2biIsGQZe9W for <cfrg@ietfa.amsl.com>; Thu, 4 Feb 2016 11:00:17 -0800 (PST)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 276181ACD74 for <cfrg@irtf.org>; Thu, 4 Feb 2016 11:00:17 -0800 (PST)
Received: by mail-yw0-x22a.google.com with SMTP id q190so32574240ywd.3 for <cfrg@irtf.org>; Thu, 04 Feb 2016 11:00:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=vISEbU/q2OvLUdGAPT52JYEmKz7vCGBjR/0ELVHyxlA=; b=jr7BlRATNlcYKkH9oJQDuPnOKVKKLBSY47rKpI1ECXtAEhib2YKRIlgUMcDJgjm/cY kPfBRD2d1JPEdtw8KYUls1HHdl3wkPhK8iuatLnMJlOafdMoi1a4gF75LZjCv/oWtvH1 bZN0uDik8z1SeYA4/JNAvBlsACOeZ+uCVstA1GguALIRhnsxGWWTS4bcJHiLHSww7cIT XMbL/fIttygV2aHKlGbVuVsQh/t+ioPIPlk4z3UciPgHNqsqK7x72l5P6HGrmF0Lj4/O r+UPfe+2bWzFD8KTWHVJ/tSVy/SjiZmIOrFiNLmOfjyP8tJbMOrDuEbdHKgZahNUeMIb ARjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=vISEbU/q2OvLUdGAPT52JYEmKz7vCGBjR/0ELVHyxlA=; b=lsbgXzhUbxdVdZ5ZOmfHn4nepUHFT+k+PXZWmVZir99kldi2oXCnUYTtEkiGtNdQ0d WEv563IUQ+6XYMklN47jttbPAQc1PQ7pD7PhtDhAu1AtJKtlPfJ3YldNRh32+M3gpd8B uG7PhfK2owT1I+K5x+TLlCqB7YYbdTP+flGGdSpCAt1qrZ5YZ5Bd+0uW3+qN3orC68F0 FJ/sxZmQy62fCSw9SLIf1r2EdtYmUNH+t5w5L6McLRlTpP1qq4KKcJlPfHlAlLQLpO1X 3eDzsS6jTmkQNtiJMHaRqgeGJEjUJgc+KoRfTkLcu3i6JvY6FLr6+j5AMcJxe3THoe/v 5I4Q==
X-Gm-Message-State: AG10YOSQVKS0IXzq3LUlsSCp3OV2WuepmmIm9VyRSaZu9sxQw4hdZvtw54+0BTZUbXTUdeXicwpX4UNGoO7Dsg==
MIME-Version: 1.0
X-Received: by 10.129.45.2 with SMTP id t2mr4700812ywt.182.1454612416296; Thu, 04 Feb 2016 11:00:16 -0800 (PST)
Received: by 10.13.216.138 with HTTP; Thu, 4 Feb 2016 11:00:15 -0800 (PST)
Received: by 10.13.216.138 with HTTP; Thu, 4 Feb 2016 11:00:15 -0800 (PST)
In-Reply-To: <b0a5edfea0df3670d5526d488dc731d1.squirrel@www.trepanning.net>
References: <4A631584-C0F1-4AFC-A51D-155C34415413@isode.com> <D2D64C5B.61B8F%kenny.paterson@rhul.ac.uk> <CADqLbz+b-YQ10d6d5_GHN+r7ETWobQgq+skPyXQSdUGG1dBDqQ@mail.gmail.com> <CACsn0c=ErkJLja7QUbA06V7vH-KPR_MpTcPhPyrKfyV02bxq-w@mail.gmail.com> <D2D65F65.266E2%uri@ll.mit.edu> <87a8nix2od.fsf@latte.josefsson.org> <D2D68F83.26762%uri@ll.mit.edu> <871t8uw0sb.fsf@latte.josefsson.org> <D2D78DD6.2680E%uri@ll.mit.edu> <b0a5edfea0df3670d5526d488dc731d1.squirrel@www.trepanning.net>
Date: Thu, 04 Feb 2016 11:00:15 -0800
Message-ID: <CACsn0c=OcJP6jzne9hHp67U6ZVpBssK1y=4zu1UW8+V=brUF0w@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Dan Harkins <dharkins@lounge.org>
Content-Type: multipart/alternative; boundary="001a11428d3e5c00b1052af658cc"
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/qzNr0EA7XOXxUYfTtuYrWMcUYvE>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] RFC 5742 conflict review for draft-dolmatov-kuznyechik
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2016 19:00:19 -0000

On Feb 4, 2016 9:18 AM, "Dan Harkins" <dharkins@lounge.org> wrote:
>
>
> On Wed, February 3, 2016 8:09 am, Blumenthal, Uri - 0553 - MITLL wrote:
> > On 2/3/16, 5:23 , "Simon Josefsson" <simon@josefsson.org> 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.

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.

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.
>
>   Dan.
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg

v2.23.0 | Report a Bug | By Email