Re: [saag] Improving the CHAP protocol

"Black, David" <David.Black@dell.com> Wed, 18 September 2019 20:03 UTC

Return-Path: <David.Black@dell.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 CB806120C47 for <saag@ietfa.amsl.com>; Wed, 18 Sep 2019 13:03:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=dell.com header.b=HjHlM5jy; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=rl4F0/rJ
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 HUtRgoUxXCbp for <saag@ietfa.amsl.com>; Wed, 18 Sep 2019 13:03:14 -0700 (PDT)
Received: from mx0b-00154904.pphosted.com (mx0b-00154904.pphosted.com [148.163.137.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66B36120CAD for <saag@ietf.org>; Wed, 18 Sep 2019 13:02:50 -0700 (PDT)
Received: from pps.filterd (m0170397.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8IJxqwv010180; Wed, 18 Sep 2019 16:02:46 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=g6OWuF4Cqt/LZkOZdoWaGlUhj3kLTAiDL5dlMr1PgqM=; b=HjHlM5jyCw1GDihUtik11HvoJhY1D4NqUpqO7vb24wUApZWru81s7Sg+tuHjdTrv0EWN G476GRjTmA1in/cLP+a/0RpXmdkjqOYxVHPku5BCYNGEo3aAdWnNzI+ZYTCN+ysPiqMs 999dsKKxFqXvqqzbp7ib3nQ8syI1O7WD1vbqo11C1DlaqP3QgoTE/+9Q6+R8JKsYBNtA 6eidBlfZZt19UIelCSsSQGR+04RSX6pT4wQUiwLQfCeRpAmq0obqa6G0QtpONWmVwJb2 2p2LbN52uuxzmKVXJhz8qTB0cLbjihF2Fi+lZdBMqZdBFCblHqfJXZZgcJ+WK7LMsJMb zg==
Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2v37suedkv-2 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Sep 2019 16:02:46 -0400
Received: from pps.filterd (m0134318.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8IJRe1M165718; Wed, 18 Sep 2019 15:32:47 -0400
Received: from mailuogwhop.emc.com (mailuogwhop-nat.lss.emc.com [168.159.213.141] (may be forged)) by mx0a-00154901.pphosted.com with ESMTP id 2v3829ga5x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 18 Sep 2019 15:32:47 -0400
Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8IJWd9i016517 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 18 Sep 2019 15:32:46 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd04.lss.emc.com x8IJWd9i016517
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1568835166; bh=Vlx54g90ukIg/MDVhLKkeLNKwuY=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=rl4F0/rJ5hYw51Z4wKWc4dPGFMWRbVll2IBfSZsd9zrSIYaYDHO33UZBXl/+1v80t NxfmzlnmagZZ5i7PJQ5gx3lDxC/Gr1I5HuD3qIRBvnRPyk0GCIlWxwk3rsMxCRtRPt C37oGQT4vn19EUxGRESn1yeiNLKWxonGqreb2sS4=
Received: from mailusrhubprd54.lss.emc.com (mailusrhubprd54.lss.emc.com [10.106.48.19]) by maildlpprd04.lss.emc.com (RSA Interceptor); Wed, 18 Sep 2019 15:32:16 -0400
Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8IJWIQc027608 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 18 Sep 2019 15:32:19 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB313.corp.emc.com ([10.146.3.91]) with mapi id 14.03.0439.000; Wed, 18 Sep 2019 15:31:29 -0400
From: "Black, David" <David.Black@dell.com>
To: "Mark D. Baushke" <mdb=40juniper.net@dmarc.ietf.org>, Maurizio Lombardi <mlombard@redhat.com>
CC: "saag@ietf.org" <saag@ietf.org>
Thread-Topic: [saag] Improving the CHAP protocol
Thread-Index: AQHVbhyVNSLAH6mw10yrI1pLte3B86cx18CA///4JYA=
Date: Wed, 18 Sep 2019 19:31:28 +0000
Message-ID: <CE03DB3D7B45C245BCA0D2432779493630702B7F@MX307CL04.corp.emc.com>
References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <19010.1568821685@contrail-ubm16-mdb.svec1.juniper.net>
In-Reply-To: <19010.1568821685@contrail-ubm16-mdb.svec1.juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Enabled=True; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SiteId=945c199a-83a2-4e80-9f8c-5a91be5752dd; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Owner=david.black@emc.com; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_SetDate=2019-09-18T19:30:04.1006695Z; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Name=External Public; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Application=Microsoft Azure Information Protection; MSIP_Label_17cb76b2-10b8-4fe1-93d4-2202842406cd_Extended_MSFT_Method=Manual; aiplabel=External Public
x-originating-ip: [10.238.21.131]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd54.lss.emc.com
X-RSA-Classifications: public, Resumes
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-18_09:2019-09-18,2019-09-18 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 phishscore=0 priorityscore=1501 impostorscore=0 adultscore=0 spamscore=0 clxscore=1011 mlxlogscore=822 lowpriorityscore=0 malwarescore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909180167
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=916 suspectscore=0 phishscore=0 spamscore=0 clxscore=1011 adultscore=0 priorityscore=1501 lowpriorityscore=0 bulkscore=0 impostorscore=0 mlxscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909180170
Archived-At: <https://mailarchive.ietf.org/arch/msg/saag/7PTjZB4EARYRb0c4z5eq57ombHY>
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: Wed, 18 Sep 2019 20:03:19 -0000

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.

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