Re: [saag] Improving the CHAP protocol

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Thu, 19 September 2019 10:11 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: saag@ietfa.amsl.com
Delivered-To: saag@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D370120137 for <saag@ietfa.amsl.com>; Thu, 19 Sep 2019 03:11:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 fKHIOsQm8lUv for <saag@ietfa.amsl.com>; Thu, 19 Sep 2019 03:11:43 -0700 (PDT)
Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 3C7E01200F4 for <saag@ietf.org>; Thu, 19 Sep 2019 03:11:43 -0700 (PDT)
Received: by mail-qt1-x836.google.com with SMTP id o12so3517218qtf.3 for <saag@ietf.org>; Thu, 19 Sep 2019 03:11:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aA2QGu+/miT2FmGZeBy/egNb44aPrzp0TszMttSWGZg=; b=XRjt3tgX+4LOgMdrHbR7s/3NfxYXchLXd1Wwk1d+4u8DIx8TP85tbqmVBjK52jFD8p bkbX1YkSqjLTwfDRtKx0oJT+nDxKYScAmMNDMDSULXhlJhNBQQl2GnOeJEorXhoVtDNL VeQZYK+iGQxrGv59yA8R+uCMLITNsg6z9ItfdKfpGFWrqZf6m7Sp9yJsPkau+QQq9XF6 7Ox65cqRALPwh0NWwl4eqRZVEfuutic3Jew4AxaGWswz7xtHSOt2kjG3+eCTq0xia6vv jMmwTtkqNrvBF12eqVTjuJW9X7REyJNBV46h10cYEcsZ51gQRAmuxZyYrqTaqKS7YAgL 4yWQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=aA2QGu+/miT2FmGZeBy/egNb44aPrzp0TszMttSWGZg=; b=B/8gHFCQD28Bq+T1pZoDfiuhrwAc8FdXE+Dap5G6pbJDz7waUwG3k84jcEdmEBkooH J6WJkp+aFpqCFUAn2WJK/3DdQyQfoNjIJ7nVPL2AdoUzb1jE0ZXh+52DiGbAFodri2jT Fmx4bkSn4U387lCH6HFTA3CZWVBelubxOn3LZnAzyaWuX3jSJ9PmgOCyQDjnDDqHlf5O 9va00eNfaqPcf47FAZ/1JDR7pKTnBaSK/RbnrX2CLWJgKdCc7Ul7/VUH+00WuvZgKED7 nYaSBDNO5/N6A87xXx7S2GYXJMcg5ZKBMv3SJtoic7PiJZtQNTQ4j2pt6Ob9nszF3xML GJTg==
X-Gm-Message-State: APjAAAVjIZy26Z3YEdiNmqG6Q1p6gu2JNywqEB8ryjwZ3CbQGY4JKlNJ hLlFWZhRrJeh1OV85x2I2W8=
X-Google-Smtp-Source: APXvYqyA5cRCbdhoBVt1PHZqUiC8g9StC6FPOH7mC8fdWCC3YBLcng5V1kchkq9vdlGnwwZbOFGR4w==
X-Received: by 2002:ac8:822:: with SMTP id u31mr2262034qth.328.1568887902297; Thu, 19 Sep 2019 03:11:42 -0700 (PDT)
Received: from [192.168.1.4] (146-115-73-78.s5196.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [146.115.73.78]) by smtp.gmail.com with ESMTPSA id t17sm5889556qtt.57.2019.09.19.03.11.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Sep 2019 03:11:41 -0700 (PDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (1.0)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Mailer: iPhone Mail (16G102)
In-Reply-To: <CE03DB3D7B45C245BCA0D2432779493630702B7F@MX307CL04.corp.emc.com>
Date: Thu, 19 Sep 2019 06:11:41 -0400
Cc: "Mark D. Baushke" <mdb=40juniper.net@dmarc.ietf.org>, Maurizio Lombardi <mlombard@redhat.com>, "saag@ietf.org" <saag@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <F2B9DC21-4A23-4CE0-A82B-906B94C9F0E3@gmail.com>
References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <19010.1568821685@contrail-ubm16-mdb.svec1.juniper.net> <CE03DB3D7B45C245BCA0D2432779493630702B7F@MX307CL04.corp.emc.com>
To: "Black, David" <David.Black@dell.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/glA2wogY4ggwLUvB4vV_IfkpGow>
Subject: Re: [saag] Improving the CHAP protocol
X-BeenThere: saag@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Security Area Advisory Group <saag.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/saag>, <mailto:saag-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/saag/>
List-Post: <mailto:saag@ietf.org>
List-Help: <mailto:saag-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/saag>, <mailto:saag-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Sep 2019 10:11:46 -0000


Sent from my mobile device

> On Sep 18, 2019, at 3:31 PM, Black, David <David.Black@dell.com>; wrote:
> 
> Hi Mark,
> 
> Thank you very much for your comments and explanation - it seems that SHA2-512/256 is the better choice of SHA-2 hash (than SHA2-256) on both security and performance grounds.  My 0.02 is that fewer options are better here, so I'd register only SHA2-512/256 for SHA2, in addition to registering SHA3-256.
> 
> The registration procedure for the PPP Authentication Algorithms registry (https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xhtml#ppp-numbers-9) [iSCSI uses this by reference] is Expert Review, so we can submit the registration requests directly to IANA (e.g., don't need an Internet-Draft).  That said, I'd be happy to bring these requests to secdispatch in Singapore if there's a sense that more "eyes" should take a look at the requests (including the choice of algorithms) before the requests are submitted to IANA.

That shouldn’t be necessary, I should have looked at the registration policy.

Thank you,
Kathleen 

> 
> Thanks, --David
> ----------------------------------------------------------------
> David L. Black, Senior Distinguished Engineer
> Dell EMC, 176 South St., Hopkinton, MA  01748
> +1 (774) 350-9323 New    Mobile: +1 (978) 394-7754
> David.Black@dell.com
> ----------------------------------------------------------------
> 
>> -----Original Message-----
>> From: saag <saag-bounces@ietf.org>; On Behalf Of Mark D. Baushke
>> Sent: Wednesday, September 18, 2019 11:48 AM
>> To: Maurizio Lombardi
>> Cc: saag@ietf.org
>> Subject: Re: [saag] Improving the CHAP protocol
>> 
>> 
>> [EXTERNAL EMAIL]
>> 
>> Hi Maurizio,
>> 
>> Summary: SHA2-512/256 looks good to me. You may also wish to consider
>>         SHAKE128(M,256) or SHAKE256(M,256) generating 256 bits.
>> 
>> Long reply:
>> 
>> See "Comparing Hardware Performance of Round 3 SHA-3 Candidates using
>> Multiple Hardware Architectures in Xilinx and Altera FPGAs"
>> https://pdfs.semanticscholar.org/20e2/3a26384b0edc4a218d2d180f0658c1c9
>> a05f.pdf
>> and look for Keecak vs SHA-2 results.
>> 
>> Doing SHA3 in hardware is going to be faster than doing SHA2 in
>> hardware.
>> 
>> Doing SHA3 in software is going to be much slower than doing SHA2 in
>> software.
>> 
>> Comparing SHA2-256 to SHA2-512/256 in software depends on the native
>> size of a CPU word.
>> 
>> On a 64bit CPU, I beleve that doing a SHA2-256 will be slower than
>> doing a SHA2-512/256 on the order of 30% (best to run your own
>> benchmarks using something like 'openssl speed').
>> 
>> Per FIPS Publication 202, for SHA3, to get 256-bits of hash, there are
>> alternatives: SHA3-256, and the two Extendable-Output Functions (XOF):
>> SHAKE128 and SHAKE256. (There is no definition for SHA3-512/256.)
>> 
>> I have not done any software performance analysis of SHA3 functionality,
>> however, the https://keccak.team/2017/is_sha3_slow.html shows that using
>> the XOF functions are on performance part with SHA-2 on common
>> processors.
>> 
>> Considering longer term safety of the 256-bit hashes...
>> 
>> The SHA2-512/256 keeps an internal state of 1024 bits and displays only
>> 256 bits of the finished hash. While SHA2-256 keeps an internal state of
>> 512 bits and displays half of it (256 bits), so from a data hiding point
>> of view is should be more secure to use SH2-512/256.
>> 
>> As the intention is cryptographic agility, I think that adding
>> SHA2-512/256 is a good idea.
>> 
>> It may also be desirable to consult with your FIPS experts to determine
>> if SHAKE{128,256} is acceptable to generate the 256-bits needed and be
>> FIPS 140-2 compliant.
>> 
>>    -- Mark
>> 
>> _______________________________________________
>> saag mailing list
>> saag@ietf.org
>> https://www.ietf.org/mailman/listinfo/saag
> 
> _______________________________________________
> saag mailing list
> saag@ietf.org
> https://www.ietf.org/mailman/listinfo/saag