From nobody Tue Sep 3 22:04:57 2019 Return-Path: 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 DC22412081E for ; Tue, 3 Sep 2019 22:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.099 X-Spam-Level: X-Spam-Status: No, score=-4.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PLING_QUERY=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 prCc7LKMOJtK for ; Tue, 3 Sep 2019 22:04:46 -0700 (PDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 CC339120108 for ; Tue, 3 Sep 2019 22:04:45 -0700 (PDT) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x8454f8E004951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 4 Sep 2019 01:04:44 -0400 Date: Wed, 4 Sep 2019 00:04:41 -0500 From: Benjamin Kaduk To: saag@ietf.org Message-ID: <20190904050440.GB58050@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.10.1 (2018-07-13) Archived-At: Subject: [saag] Interested in chairing a WG? Let us know! X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Sep 2019 05:04:56 -0000 Dear all, The security area has been fortunate enough in recent history to have a solid pipeline of candidates for WG leadership positions, but we should not grow complacent and come to rely on that continuing to be the case! Roman and I would like to have a pool of candidates to select from for any given position. Such a pool lets us tailor the match between the position, and the skills and potential of the candidates in question. I'm sending this note to help make sure we've got the broadest pool available. If you are interested in chairing, please email us privately or find us at any meeting. (Co-chairing with an experienced chair is a great way to learn more about the IETF and how to work here effectively!) Even if you think you're not quite ready but will eventually be interested, or cannot be a chair right now but will want to be in the future if time/work commitments change, please let us know that you're thinking about it as a possibility. We can check back with you when an opportunity or three does arise. (And of course, if you're ready to start tomorrow, we want to hear about that, too!) On a related note, just as it's nice to have a pool of candidates to choose from for a WG chair, the NomCom likes to have a pool of candidates when finding ADs. My term is up for selection this cycle. Although I expect to stand for a second term, I do think there's value in the NomCom having a diverse pool, and I would be happy to see a group of qualified candidates standing alongside me so the NomCom can make the best choice for the IETF. If you are or might be interested, see https://datatracker.ietf.org/nomcom/2019/. Thanks, and looking forward to talking to you, Ben From mlombard@redhat.com Wed Sep 18 05:25:30 2019 Return-Path: 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 D73161201E5 for ; Wed, 18 Sep 2019 05:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 AfuDOlXBxvf8 for ; Wed, 18 Sep 2019 05:25:28 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDBD812004D for ; Wed, 18 Sep 2019 05:25:27 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id ACB7810C0928 for ; Wed, 18 Sep 2019 12:25:26 +0000 (UTC) Received: from [10.35.206.36] (unknown [10.35.206.36]) by smtp.corp.redhat.com (Postfix) with ESMTP id EA0C81048134 for ; Wed, 18 Sep 2019 12:25:25 +0000 (UTC) To: saag@ietf.org From: Maurizio Lombardi Message-ID: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> Date: Wed, 18 Sep 2019 14:25:23 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx1.redhat.com [10.5.110.66]); Wed, 18 Sep 2019 12:25:26 +0000 (UTC) Archived-At: Subject: [saag] Improving the CHAP protocol X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 12:28:17 -0000 Hello, I am working to solve the problem of FIPS (Federal Information Processing Standards) compliance with the iSCSI/CHAP authentication protocol. CHAP is described in RFC 1994: https://tools.ietf.org/html/rfc1994. This email is to start discussion, and look for guidance. All the major implementations of CHAP for iSCSI use MD5 as the only supported hash function. Unfortunately, MD5 is now considered insufficient for FIPS and isn’t allowed it to be used on FIPS-enabled systems. As a consequence, when FIPS mode is active, the CHAP authentication doesn’t work. As reported by IANA, the SHA1 algorithm could be used as an alternative to MD5: https://www.iana.org/assignments/ppp-numbers/ppp-numbers.xml#ppp-numbers-9 but the use of SHA1 on FIPS systems has been deprecated and will soon be phased out. I therefore proposed to add a more modern hash algorithm (like SHA3-256) to the list of approved CHAP authentication algorithms. David Black suggested to consider adding SHA-256 and SHA-512/256 in addition to SHA3-256 and asked me to send an email to this mailing list: David Black wrote: ------------- My sense of the IETF view on secure hashes is that MD5 and SHA1 are broken, whereas \ the SHA2 algorithms are proving to be longer-lived (more resistant to attack) than \ expected, and the SHA3 algorithms are fine. That suggests that registration of codepoints for both SHA2 and SHA3 would be a good \ thing to do, as opposed to only SHA3. I'd suggest starting with either SHA-256 or \ SHA-512/256 (both are SHA2 hashes) in addition to SHA3-256, as all three have the \ same 256-bit output size. Figuring out exactly what should be done here (e.g., which SHA2 variant to register) \ would benefit from some discussion at IETF. I would start with the Security Area's \ saag@ietf.org mailing list. In addition, as iSCSI falls within IETF's Transport \ Area, the Transport Area Directors ought to be looped in beforehand. ----------- https://marc.info/?l=target-devel&m=156755533912350&w=2 Thank you, Maurizio Lombardi From nobody Wed Sep 18 08:48:23 2019 Return-Path: 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 8BCBE12095E for ; Wed, 18 Sep 2019 08:48:20 -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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 T1vI0Mf2dII1 for ; Wed, 18 Sep 2019 08:48:18 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 42954120884 for ; Wed, 18 Sep 2019 08:48:18 -0700 (PDT) Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8IFYj0W012112; Wed, 18 Sep 2019 08:48:12 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=Tqpu61kFa+q6ipVFzFs4BHeaBTihf0zFQKJ7q6jLEoY=; b=v/MHCwOeq84MWf3sDB+enSi2/hlH+vqBWYS3P63hhxVh0JK962EUmMBsL9Veu/v3UXVK lZvaYSJutIZqNhwWiiAub1aULJl6mp3RGdD5kpMzU9zZ2To3cKUze73x2at6E0bCvM8u WAGQJsCCX+vwekKPrD/S8IBODRwlE/6c+jxk9ONwalGOl1Zu2jvalv9jStFLqqZHp9aq aZCxb0u5hXGDRA/c7WsKRbV860oCtaj5J7Cx7czNBoQ4UIIx0tysKSND08oQNLR5EtJb DkCR99aicmLZDaj1wPoiwJ5y8wBy/+8br5EGtgVYe1K1YjnuG1sJ7JLFU+OsfgMlfWIk 7A== Received: from nam04-co1-obe.outbound.protection.outlook.com (mail-co1nam04lp2058.outbound.protection.outlook.com [104.47.45.58]) by mx0b-00273201.pphosted.com with ESMTP id 2v3nt8872c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 18 Sep 2019 08:48:12 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=UZAvniy03UAKr8ivfgt6pgd2e7I1UbrBcrQZKTeiXtq35GIyJ+Ni5fydBemBFgQ0jSv/UOf+Z4Z6p5K07q5lpR6n/D7Xk1gLH15ZKva4QuxdWX5aE7Bc+npogu+tlGEH4t9A7K8LS07/6Qej8lupoGOpJPcqKI8gGZUqB7LiCyx/9BnA7/BfldAEhL5xl4cTmEIiR7Rcybh1WwjzenAXRR8Kt1jVWTFSXexb8RrD0XQ4hkEF7yxtjFxHDLxoYidPvVHiNRe7E2tts9zXmOQWmCJzEEaZFlIo0wnwxwSZkoXWGpq5JQRmxMhmdixoYMEojGeEIgTEwmZwc3cTvOMdQQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Tqpu61kFa+q6ipVFzFs4BHeaBTihf0zFQKJ7q6jLEoY=; b=ew6SCZwomDCpSJ8EggJ/TmXwPWTYwJNEED49W1E6qfBOkBkBbQ+c0nn8Ql344jxz/qxc+wn7kDHyGxbl1C25FUoudRGPlqz9FATMl4Lm3iPnFOzrxXAJrc4inQ/R/Jmi4gjahXSgEZgwz8t3epczYIR+rMGxTZswcfGH8uf5p3/eUZoK1rEQOgt2VtpCV4drv1027G2UIA0nvSe6TTa/sc+6Nd/DHbQypJZL/6vFzJtrD3cFK2SgoV0Q3FfbSqpn/ic9fyE93L/JyCA49KUsl/7MSquG/W0KAdVnoCXJt6ZCZTVerC+dyfae0kSpGQIK76SVr3X+yQL8z7a4cUEC3A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.13) smtp.rcpttodomain=ietf.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none Received: from CH2PR05CA0023.namprd05.prod.outlook.com (2603:10b6:610::36) by BN3PR05MB2753.namprd05.prod.outlook.com (2a01:111:e400:7bb4::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.10; Wed, 18 Sep 2019 15:48:07 +0000 Received: from DM3NAM05FT049.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::207) by CH2PR05CA0023.outlook.office365.com (2603:10b6:610::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2284.20 via Frontend Transport; Wed, 18 Sep 2019 15:48:07 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.13 as permitted sender) Received: from P-EXFEND-EQX-02.jnpr.net (66.129.239.13) by DM3NAM05FT049.mail.protection.outlook.com (10.152.98.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2284.10 via Frontend Transport; Wed, 18 Sep 2019 15:48:07 +0000 Received: from P-EXBEND-EQX-03.jnpr.net (10.104.8.56) by P-EXFEND-EQX-02.jnpr.net (10.104.8.55) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 18 Sep 2019 08:48:06 -0700 Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXBEND-EQX-03.jnpr.net (10.104.8.56) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 18 Sep 2019 08:48:06 -0700 Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 18 Sep 2019 08:48:06 -0700 Received: from contrail-ubm16-mdb.svec1.juniper.net ([10.163.18.199]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id x8IFm5ls021699; Wed, 18 Sep 2019 08:48:05 -0700 (envelope-from mdb@juniper.net) To: Maurizio Lombardi CC: In-Reply-To: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> Comments: In-reply-to: Maurizio Lombardi message dated "Wed, 18 Sep 2019 14:25:23 +0200." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <19009.1568821685.1@contrail-ubm16-mdb.svec1.juniper.net> Date: Wed, 18 Sep 2019 08:48:05 -0700 Message-ID: <19010.1568821685@contrail-ubm16-mdb.svec1.juniper.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.13; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(4636009)(376002)(39860400002)(136003)(396003)(346002)(199004)(189003)(51444003)(186003)(966005)(316002)(446003)(11346002)(47776003)(426003)(81166006)(6916009)(46406003)(8936002)(8676002)(70206006)(70586007)(478600001)(336012)(16586007)(117636001)(2906002)(486006)(305945005)(97756001)(6246003)(26005)(97876018)(86362001)(23726003)(81156014)(6306002)(50466002)(76176011)(126002)(476003)(356004)(5660300002)(14444005)(229853002)(7696005)(4326008)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR05MB2753; H:P-EXFEND-EQX-02.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 3b229d28-136f-41a3-34e0-08d73c4f99a3 X-Microsoft-Antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(4710121)(4711137)(1401327)(4618075)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328); SRVR:BN3PR05MB2753; X-MS-TrafficTypeDiagnostic: BN3PR05MB2753: X-MS-Exchange-PUrlCount: 2 X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:8882; X-Forefront-PRVS: 01644DCF4A X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam-Message-Info: h4iMY3h56+DhK9wtwUdWt35hKE0o9q/jbWWV3pLTRWJ7bxLY9I7w0PheK4Y8gCsfCTMf4QlwqPxoi9T9wJ9pR0Qm2TyCdR9uzIKzn+/H3A9QVUuTtaH2UiHl5VUmY/4z+L7shx11DARg/okIAWFAqgxOi+5ItJ+cNDRqOl3YOnazFAADJ7PxXcKgsVGsC7NCrnJF29enQyZtJ/aoD0kAXpzX2SDmhgiefckKjsKDlxvHlT/E0S/tpb1LPAEabu0TvgtoSOzbXr87eaJwrVDaOQo+ik5uBaZtnoS8hAG5X6bjjWD5fTzC486lUob+Cfzjp3UwPAaiM2iIecvtp03CyGjGElL2ukmTM6ladval2VzPwuCVA72BUBjykPtYBAaFWx42Oe/HNPwA02VFB+9HDKgEpgWQE7AcG7JOVVcvEGY= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Sep 2019 15:48:07.2766 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 3b229d28-136f-41a3-34e0-08d73c4f99a3 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.13]; Helo=[P-EXFEND-EQX-02.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR05MB2753 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.70,1.0.8 definitions=2019-09-18_08:2019-09-18,2019-09-18 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 spamscore=0 impostorscore=0 clxscore=1011 adultscore=0 lowpriorityscore=0 mlxlogscore=337 malwarescore=0 mlxscore=0 suspectscore=0 phishscore=0 bulkscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909180152 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 15:48:21 -0000 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/3a26384b0edc4a218d2d180f0658c1c9a05f.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 From nobody Wed Sep 18 09:23:03 2019 Return-Path: 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 057161200E0 for ; Wed, 18 Sep 2019 09:23:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 6tKPdnbxVcom for ; Wed, 18 Sep 2019 09:22:59 -0700 (PDT) Received: from mail-ot1-x32e.google.com (mail-ot1-x32e.google.com [IPv6:2607:f8b0:4864:20::32e]) (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 7D53712006A for ; Wed, 18 Sep 2019 09:22:59 -0700 (PDT) Received: by mail-ot1-x32e.google.com with SMTP id z26so410191oto.1 for ; Wed, 18 Sep 2019 09:22:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MetJ5qqyNmWihORo4HFUScfK/xM3lMaTR+kCBbOA168=; b=a/2A7xgdL7jxJ67EC7TS+nq3PsEbuSqrd0nG6HEnrfttYxU8bOr0CqWqIy2FWU3kEs Ngy4y1eL3v+BY0IMzCeFwI4aMdkho5dJaF3KFnnBMaldsBhWWxMF1xUY1lJ0Gdzr9w0q BeVPXZx+MxWxWJy5G2QJNR1PmA+uIau50iuny0l8Ao2qn/cqe6XKFvj1fZ5BjWDbOIzP /NUs/tsL9/4gZkweydsRlJ5GnCGvzJ6F31X4XBnrFRCz1Cyw+fOPGh95PyQbH1BoJhtF LGHQvxu9KNSl4QyKeedQUfiRhtFINA11tnO5rdWYjuWE4LidLyAon8WBXm14XNZ545Tg A8jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MetJ5qqyNmWihORo4HFUScfK/xM3lMaTR+kCBbOA168=; b=ew3k6cQeFG07aTEjltDyF2CmhqN3PC0YyH2n+wambNl2QZAccq8UiL3ct8bFjqMPLc SPqu8Fp+y/EghKiyRYzF1dQ/0xR32GmIq5JfCSeVK7zmQcSTqbnUyFB0YMGGhGazU1GP xm5kUCXmYt2ktzkAvnXy5aag7dPnJRlvOswT+WjVo3Si9Hnxg2OyXHD09MunNoUiwVvI IUKjBf9zV3XJNX6ZfL5iayJqahjIXfOTcMgS5HviCiAXzuOjmzrXMO5p4Yes7dAFGICZ JawmjhZ3Le749dWYdYApwFbb0Utni5mfhhjVH/ypS8GbgZHWXw31ezWNqjwx/cLI1lyb R6QQ== X-Gm-Message-State: APjAAAV+kHDiMAKkJc+IG+O7u2Xcv45z72ripGKUvIxQIHhl1pSEextD NzGybdD817P9C367Te8Xjew8DCd9dkE4gUHdXA2MbkVx X-Google-Smtp-Source: APXvYqyCcJNVgrkjmMfzceMbCnUomUvfsjB/wrOw6iiVdrRGep5+uTFEwdInPO1m9aaYm1JpT/hbdMxoB7zQr6syoHU= X-Received: by 2002:a05:6830:1bd4:: with SMTP id v20mr3706697ota.151.1568823778892; Wed, 18 Sep 2019 09:22:58 -0700 (PDT) MIME-Version: 1.0 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> From: Kathleen Moriarty Date: Wed, 18 Sep 2019 12:22:29 -0400 Message-ID: To: "Mark D. Baushke" Cc: Maurizio Lombardi , saag@ietf.org Content-Type: multipart/alternative; boundary="0000000000000e5f2d0592d64095" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Sep 2019 16:23:02 -0000 --0000000000000e5f2d0592d64095 Content-Type: text/plain; charset="UTF-8" Maurizio, This is the right place to start the discussion. If you pull together a draft before the deadline and want a slot to present at SecDispatch, send a message there as well. SecDispatch will help find a home for the draft, even if that is an AD sponsored draft (if there's not WG that is a fit). Best regards, Kathleen On Wed, Sep 18, 2019 at 11:48 AM Mark D. Baushke wrote: > 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/3a26384b0edc4a218d2d180f0658c1c9a05f.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 > -- Best regards, Kathleen --0000000000000e5f2d0592d64095 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maurizio,

This is the right place to st= art the discussion.=C2=A0 If you pull together a draft before the deadline = and want a slot to present at SecDispatch, send a message there as well.=C2= =A0 SecDispatch will help find a home for the draft, even if that is an AD = sponsored draft (if there's not WG that is a fit).

=
Best regards,
Kathleen

On Wed, Sep 18, 2019 at 11:48 AM= Mark D. Baushke <mdb=3D= 40juniper.net@dmarc.ietf.org> wrote:
Hi Maurizio,

Summary: SHA2-512/256 looks good to me. You may also wish to consider
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SHAKE128(M,256) or SHAKE256(M,256) genera= ting 256 bits.

Long reply:

See "Comparing Hardware Performance of Round 3 SHA-3 Candidates using<= br> Multiple Hardware Architectures in Xilinx and Altera FPGAs"
https://pdfs.semantics= cholar.org/20e2/3a26384b0edc4a218d2d180f0658c1c9a05f.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.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 -- Mark

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag


--

Best regards,
Kathleen
--0000000000000e5f2d0592d64095-- From nobody Wed Sep 18 13:03:20 2019 Return-Path: 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 ; 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 ; 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 ; 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" To: "Mark D. Baushke" , Maurizio Lombardi CC: "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: 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: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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, s= o 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 re= gistration 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 Singapor= e if there's a sense that more "eyes" should take a look at the requests (i= ncluding the choice of algorithms) before the requests are submitted to IAN= A. Thanks, --David ---------------------------------------------------------------- David L. Black, Senior Distinguished Engineer Dell EMC, 176 South St., Hopkinton, MA=A0 01748 +1 (774) 350-9323 New=A0=A0 Mobile: +1 (978) 394-7754 David.Black@dell.com ---------------------------------------------------------------- > -----Original Message----- > From: saag 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 >=20 >=20 > [EXTERNAL EMAIL] >=20 > Hi Maurizio, >=20 > Summary: SHA2-512/256 looks good to me. You may also wish to consider > SHAKE128(M,256) or SHAKE256(M,256) generating 256 bits. >=20 > Long reply: >=20 > 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. >=20 > Doing SHA3 in hardware is going to be faster than doing SHA2 in > hardware. >=20 > Doing SHA3 in software is going to be much slower than doing SHA2 in > software. >=20 > Comparing SHA2-256 to SHA2-512/256 in software depends on the native > size of a CPU word. >=20 > 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'). >=20 > 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.) >=20 > 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. >=20 > Considering longer term safety of the 256-bit hashes... >=20 > 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. >=20 > As the intention is cryptographic agility, I think that adding > SHA2-512/256 is a good idea. >=20 > 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. >=20 > -- Mark >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Thu Sep 19 03:11:47 2019 Return-Path: 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 ; 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 ; 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 ; Thu, 19 Sep 2019 03:11:43 -0700 (PDT) Received: by mail-qt1-x836.google.com with SMTP id o12so3517218qtf.3 for ; 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 X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Thu, 19 Sep 2019 06:11:41 -0400 Cc: "Mark D. Baushke" , Maurizio Lombardi , "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <19010.1568821685@contrail-ubm16-mdb.svec1.juniper.net> To: "Black, David" Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: >=20 > Hi Mark, >=20 > 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-25= 6. >=20 > 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 regi= stration requests directly to IANA (e.g., don't need an Internet-Draft). Th= at 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 (includ= ing the choice of algorithms) before the requests are submitted to IANA. That shouldn=E2=80=99t be necessary, I should have looked at the registratio= n policy. Thank you, Kathleen=20 >=20 > 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 > ---------------------------------------------------------------- >=20 >> -----Original Message----- >> From: saag 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 >>=20 >>=20 >> [EXTERNAL EMAIL] >>=20 >> Hi Maurizio, >>=20 >> Summary: SHA2-512/256 looks good to me. You may also wish to consider >> SHAKE128(M,256) or SHAKE256(M,256) generating 256 bits. >>=20 >> Long reply: >>=20 >> 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. >>=20 >> Doing SHA3 in hardware is going to be faster than doing SHA2 in >> hardware. >>=20 >> Doing SHA3 in software is going to be much slower than doing SHA2 in >> software. >>=20 >> Comparing SHA2-256 to SHA2-512/256 in software depends on the native >> size of a CPU word. >>=20 >> 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'). >>=20 >> 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.) >>=20 >> 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. >>=20 >> Considering longer term safety of the 256-bit hashes... >>=20 >> 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. >>=20 >> As the intention is cryptographic agility, I think that adding >> SHA2-512/256 is a good idea. >>=20 >> 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. >>=20 >> -- Mark >>=20 >> _______________________________________________ >> saag mailing list >> saag@ietf.org >> https://www.ietf.org/mailman/listinfo/saag >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sat Sep 21 10:35:45 2019 Return-Path: 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 7A17A120071 for ; Sat, 21 Sep 2019 10:35:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 rxfR0ZAdKgeS for ; Sat, 21 Sep 2019 10:35:41 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 B728812004C for ; Sat, 21 Sep 2019 10:35:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1569087341; x=1600623341; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=Ulk9YZXjXlnYxYHhHXLNzTyJb9y8RmNCkoAYnYJqd2k=; b=GaeAP8FHCNEQD8QJGIIVsYZ+7MOshdj2UkZMHOp16t8IAN0na28UfWva NQC5VLVi/56QruhB1Yx9ESS2aM+MsyIGF4jmIqe03ZCrTVACGpIz5Osvf 19TjtS3y2UZnxhzlD287PaQXUMCrydqdKDqlDXo2TXp/GKtVkH7xKSroy hBw1enZxvInJdEDwcmcf9Hz5fgl+4h5KHsg1GYWYfcfBzSwdkhphPq+Ys qhNKr15h0KKNtnHwXh7lsJ+7OAaiV99VoM2RG6EgLVoJ2P+tVzSkKkKAO 26YZIB5e7zot4FBJDnqkxnARkQIS38/rmZdyIwfZa1dLPyc5oxfHedwps w==; X-IronPort-AV: E=Sophos;i="5.64,532,1559476800"; d="scan'208";a="86956245" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from uxcn13-ogg-d.uoa.auckland.ac.nz ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Sep 2019 05:35:38 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 22 Sep 2019 05:35:36 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sun, 22 Sep 2019 05:35:36 +1200 From: Peter Gutmann To: Maurizio Lombardi , "saag@ietf.org" Thread-Topic: [saag] Improving the CHAP protocol Thread-Index: AQHVbhyc2Z4QK0TjfkKunwtzmsdiH6c2aPb+ Date: Sat, 21 Sep 2019 17:35:35 +0000 Message-ID: <1569087342890.52733@cs.auckland.ac.nz> References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> In-Reply-To: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 17:35:44 -0000 I think many people in this thread are missing the purpose of the exercise.= =0A= CHAP is used because umpteen bajillion devices and systems need it, not=0A= because it's a very good protocol. It's insecure because it's CHAP, not=0A= because it uses MD5. Since it needs a one-way function, not a collision-= =0A= resistant function, any hash function is as good - or bad since CHAP isn't= =0A= very secure - as any other. Switching from MD5 to polyquantumresistantind-= =0A= ccaprovable2048bithash will make no difference whatsoever to its security.= =0A= =0A= What the original poster asked for is something FIPS compliant. If you wan= t=0A= to convince said umpteen bajillion devices to switch, you'd better use the= =0A= universal-standard FIPS-compliant hash algorithm that everything supports,= =0A= which is SHA-256, not a bunch of wierdo fashion-statement algorithms that= =0A= nothing supports, which is most of the other stuff that's been suggested.= =0A= =0A= Having said that, you'll have to accept that the vast majority of users wil= l=0A= keep going with MD5 more or less forever since there's no motive apart from= =0A= FIPS to change, so perhaps it'd be best to pitch the update RFC as "FIPS=0A= compliance for CHAP" or something similar.=0A= =0A= Peter.=0A= From nobody Sat Sep 21 10:56:21 2019 Return-Path: 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 7561112004C for ; Sat, 21 Sep 2019 10:56:19 -0700 (PDT) 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 M1qjnc_NFYgJ for ; Sat, 21 Sep 2019 10:56:17 -0700 (PDT) Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) (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 EE93C120074 for ; Sat, 21 Sep 2019 10:56:16 -0700 (PDT) Received: by mail-wr1-x42e.google.com with SMTP id v8so9858251wrt.2 for ; Sat, 21 Sep 2019 10:56:16 -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=R5D4d6RReZY32QXWobpvD1WqEvMrnAslYGg9n09ONG8=; b=Om4Fb/SaCA7dqMUyiZzAzMeo1jSnBGBKaeEHhaR5NgpB2e8lQ7WxfHC9sHMX+fenLo b6f3zUf9CYoSdIjXmk9wSSYGa+GbnPACi8E+jyu5nLk8NDKBPqNpTT5a8/aauGuan59H d77QJFjuI5GJmZ+7j1IZNBZcLK95LKosxeBXWSxvd+dn7jCZCS4kJGNsxVV5KKN//sze CaLOs++f92KbbP7nQy/EL+t7F5k/ggXuL2T0FgiaeoNLsJzQ5Gxmi2HWa/oBt4yyskZ7 pi1032iEWi0krZeW5w0WNTEj5thKGpePqhqt6yGvp6/7zndmuBh+LmsjUZ6ol6sBmffP ak/Q== 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=R5D4d6RReZY32QXWobpvD1WqEvMrnAslYGg9n09ONG8=; b=lyq4FiEZVQPnF5H0+UP9YjUT+S36U7Ie0ijmcg7LqhjQ2OTTBo/clFJs5V3K6tgoE2 2l5toy+yjtQAFJESwgXKkUyFDvCOt5Kjn4yMHisCOI4AxAG4KD3ycrip1pj7uEzcAU7c Ff7m2qeOIUh62lBbsngiA1ni1zLl/dCg1/q0HOziUPCLcJtqdQLwsO+hxDW+Hkf8y/5+ 1Q9zlM57c7KpIMUax0GCqg9/Xs4qxaU0eCIy0Q9qJRiCYyAu375OhMdHdNMwEIuyR0ba 26pXqmNEeo6JZ7UbJaz9yFU6jXooLG5Gt2HVUWS+63eO/aWrjMQgUGfWd2+USyoK6DhV FdVw== X-Gm-Message-State: APjAAAW3P2zgWH4iK3JO8ziV/uM1Av+YmE0krueydht642D8J67Ny2YX frkxr6ij3JQeqdBVMT7Ru7M= X-Google-Smtp-Source: APXvYqy/5+MumSZGcWRdxAn/vT28ECCHS03ThDM545gwUIsqsHAzGG8cwycX6BxjC+HqyctXyQrkNg== X-Received: by 2002:a5d:6451:: with SMTP id d17mr9246635wrw.260.1569088575441; Sat, 21 Sep 2019 10:56:15 -0700 (PDT) Received: from [192.168.1.12] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id 189sm5299606wmz.19.2019.09.21.10.56.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Sep 2019 10:56:14 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Yoav Nir In-Reply-To: <1569087342890.52733@cs.auckland.ac.nz> Date: Sat, 21 Sep 2019 20:56:11 +0300 Cc: Maurizio Lombardi , Security Area Advisory Group Content-Transfer-Encoding: quoted-printable Message-Id: <7DEB7775-B495-4269-AA60-386AD045BDAE@gmail.com> References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 17:56:19 -0000 FIPS is one advantage. The other is that MD5 is getting scarce in crypto = libraries, while SHA-256 is everywhere. Not everything is devices =E2=80=94= there=E2=80=99s still software out there. But yes, it=E2=80=99s still CHAP. > On 21 Sep 2019, at 20:35, Peter Gutmann = wrote: >=20 > I think many people in this thread are missing the purpose of the = exercise. > CHAP is used because umpteen bajillion devices and systems need it, = not > because it's a very good protocol. It's insecure because it's CHAP, = not > because it uses MD5. Since it needs a one-way function, not a = collision- > resistant function, any hash function is as good - or bad since CHAP = isn't > very secure - as any other. Switching from MD5 to = polyquantumresistantind- > ccaprovable2048bithash will make no difference whatsoever to its = security. >=20 > What the original poster asked for is something FIPS compliant. If = you want > to convince said umpteen bajillion devices to switch, you'd better use = the > universal-standard FIPS-compliant hash algorithm that everything = supports, > which is SHA-256, not a bunch of wierdo fashion-statement algorithms = that > nothing supports, which is most of the other stuff that's been = suggested. >=20 > Having said that, you'll have to accept that the vast majority of = users will > keep going with MD5 more or less forever since there's no motive apart = from > FIPS to change, so perhaps it'd be best to pitch the update RFC as = "FIPS > compliance for CHAP" or something similar. >=20 > Peter. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Sat Sep 21 11:04:19 2019 Return-Path: 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 D81F1120024 for ; Sat, 21 Sep 2019 11:04:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 oRnDg_lG0yyM for ; Sat, 21 Sep 2019 11:04:16 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 68D6F120090 for ; Sat, 21 Sep 2019 11:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1569089056; x=1600625056; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=rTzRVL+gpmScSImfJz7Pvl9lieqtLwTEIfGMdB/knPg=; b=q+wGrS8xr84YiXew4rbpt3/GueDex1pq81h8A7O/1Fyjp3mh7RvRxnpL WQtKf4D1mq3WnP1OtVvkReUlWhVqf5A2nhbGb8NT6JtwphQyC0cmSpuw+ ykja5Vb+nvFRECrk2BF3ec1JKhepS2lVKc1SD1FwSzx+4gj8tNBf1Z0mS 3h2+H32kyXLWYBGtNbQ7DKJCjTsXs4YTUdlmndv5UOxuJFI9uBVJ/694O 1+qcYQmQMb3Z4Przgut2TT0jDjql+bfXB9jZ/6fCuO+XTZuUjgrrKkEId dHq0F2Xpp2Y/M6LbUATzbuO/oQR6k1GisyZHDuWAZFjN8c5RqQJxdczgi g==; X-IronPort-AV: E=Sophos;i="5.64,532,1559476800"; d="scan'208";a="86960652" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from uxcn13-tdc-e.uoa.auckland.ac.nz ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Sep 2019 06:04:14 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sun, 22 Sep 2019 06:04:14 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Sun, 22 Sep 2019 06:04:14 +1200 From: Peter Gutmann To: Yoav Nir CC: Maurizio Lombardi , Security Area Advisory Group Thread-Topic: [saag] Improving the CHAP protocol Thread-Index: AQHVbhyc2Z4QK0TjfkKunwtzmsdiH6c2aPb+//89WoCAAMtdFg== Date: Sat, 21 Sep 2019 18:04:14 +0000 Message-ID: <1569089061012.65017@cs.auckland.ac.nz> References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz>, <7DEB7775-B495-4269-AA60-386AD045BDAE@gmail.com> In-Reply-To: <7DEB7775-B495-4269-AA60-386AD045BDAE@gmail.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Sep 2019 18:04:18 -0000 Yoav Nir writes:=0A= =0A= >FIPS is one advantage. The other is that MD5 is getting scarce in crypto= =0A= >libraries, while SHA-256 is everywhere.=0A= =0A= Sure, and thus my argument to use SHA-256 and not something obscure. As yo= u=0A= say, it's everywhere, so a switch is relatively straightforward.=0A= =0A= Peter.=0A= From nobody Sun Sep 22 06:51:27 2019 Return-Path: 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 9309A12009E for ; Sun, 22 Sep 2019 06:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 PXGIoP2q0ODu for ; Sun, 22 Sep 2019 06:51:23 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93A30120018 for ; Sun, 22 Sep 2019 06:51:23 -0700 (PDT) Received: from [192.168.46.58] (24-52-251-6.cable.teksavvy.com [24.52.251.6]) by mail.networkradius.com (Postfix) with ESMTPSA id 6A9DB5C9; Sun, 22 Sep 2019 13:51:20 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: <7DEB7775-B495-4269-AA60-386AD045BDAE@gmail.com> Date: Sun, 22 Sep 2019 09:51:18 -0400 Cc: Peter Gutmann , Security Area Advisory Group Content-Transfer-Encoding: quoted-printable Message-Id: <58407786-6F26-45F5-90A0-0F42A7AF414D@deployingradius.com> References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <7DEB7775-B495-4269-AA60-386AD045BDAE@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2019 13:51:26 -0000 On Sep 21, 2019, at 1:56 PM, Yoav Nir wrote: >=20 > FIPS is one advantage. The other is that MD5 is getting scarce in = crypto libraries, while SHA-256 is everywhere. Not everything is = devices =E2=80=94 there=E2=80=99s still software out there. MD5 will be used forever. As will MD4. Crypto library authors can = complain, but the market has spoken. Every end user device ships with support for CHAP (using MD5) and = MS-CHAP (using MD4). These protocols are widely used as part of 802.1X = authentication. The EMU WG spent years standardizing TEAP (RFC 7170, May 2014), which = is only getting implemented now (!). That method could have forbidden = the use of insecure methods such as EAP-MD5 (CHAP) or EAP-MSCHAPv2. It = did not. Even if it had deprecated MD5 / MD4 methods, no one = implemented TEAP. In the mean time, people have been using EAP-TTLS and PEAP as "de = facto" standards. Which use MS-CHAP and/or CHAP. The use of MD5 / MD4 = is inside of a TLS tunnel so it's not all bad. But the usage still = makes it difficult to remove MD5 / MD4 entirely. It may take 3 years to get a new standard which deprecates the use of = MD4 / MD5 in authentication methods. It will then take another 10 years = before the new standard is wide-spread. Only then can these insecure = authentication methods be disabled on authentication servers. I see deprecating MD5 / MD4 as "pie in the sky" wishful thinking. = It's definitely *required*, but entirely *impractical*. Crypto = libraries *will* ship with them for the next 15 years. If they are = removed from crypto libraries, vendors will add their own MD5 / MD4 = implementations to every end-user device. If we wanted to fix this, we should have been done it years ago. = Maybe we can start the process now. But to be realistic, I will be in = retirement long before MD5 / MD4 are removed from common usage. Alan DeKok. From nobody Sun Sep 22 09:44:14 2019 Return-Path: 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 CCC89120059 for ; Sun, 22 Sep 2019 09:44:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.027 X-Spam-Level: X-Spam-Status: No, score=-2.027 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 S8_wZAe1Yg1h for ; Sun, 22 Sep 2019 09:44:09 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80081.outbound.protection.outlook.com [40.107.8.81]) (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 79EA1120047 for ; Sun, 22 Sep 2019 09:44:09 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lZ7KTdbJnkyj/mM4qNdVwEGgGnms/WbO9h/+zdwIrIjPluz604CjxxwdsY8+TrH4ZP7urPcsjrLRQVPR+y7Zn9VOj3j0h3b4WIeOiAu+E310U4bbjQuaT62Wu1tz8sPdhP87w8CS/xwN0DDNkbyRaReGKAJJHGkkwEYNbrJGiMB1Bmk3HsPH6cg6eNCpoLS9Rnq4yDn/eeZuW7TbqwzTtlv78UzaKt/6pjdeyrotZPVObf6zJ+KRnyH8Gxaedi0q0RciGWLvXEqJnGN3MWT9OKvsqBVsFjBmvtUjPNslNZHmnYXu4ENqrZWUCy6fatSghh087KQziWU/uvrOygI0ig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EBpNBQILQCD2HLkLHzwfzB16y9pNdAW2f+5M0dbMH3k=; b=iohGim2UOf14E6NRz0W0+gEnDNz+oyVOb6fiVFTsWzawwiOe5cnJkpMi5YrKQ26RnbQvMSj98WqP1Xm2Ab7Z0s9KyxPvlWyUsT50RsM8X33VXbtL73DHF2IWwZjAWm3dcxaj9uHX5vngqUXeC/M6LCUoSoaa0xfMA3lPf3X+EwDHcmkkelVjg09fZ/eXn0x5a3CZFtDwHEG7I/5zSwjeVbFocI5conm9KN4cbk7CkRzAEsD1PNZjc74RSk/S7jDxRFyiQD5vBBjkRLqI4RCJHS/U6deqhyPfMjzmkzlrVPmIv9fa3mrjNne70+OHGYrj/5p4cOT0KOrGDL4bRUGymQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EBpNBQILQCD2HLkLHzwfzB16y9pNdAW2f+5M0dbMH3k=; b=KVg0/zTHxfKA1D3AfKkLzLkxUoix0qD2CCzXf4zjl6UtDrRISnn/Shr3tkAnqf8kAEKvw0yDdur1BgOPyV85ANle1W9Iy2BF9nKPlniRqL4DsSdh5gQFWdbDYLmpb9cjP4HI4PAZTGe7Cr6LswUBxnJ6fuiUIVPUuqXw9RxEajA= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB4332.eurprd07.prod.outlook.com (20.176.168.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.10; Sun, 22 Sep 2019 16:44:06 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2284.023; Sun, 22 Sep 2019 16:44:06 +0000 From: John Mattsson To: Alan DeKok , Yoav Nir CC: Security Area Advisory Group Thread-Topic: [saag] Improving the CHAP protocol Thread-Index: AQHVbhyYCYcHWGngr0yyn5sVfxkQYac2abmAgAAFwoCAAU3pAIAAUc6A Date: Sun, 22 Sep 2019 16:44:06 +0000 Message-ID: References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <7DEB7775-B495-4269-AA60-386AD045BDAE@gmail.com> <58407786-6F26-45F5-90A0-0F42A7AF414D@deployingradius.com> In-Reply-To: <58407786-6F26-45F5-90A0-0F42A7AF414D@deployingradius.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [82.214.46.143] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4f04d90c-652c-42e8-c22e-08d73f7c1586 x-ms-traffictypediagnostic: HE1PR07MB4332: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 016885DD9B x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(346002)(376002)(136003)(366004)(39860400002)(189003)(199004)(13464003)(478600001)(102836004)(229853002)(6506007)(53546011)(110136005)(58126008)(6246003)(76176011)(81156014)(2616005)(186003)(446003)(966005)(14454004)(81166006)(26005)(8676002)(11346002)(66066001)(99286004)(33656002)(25786009)(4326008)(8936002)(7736002)(305945005)(256004)(3846002)(6116002)(14444005)(486006)(71190400001)(6436002)(5660300002)(71200400001)(91956017)(76116006)(66446008)(64756008)(66556008)(66476007)(6486002)(44832011)(6306002)(6512007)(2906002)(316002)(36756003)(476003)(86362001)(66946007); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4332; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: eT5FlGR5xYzOiBjbVvM5DTHxGokUMwNf/KA9BJ1aB7PvnfK8UgxPJ5Z5UV75PEClY7Vbu6alf+n9BkAGO/ajjvhJMZSrQa8Qe6kbFlmdcdi5RZxosOLjTyT8FuW60FvhRmUgmxzWyXkzoI4HfvAIrCAT0p4hBcNOpdilel1hSpos3LsCZ9RvDM6FevwjQU6G35xLtu+3BkmCB+OU0RIBNfLTGcc5S/49wcu85uoM+hMN4RlPzyqvV5AkWVt/YCQyF0vqsUz3Z96UbK0XZTiURjI2aiYLgekFf65d0PPmpwZvwPU497lNOwNSuxbmcADHwrcyG+fokawMdybe53Qx+TrzJVHQREXtdB5XRm+fUAFfcmyDpsG8TePZ1UcDZrwERhKNJygSzFuPbSnVYKCYJ0YoZHUG7/ToyT3Ohwm+iyE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <399C9EF5569F334088267EE496DBBCAD@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4f04d90c-652c-42e8-c22e-08d73f7c1586 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Sep 2019 16:44:06.4583 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: mJcTDPCuXVGkP63AvYRVMUAP2Cv8FMVfSfc63WWbwQKs7N++qwYB/sOlUIz10Hv1qnek1+5ursoDJTzUiaounxi2KbJBb+0jam8QoXt8Apw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4332 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2019 16:44:13 -0000 SGksDQoNCkkgZnVsbHkgYWdyZWUgdGhhdCBpdCBzaG91bGQgaGF2ZSBiZWVuIGRvbmUgYSBsb25n IHRpbWUgYWdvIGFuZCB0aGF0IGl0IHdpbGwgdGFrZSBhIHZlcnkgbG9uZyB0aW1lIHRvIGFjaGll dmUuIFRvIG1lIHRoYXQganVzdCBtZWFucyB3ZSBuZWVkIHRvIHN0YXJ0IGFzIHNvb24gYXMgcG9z c2libGUuDQoNCldoZW4gaXQgY29tZXMgdG8gY3J5cHRvIHByb2ZpbGluZywgSUVURiBpcyBvZnRl biB2ZXJ5IHNsb3cgYW5kIHZlcnkgZm9jdXNlZCBvbiB3aGV0aGVyIHNvbWUgc3lzdGVtIHdpbGwg Y29udGludWUgdGhlIHdlYWsgYWxnb3JpdGhtcyBpbiBxdWVzdGlvbnMuIEZvciBhbiBleGFtcGxl IHRha2UgdGhlIG90aGVyd2lzZSBleGNlbGxlbnQgUkZDIDc1MjUgdGhhdCBoYXMgc2V2ZXJhbCBz dXBlciBzb2Z0IHN0YXRlbWVudHMgbGlrZToNCg0KIkN1cnZlcyBvZiBsZXNzIHRoYW4gMTkyIGJp dHMgU0hPVUxEIE5PVCBiZSB1c2VkLiINCg0KSSBoYXZlIG1ldCBzZXZlcmFsIGltcGxlbWVudG9y cyBpbiBkaWZmZXJlbnQgY29tcGFuaWVzIHRoYXQgcmVhZCAiU0hPVUxEIE5PVCIgYXMgIk5PIFJF QVNPTiBUTyBDSEFOR0UgQU5ZVEhJTkciLg0KDQpJIHRoaW5rIElFVEYgaW4gZ2VuZXJhbCBuZWVk IHRvIGJlIG11Y2ggbW9yZSBwcm8tYWN0aXZlIHdoZW4gaXQgY29tZXMgZm9yYmlkZGluZyB3ZWFr IGFsZ29yaXRobXMgYW5kIGFsc28gdXNlIG11Y2ggbW9yZSAiTVVTVCBOT1QiLg0KDQpDaGVlcnMs DQpKb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzYWFnIDxzYWFn LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBBbGFuIERlS29rIDxhbGFuZEBkZXBsb3lp bmdyYWRpdXMuY29tPg0KRGF0ZTogU3VuZGF5LCAyMiBTZXB0ZW1iZXIgMjAxOSBhdCAxNTo1MQ0K VG86IFlvYXYgTmlyIDx5bmlyLmlldGZAZ21haWwuY29tPg0KQ2M6IFNlY3VyaXR5IEFyZWEgQWR2 aXNvcnkgR3JvdXAgPHNhYWdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NhYWddIEltcHJvdmlu ZyB0aGUgQ0hBUCBwcm90b2NvbA0KDQogICAgT24gU2VwIDIxLCAyMDE5LCBhdCAxOjU2IFBNLCBZ b2F2IE5pciA8eW5pci5pZXRmQGdtYWlsLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+IEZJUFMg aXMgb25lIGFkdmFudGFnZS4gVGhlIG90aGVyIGlzIHRoYXQgTUQ1IGlzIGdldHRpbmcgc2NhcmNl IGluIGNyeXB0byBsaWJyYXJpZXMsIHdoaWxlIFNIQS0yNTYgaXMgZXZlcnl3aGVyZS4gIE5vdCBl dmVyeXRoaW5nIGlzIGRldmljZXMg4oCUIHRoZXJl4oCZcyBzdGlsbCBzb2Z0d2FyZSBvdXQgdGhl cmUuDQogICAgDQogICAgICBNRDUgd2lsbCBiZSB1c2VkIGZvcmV2ZXIuICBBcyB3aWxsIE1ENC4g IENyeXB0byBsaWJyYXJ5IGF1dGhvcnMgY2FuIGNvbXBsYWluLCBidXQgdGhlIG1hcmtldCBoYXMg c3Bva2VuLg0KICAgIA0KICAgICAgRXZlcnkgZW5kIHVzZXIgZGV2aWNlIHNoaXBzIHdpdGggc3Vw cG9ydCBmb3IgQ0hBUCAodXNpbmcgTUQ1KSBhbmQgTVMtQ0hBUCAodXNpbmcgTUQ0KS4gIFRoZXNl IHByb3RvY29scyBhcmUgd2lkZWx5IHVzZWQgYXMgcGFydCBvZiA4MDIuMVggYXV0aGVudGljYXRp b24uDQogICAgDQogICAgICBUaGUgRU1VIFdHIHNwZW50IHllYXJzIHN0YW5kYXJkaXppbmcgVEVB UCAoUkZDIDcxNzAsIE1heSAyMDE0KSwgd2hpY2ggaXMgb25seSBnZXR0aW5nIGltcGxlbWVudGVk IG5vdyAoISkuICBUaGF0IG1ldGhvZCBjb3VsZCBoYXZlIGZvcmJpZGRlbiB0aGUgdXNlIG9mIGlu c2VjdXJlIG1ldGhvZHMgc3VjaCBhcyBFQVAtTUQ1IChDSEFQKSBvciBFQVAtTVNDSEFQdjIuICBJ dCBkaWQgbm90LiAgRXZlbiBpZiBpdCBoYWQgZGVwcmVjYXRlZCBNRDUgLyBNRDQgbWV0aG9kcywg bm8gb25lIGltcGxlbWVudGVkIFRFQVAuDQogICAgDQogICAgICBJbiB0aGUgbWVhbiB0aW1lLCBw ZW9wbGUgaGF2ZSBiZWVuIHVzaW5nIEVBUC1UVExTIGFuZCBQRUFQIGFzICJkZSBmYWN0byIgc3Rh bmRhcmRzLiAgV2hpY2ggdXNlIE1TLUNIQVAgYW5kL29yIENIQVAuICBUaGUgdXNlIG9mIE1ENSAv IE1ENCBpcyBpbnNpZGUgb2YgYSBUTFMgdHVubmVsIHNvIGl0J3Mgbm90IGFsbCBiYWQuICBCdXQg dGhlIHVzYWdlIHN0aWxsIG1ha2VzIGl0IGRpZmZpY3VsdCB0byByZW1vdmUgTUQ1IC8gTUQ0IGVu dGlyZWx5Lg0KICAgIA0KICAgICAgSXQgbWF5IHRha2UgMyB5ZWFycyB0byBnZXQgYSBuZXcgc3Rh bmRhcmQgd2hpY2ggZGVwcmVjYXRlcyB0aGUgdXNlIG9mIE1ENCAvIE1ENSBpbiBhdXRoZW50aWNh dGlvbiBtZXRob2RzLiAgSXQgd2lsbCB0aGVuIHRha2UgYW5vdGhlciAxMCB5ZWFycyBiZWZvcmUg dGhlIG5ldyBzdGFuZGFyZCBpcyB3aWRlLXNwcmVhZC4gIE9ubHkgdGhlbiBjYW4gdGhlc2UgaW5z ZWN1cmUgYXV0aGVudGljYXRpb24gbWV0aG9kcyBiZSBkaXNhYmxlZCBvbiBhdXRoZW50aWNhdGlv biBzZXJ2ZXJzLg0KICAgIA0KICAgICAgSSBzZWUgZGVwcmVjYXRpbmcgTUQ1IC8gTUQ0IGFzICJw aWUgaW4gdGhlIHNreSIgd2lzaGZ1bCB0aGlua2luZy4gIEl0J3MgZGVmaW5pdGVseSAqcmVxdWly ZWQqLCBidXQgZW50aXJlbHkgKmltcHJhY3RpY2FsKi4gIENyeXB0byBsaWJyYXJpZXMgKndpbGwq IHNoaXAgd2l0aCB0aGVtIGZvciB0aGUgbmV4dCAxNSB5ZWFycy4gIElmIHRoZXkgYXJlIHJlbW92 ZWQgZnJvbSBjcnlwdG8gbGlicmFyaWVzLCB2ZW5kb3JzIHdpbGwgYWRkIHRoZWlyIG93biBNRDUg LyBNRDQgaW1wbGVtZW50YXRpb25zIHRvIGV2ZXJ5IGVuZC11c2VyIGRldmljZS4NCiAgICANCiAg ICAgIElmIHdlIHdhbnRlZCB0byBmaXggdGhpcywgd2Ugc2hvdWxkIGhhdmUgYmVlbiBkb25lIGl0 IHllYXJzIGFnby4gIE1heWJlIHdlIGNhbiBzdGFydCB0aGUgcHJvY2VzcyBub3cuICBCdXQgdG8g YmUgcmVhbGlzdGljLCBJIHdpbGwgYmUgaW4gcmV0aXJlbWVudCBsb25nIGJlZm9yZSBNRDUgLyBN RDQgYXJlIHJlbW92ZWQgZnJvbSBjb21tb24gdXNhZ2UuDQogICAgDQogICAgICBBbGFuIERlS29r Lg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgc2FhZyBtYWlsaW5nIGxpc3QNCiAgICBzYWFnQGlldGYub3JnDQogICAgaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zYWFnDQogICAgDQoNCg== From nobody Sun Sep 22 12:53:47 2019 Return-Path: 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 57CBA12002E for ; Sun, 22 Sep 2019 12:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 r34fE8M76FTz for ; Sun, 22 Sep 2019 12:53:43 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 C6F0E120090 for ; Sun, 22 Sep 2019 12:53:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1569182023; x=1600718023; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=/Hossy2Qucn+Q4LXpnFKxixWg0/JZ0nHLSWyGhVvZK4=; b=oGpg3XNffUNhwlifmPonfo+hEPDxXwAAGy8r907PHEeUx1C5sg34miUM mLKxZs+Wmm6IHSlhhfNV3pp6xQrknl3OIIuQZz1yUaa9c/xcyBFfmOCZi +PrghX0z3OHuMZoZ+8iUVwYRf/AI51PYrLBJjx/eajxR14beHai2lR6kU WhFnRZSLBfiRvU54HyT2+Ib/t5jyYQ6LLS8UTT5MVAFuUwS7AytKjv1s1 L/d8a4XW9VM0Mp8RrtoebqGVKntgWsKFMecWpbv8fIAzN/zqcKE8kpQxx YykYS3s29ibJbSVoHGqvTig27f9KEJnE2NRQvCkKm37463vgocrZ/8csK g==; X-IronPort-AV: E=Sophos;i="5.64,537,1559476800"; d="scan'208";a="87216566" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.8 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-e.UoA.auckland.ac.nz) ([10.6.2.8]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 23 Sep 2019 07:53:39 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-e.UoA.auckland.ac.nz (10.6.2.8) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Mon, 23 Sep 2019 07:53:39 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Mon, 23 Sep 2019 07:53:39 +1200 From: Peter Gutmann To: Alan DeKok , Yoav Nir CC: Security Area Advisory Group Thread-Topic: [saag] Improving the CHAP protocol Thread-Index: AQHVbhyc2Z4QK0TjfkKunwtzmsdiH6c2aPb+//89WoCAAU3qAIABLjYk Date: Sun, 22 Sep 2019 19:53:38 +0000 Message-ID: <1569182027021.91161@cs.auckland.ac.nz> References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <7DEB7775-B495-4269-AA60-386AD045BDAE@gmail.com>, <58407786-6F26-45F5-90A0-0F42A7AF414D@deployingradius.com> In-Reply-To: <58407786-6F26-45F5-90A0-0F42A7AF414D@deployingradius.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Sep 2019 19:53:47 -0000 Alan DeKok writes:=0A= =0A= >In the mean time, people have been using EAP-TTLS and PEAP as "de facto"= =0A= >standards.=0A= =0A= Yup. Doesn't matter how bad the auth protocol actually is because it's=0A= tunneled over TLS everywhere where it matters.=0A= =0A= >I see deprecating MD5 / MD4 as "pie in the sky" wishful thinking. It's=0A= >definitely *required*, but entirely *impractical*.=0A= =0A= Definitely. And that's why I proposed having the replacement RFC titled as= =0A= "FIPS compliance for CHAP", because moving to SHA-256 won't make it more=0A= secure, it'll just make it more FIPS compliant.=0A= =0A= Having said that, if you're going to go with a breaking change in CHAP, you= =0A= may as well actually fix CHAP rather than just making the hash function FIP= S=0A= compliant. There's a rather nice mutual auth protocol from Kaufman, Perlma= n,=0A= and Speciner which is something like:=0A= =0A= Challenge ->=0A= <- Enc( Challenge )=0A= Enc( Response ->=0A= =0A= using the universally-available AES, so the whole protocol is two crypt=0A= operations on each side. It's one more message than CHAP, but provides mut= ual=0A= auth in the process. Downside is that for low-entropy keys/authenticators= =0A= it's open to a brute-force attack, but it is a starting point.=0A= =0A= Peter.=0A= From nobody Mon Sep 23 03:29:50 2019 Return-Path: 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 05D14120288 for ; Mon, 23 Sep 2019 03:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 qVagdX6Bxxdw for ; Mon, 23 Sep 2019 03:29:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09318120105 for ; Mon, 23 Sep 2019 03:29:46 -0700 (PDT) Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 7749A3084031; Mon, 23 Sep 2019 10:29:45 +0000 (UTC) Received: from [10.35.206.29] (unknown [10.35.206.29]) by smtp.corp.redhat.com (Postfix) with ESMTP id 5D741600C4; Mon, 23 Sep 2019 10:29:44 +0000 (UTC) To: Peter Gutmann , "saag@ietf.org" References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> From: Maurizio Lombardi Message-ID: <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com> Date: Mon, 23 Sep 2019 12:29:42 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <1569087342890.52733@cs.auckland.ac.nz> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.11 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.40]); Mon, 23 Sep 2019 10:29:45 +0000 (UTC) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 10:29:49 -0000 Hello Peter, Dne 21.9.2019 v 19:35 Peter Gutmann napsal(a): > I think many people in this thread are missing the purpose of the exercise. > CHAP is used because umpteen bajillion devices and systems need it, not > because it's a very good protocol. It's insecure because it's CHAP, not > because it uses MD5. Since it needs a one-way function, not a collision- > resistant function, any hash function is as good - or bad since CHAP isn't > very secure - as any other. Switching from MD5 to polyquantumresistantind- > ccaprovable2048bithash will make no difference whatsoever to its security. > > What the original poster asked for is something FIPS compliant. If you want > to convince said umpteen bajillion devices to switch, you'd better use the > universal-standard FIPS-compliant hash algorithm that everything supports, > which is SHA-256, not a bunch of wierdo fashion-statement algorithms that > nothing supports, which is most of the other stuff that's been suggested. That's correct, what we need is just a FIPS-compliant hash function that is very unlikely do be deprecated anytime soon; and we need it because the non-compliance of MD5 is breaking iSCSI use cases for our customers now. The collision resistance of the hash function is not a top priority for us. Personally, I would like to see adopted something widely used, SHA-256 and SHA3-256 are good candidates IMO. Maurizio Lombardi From nobody Mon Sep 23 12:30:14 2019 Return-Path: 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 C75B21208D2 for ; Mon, 23 Sep 2019 12:30:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=PSRnXJ4s; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=EkD2Wdvl 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 8I9rBLMwMv8s for ; Mon, 23 Sep 2019 12:30:02 -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 7BF6512085E for ; Mon, 23 Sep 2019 12:30:02 -0700 (PDT) Received: from pps.filterd (m0170395.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8NJFbfm015210; Mon, 23 Sep 2019 15:29:49 -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=BrDcIXejPLd6w1wZ1d3u1OJGafx5FLbPP56x+ZMfxdA=; b=PSRnXJ4sa66orwZcqwdeXA9mEBxjdavAaU+4DbK58ZvtgUR/hDeHMsDOiZUJqZEOSg52 fy48o+Bmg2dpmT6MY93FQjAYESSm15xRjWMDCi+OrWtdZJ65qcfrjYvLRVdrluXv7uPB QPwjwz5s6+wZ2dymdHK9exBLcUcKBs3fO9tI2hSsGJd2xwWslNB14sPwOMrJws1QvndC wSIeIymTXRku7uFemWbzkys0OZ+OEPvP3bpKdjK8LVUMliYDntYpseA8Cqfqj4/t4MAn ZArrYFSzSwlCDqejRzh81+0PVhAf6qdfquHFo6ihnArkDL59grp7ML/U9uVQA/pMqI+l tQ== Received: from mx0a-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 2v5ghm9d9y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 23 Sep 2019 15:29:49 -0400 Received: from pps.filterd (m0142693.ppops.net [127.0.0.1]) by mx0a-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8NJD7rd139275; Mon, 23 Sep 2019 15:29:48 -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 2v6188g53b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 23 Sep 2019 15:29:48 -0400 Received: from maildlpprd04.lss.emc.com (maildlpprd04.lss.emc.com [10.253.24.36]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8NJTgaT022822 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 23 Sep 2019 15:29:47 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com x8NJTgaT022822 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1569266987; bh=6OYtStFsxyaNkmaHMwpXcDf4TFU=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=EkD2WdvlCOO2li9gfsazfR2YX3B5K66c+On+PStxiIKlF9J6aVohovrQRVf5FLIkB lzefNzj3oeXDXK7hliX5eyioqd7FrpKXxICQ5H5rpSyBzqM5lP/sMSwLD2hnMUV8eJ 6cCUcznE7fyblvNpJO969HZkQcYadvTeTFCZoFuo= Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd04.lss.emc.com (RSA Interceptor); Mon, 23 Sep 2019 15:29:09 -0400 Received: from MXHUB313.corp.emc.com (MXHUB313.corp.emc.com [10.146.3.91]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8NJT5Jf013961 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 23 Sep 2019 15:29:09 -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; Mon, 23 Sep 2019 15:28:32 -0400 From: "Black, David" To: Peter Gutmann , "saag@ietf.org" Thread-Topic: [saag] Improving the CHAP protocol Thread-Index: AQHVbhyVNSLAH6mw10yrI1pLte3B86c2rMeAgAKtrQCAAEGFkA== Date: Mon, 23 Sep 2019 19:28:31 +0000 Message-ID: References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com> In-Reply-To: <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com> 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-23T19:24:44.3760293Z; 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-23_06:2019-09-23,2019-09-23 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 malwarescore=0 spamscore=0 bulkscore=0 priorityscore=1501 mlxscore=0 phishscore=0 adultscore=0 mlxlogscore=999 suspectscore=0 impostorscore=0 clxscore=1011 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909230164 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 adultscore=0 mlxlogscore=999 priorityscore=1501 impostorscore=0 bulkscore=0 phishscore=0 mlxscore=0 suspectscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909230164 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Sep 2019 19:30:12 -0000 Hi Peter, > > I think many people in this thread are missing the purpose of the exerc= ise. For clarity, the purpose of this exercise is to register additional hash fu= nctions for use by iSCSI, not to prolong the life of CHAP in PPP. We have = no problem asking IANA to restrict the newly registered hashes to be used o= nly with iSCSI (i.e., prohibit their use with PPP). One of the reasons tha= t this is feasible is that iSCSI uses CHAP as part of an iSCSI-specific neg= otiation mechanism that is not based on PPP. > > CHAP is used because umpteen bajillion devices and systems need it, not > > because it's a very good protocol. =20 I'm not sure whether iSCSI is up to a bajillion ;-), but there is a lot of = iSCSI out there. The situation that we can't change is that iSCSI referenc= es the IANA PPP CHAP registry for CHAP hash algorithms. An important histo= rical reason for that registry reference was compatibility with RADIUS veri= fication of CHAP (which was important at the time). > > Since it needs a one-way function, not a collision- > > resistant function, any hash function is as good - or bad since CHAP is= n't > > very secure - as any other. Switching from MD5 to polyquantumresistant= ind- > > ccaprovable2048bithash will make no difference whatsoever to its securi= ty. FWIW, iSCSI CHAP is somewhat better than plain CHAP, e.g., checks that prev= ent reflection attacks are mandatory. > > What the original poster asked for is something FIPS compliant. If you= want > > to convince said umpteen bajillion devices to switch, you'd better use = the > > universal-standard FIPS-compliant hash algorithm that everything suppor= ts, > > which is SHA-256, not a bunch of wierdo fashion-statement algorithms th= at > > nothing supports, which is most of the other stuff that's been suggeste= d. SHA-256 makes sense from that running code perspective, no problem. > > Having said that, if you're going to go with a breaking change in CHAP,= you > > may as well actually fix CHAP rather than just making the hash function= FIPS > > compliant. I see no little to no current interest in a new iSCSI authentication protoc= ol in either the storage standards community or iSCSI implementer community= , whereas there is running iSCSI code for at least one of the new hashes. Moreover, back when there was interest in iSCSI authentication protocols, w= hat was wanted was a strong password protocol to defend against weak secret= s (e.g., passwords). iSCSI originally specified a version of SRP as option= al, but that's not used much. In 20/20 hindsight, it's unfortunate that IE= TF & CFRG missed the opportunity to recommend a preferred strong password p= rotocol back around the time that the problematic patents were approaching = expiration. Thanks, --David > -----Original Message----- > From: saag On Behalf Of Maurizio Lombardi > Sent: Monday, September 23, 2019 6:30 AM > To: Peter Gutmann; saag@ietf.org > Subject: Re: [saag] Improving the CHAP protocol >=20 >=20 > [EXTERNAL EMAIL] >=20 > Hello Peter, >=20 > Dne 21.9.2019 v 19:35 Peter Gutmann napsal(a): > > I think many people in this thread are missing the purpose of the exerc= ise. > > CHAP is used because umpteen bajillion devices and systems need it, not > > because it's a very good protocol. It's insecure because it's CHAP, no= t > > because it uses MD5. Since it needs a one-way function, not a collisio= n- > > resistant function, any hash function is as good - or bad since CHAP is= n't > > very secure - as any other. Switching from MD5 to > polyquantumresistantind- > > ccaprovable2048bithash will make no difference whatsoever to its securi= ty. > > > > What the original poster asked for is something FIPS compliant. If you= want > > to convince said umpteen bajillion devices to switch, you'd better use = the > > universal-standard FIPS-compliant hash algorithm that everything suppor= ts, > > which is SHA-256, not a bunch of wierdo fashion-statement algorithms th= at > > nothing supports, which is most of the other stuff that's been suggeste= d. >=20 > That's correct, what we need is just a FIPS-compliant hash function > that is very unlikely do be deprecated anytime soon; and we need it > because the non-compliance of MD5 is breaking iSCSI use cases for our > customers now. >=20 > The collision resistance of the hash function is not a top priority for u= s. >=20 > Personally, I would like to see adopted something widely used, > SHA-256 and SHA3-256 are good candidates IMO. >=20 > Maurizio Lombardi >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Tue Sep 24 06:52:15 2019 Return-Path: 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 E142812080C for ; Tue, 24 Sep 2019 06:52:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vuJsblImWwaD for ; Tue, 24 Sep 2019 06:52:11 -0700 (PDT) Received: from mail.networkradius.com (mail.networkradius.com [62.210.147.122]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E25AB1200C7 for ; Tue, 24 Sep 2019 06:52:10 -0700 (PDT) Received: from [192.168.20.69] (ottawa.ca.networkradius.com [72.137.155.194]) by mail.networkradius.com (Postfix) with ESMTPSA id 4DD5A19D9; Tue, 24 Sep 2019 13:52:08 +0000 (UTC) Authentication-Results: NetworkRADIUS; dmarc=none header.from=deployingradius.com Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) From: Alan DeKok In-Reply-To: Date: Tue, 24 Sep 2019 09:52:06 -0400 Cc: Peter Gutmann , "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2534DA2B-76A0-4CC7-95F6-405BCC5ADE91@deployingradius.com> References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com> To: "Black, David" X-Mailer: Apple Mail (2.3445.104.11) Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 13:52:13 -0000 On Sep 23, 2019, at 3:28 PM, Black, David wrote: > For clarity, the purpose of this exercise is to register additional = hash functions for use by iSCSI, not to prolong the life of CHAP in PPP. = We have no problem asking IANA to restrict the newly registered hashes = to be used only with iSCSI (i.e., prohibit their use with PPP). I don't see that as necessary. It should be fine to use new methods = with PPP. Using the new methods in other protocols requires standards = actions. So by default they won't be used unless someone steps up to = write those standards. Alan DeKok. From nobody Tue Sep 24 07:53:57 2019 Return-Path: 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 E2A9D120072 for ; Tue, 24 Sep 2019 07:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 HMe0ECk3ws3b for ; Tue, 24 Sep 2019 07:53:54 -0700 (PDT) Received: from mx4-int.auckland.ac.nz (mx4-int.auckland.ac.nz [130.216.125.246]) (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 989A812001A for ; Tue, 24 Sep 2019 07:53:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1569336833; x=1600872833; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5B2UV21eRM2/QCEI56+y6nglon1wqP5ht34Bqtv8DtA=; b=x+FrXAHfVd6ZgBZVGEqT4goLz1msJHAvAsy8aQmzOUsfkixzkX94nmpG 0s3PyXHIB4SmenTXJP2p9kFCDu71mBtwBpks8+9dSbAPc476z8GINewtS MtPDunDox5Jv8VXJQIvGKLhO4BK45ev4iP8XhFXAMOgC48qKse48UZ0rK u49BpYcqhcKoZnCaMTxigwi8adgytSPoLNEum4ATe+Gc29TBgefXfcwaJ 9kHnQS1hlzzwZdHe4JQ0pzD3j4IkrZKPNR+Xx320d0PZymN6CskooiTc2 06UDcbYLecBsXjOiEePCru5saf2XHc/GTV5X25fpMuaQlfWj1OGud5vIN g==; X-IronPort-AV: E=Sophos;i="5.64,544,1559476800"; d="scan'208";a="87798982" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.9 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-e.UoA.auckland.ac.nz) ([10.6.3.9]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Sep 2019 02:53:51 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-e.UoA.auckland.ac.nz (10.6.3.9) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 25 Sep 2019 02:53:51 +1200 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.5]) with mapi id 15.00.1395.000; Wed, 25 Sep 2019 02:53:50 +1200 From: Peter Gutmann To: "Black, David" , "saag@ietf.org" Thread-Topic: [saag] Improving the CHAP protocol Thread-Index: AQHVbhyc2Z4QK0TjfkKunwtzmsdiH6c2aPb+gAHlRQCAAJaLgIACDrC+ Date: Tue, 24 Sep 2019 14:53:50 +0000 Message-ID: <1569336830344.45369@cs.auckland.ac.nz> References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Sep 2019 14:53:56 -0000 Black, David writes:=0A= =0A= >The situation that we can't change is that iSCSI references the IANA PPP C= HAP=0A= >registry for CHAP hash algorithms.=0A= =0A= So would the simplest solution then be just to add SHA-256 to the registry?= =0A= =0A= Peter.=0A= From nobody Wed Sep 25 10:05:04 2019 Return-Path: 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 3680E12012E for ; Wed, 25 Sep 2019 10:05:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=m8nDvOO2; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=Di8RqrT0 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 ihu5nYEDZhBu for ; Wed, 25 Sep 2019 10:05:00 -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 976411200CE for ; Wed, 25 Sep 2019 10:05:00 -0700 (PDT) Received: from pps.filterd (m0170396.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8PGtHF8013287; Wed, 25 Sep 2019 13:04:47 -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=jfRtHYVHiwPO9D3Gqkdtyrs6yup1AimZsqPIfoeLn9g=; b=m8nDvOO2iYi6ORbbuEUtExjOWuL0R+u1XTo3KHKsltPKJ7Od/mPfuXVsbIvIY6MtBlT+ 4n/Jctw5bZ0P5I15haaNVmt8nhZAbJvYQT9eyurv8TvdEka76gRM+8PP2cwb3kSqvb15 ClxCu5bQiPCgti71HHLFD175aZ38PQyM5I+hWyjGNpTdCKUoaeds1TlYyjJcKjD3myQ7 +y3J86UrseDaqCoPN0sfZv9njv5yH+iAYPCS4tEQ2vCb9T4Gcs151eEZe0IXuhCMgoCj COXDswCKORM0WWCkgjysCOMlIWJK7qIboQa6TsOyHaHnxFYZY+kz1OFlavc00NSAke8S mQ== Received: from mx0b-00154901.pphosted.com (mx0a-00154901.pphosted.com [67.231.149.39]) by mx0b-00154904.pphosted.com with ESMTP id 2v7mne6jhf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Sep 2019 13:04:47 -0400 Received: from pps.filterd (m0090350.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8PGx1Ch055002; Wed, 25 Sep 2019 13:04:46 -0400 Received: from mailuogwhop.emc.com (mailuogwhop-nat.lss.emc.com [168.159.213.141] (may be forged)) by mx0b-00154901.pphosted.com with ESMTP id 2v7p3dd6y0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 25 Sep 2019 13:04:45 -0400 Received: from maildlpprd02.lss.emc.com (maildlpprd02.lss.emc.com [10.253.24.34]) by mailuogwprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8PH4GV4014532 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 25 Sep 2019 13:04:33 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd02.lss.emc.com x8PH4GV4014532 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1569431074; bh=bI3MATGAXJpJNdNw/T79ZM656eI=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=Di8RqrT0WhECN6w3TBYhO6GS/qyst88Pk1u0q0pLzwI4Oxtao3md9fOqf3jCEJe+Y zClWRcAwviIKb/PwI6qtl+Lqz8v2Lstf8gabLvHU7i5+5qyG45kcyfXBujCqBfRq6/ lbkHMCEERKawYjMu9deT2DCev/44Qe8gN7yPE8iQ= Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd02.lss.emc.com (RSA Interceptor); Wed, 25 Sep 2019 13:03:49 -0400 Received: from MXHUB315.corp.emc.com (MXHUB315.corp.emc.com [10.146.3.93]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8PH3mDt000384 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Wed, 25 Sep 2019 13:03:49 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB315.corp.emc.com ([10.146.3.93]) with mapi id 14.03.0439.000; Wed, 25 Sep 2019 13:03:48 -0400 From: "Black, David" To: Peter Gutmann , "saag@ietf.org" Thread-Topic: [saag] Improving the CHAP protocol Thread-Index: AQHVbhyVNSLAH6mw10yrI1pLte3B86c2rMeAgAKtrQCAAEGFkIABmpwAgAFzOzA= Date: Wed, 25 Sep 2019 17:03:47 +0000 Message-ID: References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com>, <1569336830344.45369@cs.auckland.ac.nz> In-Reply-To: <1569336830344.45369@cs.auckland.ac.nz> 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-25T17:03:35.7740215Z; 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.105.8.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-25_08:2019-09-25,2019-09-25 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 phishscore=0 spamscore=0 lowpriorityscore=0 suspectscore=0 bulkscore=0 malwarescore=0 mlxscore=0 adultscore=0 clxscore=1015 impostorscore=0 mlxlogscore=586 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909250152 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxlogscore=672 clxscore=1015 mlxscore=0 suspectscore=0 spamscore=0 impostorscore=0 priorityscore=1501 lowpriorityscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909250152 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 17:05:03 -0000 Yes, and SHA3-256 while we're in there ... I plan to submit the request to= IANA to do that by early next week. Thanks, --David > -----Original Message----- > From: Peter Gutmann > Sent: Tuesday, September 24, 2019 10:54 AM > To: Black, David; saag@ietf.org > Cc: Maurizio Lombardi > Subject: Re: [saag] Improving the CHAP protocol >=20 >=20 > Black, David writes: >=20 > >The situation that we can't change is that iSCSI references the IANA PPP= CHAP > >registry for CHAP hash algorithms. >=20 > So would the simplest solution then be just to add SHA-256 to the registr= y? >=20 > Peter. From nobody Wed Sep 25 10:20:01 2019 Return-Path: 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 F00E712012E for ; Wed, 25 Sep 2019 10:19:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 bn8fl42R_tyB for ; Wed, 25 Sep 2019 10:19:56 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 DAFBB1200C1 for ; Wed, 25 Sep 2019 10:19:55 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8PH7JG3025007; Wed, 25 Sep 2019 18:19:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=hksucbznNVHOG9weTqA94osZEdc/HZiTaEiiRJepFCg=; b=oKiM23Me+2iyIbD3yxDgNek9GoV8KWXOMI4PNAms7UFFN1AGIVpQPs39+QsI2Otl1+T0 3U7jpOTGk8EPMCaVlo9BnhrQJ1+IPtXLHBPdVhKEPWzYU1uBZO8SBEYXLE7AvK+LQbDL a4VDQAENYsYTnmk4wgc01oiU1SsEljvPmhgPjWhaJQTVebdzoEzo3dRgZ1An2kfe5FE+ 35TnBjckp1D5qDAVRIvtxEP10ZxBEcfJpQERwkCDX5QV11LEJtEfUN3Ap/JCm2NqfzCe SQFrnUS8cJk4rz2LYAZwoOZ6QUIvGnZY4ouza2+OAChyjYrS8f9VBtOXCazvRvmirUhF /w== Received: from prod-mail-ppoint5 (prod-mail-ppoint5.akamai.com [184.51.33.60] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2v73q9gpsm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Sep 2019 18:19:49 +0100 Received: from pps.filterd (prod-mail-ppoint5.akamai.com [127.0.0.1]) by prod-mail-ppoint5.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8PHH8XS027324; Wed, 25 Sep 2019 10:19:48 -0700 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint5.akamai.com with ESMTP id 2v73vp48r7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 25 Sep 2019 10:19:48 -0700 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 25 Sep 2019 13:19:47 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 25 Sep 2019 13:19:47 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Wed, 25 Sep 2019 13:19:47 -0400 From: "Salz, Rich" To: "Black, David" , Peter Gutmann , "saag@ietf.org" Thread-Topic: [saag] Improving the CHAP protocol Thread-Index: AQHVbhyYXsrZtoYokU++GClDQj31Gqc2rMeAgAKtrQCAAJaLgIABRZYAgAG2o4D//8FqgA== Date: Wed, 25 Sep 2019 17:19:47 +0000 Message-ID: <6B20CCD2-58AF-4AC4-B978-EC1CBA7F264F@akamai.com> References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com> <1569336830344.45369@cs.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.67] Content-Type: text/plain; charset="utf-8" Content-ID: <65830B0B9FB2B046A82E06E078443175@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-25_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=921 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909250153 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-25_08:2019-09-25,2019-09-25 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1011 bulkscore=0 mlxlogscore=974 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909250153 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 17:19:59 -0000 SnVzdCBkbyBvbmUuDQoNCu+7v09uIDkvMjUvMTksIDE6MDUgUE0sICJCbGFjaywgRGF2aWQiIDxE YXZpZC5CbGFja0BkZWxsLmNvbT4gd3JvdGU6DQoNCiAgICBZZXMsIGFuZCBTSEEzLTI1NiAgd2hp bGUgd2UncmUgaW4gdGhlcmUgLi4uIEkgcGxhbiB0byBzdWJtaXQgdGhlIHJlcXVlc3QgdG8gSUFO QSB0byBkbyB0aGF0IGJ5IGVhcmx5IG5leHQgd2Vlay4NCiAgICANCiAgICBUaGFua3MsIC0tRGF2 aWQNCiAgICANCiAgICA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgPiBGcm9tOiBQ ZXRlciBHdXRtYW5uIDxwZ3V0MDAxQGNzLmF1Y2tsYW5kLmFjLm56Pg0KICAgID4gU2VudDogVHVl c2RheSwgU2VwdGVtYmVyIDI0LCAyMDE5IDEwOjU0IEFNDQogICAgPiBUbzogQmxhY2ssIERhdmlk OyBzYWFnQGlldGYub3JnDQogICAgPiBDYzogTWF1cml6aW8gTG9tYmFyZGkNCiAgICA+IFN1Ympl Y3Q6IFJlOiBbc2FhZ10gSW1wcm92aW5nIHRoZSBDSEFQIHByb3RvY29sDQogICAgPiANCiAgICA+ IA0KICAgID4gQmxhY2ssIERhdmlkIDxEYXZpZC5CbGFja0BkZWxsLmNvbT4gd3JpdGVzOg0KICAg ID4gDQogICAgPiA+VGhlIHNpdHVhdGlvbiB0aGF0IHdlIGNhbid0IGNoYW5nZSBpcyB0aGF0IGlT Q1NJIHJlZmVyZW5jZXMgdGhlIElBTkEgUFBQIENIQVANCiAgICA+ID5yZWdpc3RyeSBmb3IgQ0hB UCBoYXNoIGFsZ29yaXRobXMuDQogICAgPiANCiAgICA+IFNvIHdvdWxkIHRoZSBzaW1wbGVzdCBz b2x1dGlvbiB0aGVuIGJlIGp1c3QgdG8gYWRkIFNIQS0yNTYgdG8gdGhlIHJlZ2lzdHJ5Pw0KICAg ID4gDQogICAgPiBQZXRlci4NCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KICAgIHNhYWcgbWFpbGluZyBsaXN0DQogICAgc2FhZ0BpZXRm Lm9yZw0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KICAg IA0KDQo= From nobody Wed Sep 25 10:35:25 2019 Return-Path: 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 6844A120121 for ; Wed, 25 Sep 2019 10:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 X4AOeatftSoU for ; Wed, 25 Sep 2019 10:35:21 -0700 (PDT) Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A83B1201DE for ; Wed, 25 Sep 2019 10:35:21 -0700 (PDT) Received: from Jude (192.168.1.159) by mail2.augustcellars.com (192.168.1.201) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Wed, 25 Sep 2019 10:35:14 -0700 From: Jim Schaad To: "'Black, David'" , References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com>, <1569336830344.45369@cs.auckland.ac.nz> In-Reply-To: Date: Wed, 25 Sep 2019 10:35:13 -0700 Message-ID: <01ae01d573c7$97de44b0$c79ace10$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQJuUtirWZsZ6Nr59C8ioM7oqEO5NwIncRnTAeAhwvEBcFmTvwHpYQBrAs21KHuluXE2MA== Content-Language: en-us X-Originating-IP: [192.168.1.159] Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 17:35:24 -0000 If you do that, I don't know if you want SHA3-256 or SHAKE. SHAKE seems to be used more from what I have seen so far. Jim -----Original Message----- From: saag On Behalf Of Black, David Sent: Wednesday, September 25, 2019 10:04 AM To: Peter Gutmann ; saag@ietf.org Subject: Re: [saag] Improving the CHAP protocol Yes, and SHA3-256 while we're in there ... I plan to submit the request to IANA to do that by early next week. Thanks, --David > -----Original Message----- > From: Peter Gutmann > Sent: Tuesday, September 24, 2019 10:54 AM > To: Black, David; saag@ietf.org > Cc: Maurizio Lombardi > Subject: Re: [saag] Improving the CHAP protocol > > > Black, David writes: > > >The situation that we can't change is that iSCSI references the IANA > >PPP CHAP registry for CHAP hash algorithms. > > So would the simplest solution then be just to add SHA-256 to the registry? > > Peter. _______________________________________________ saag mailing list saag@ietf.org https://www.ietf.org/mailman/listinfo/saag From nobody Wed Sep 25 11:08:41 2019 Return-Path: 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 EF0E6120891 for ; Wed, 25 Sep 2019 11:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=a5vPc7Y0; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=gU4DvZV2 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 vzr2966g-gaP for ; Wed, 25 Sep 2019 11:08:37 -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 E715B120885 for ; Wed, 25 Sep 2019 11:08:36 -0700 (PDT) Received: from pps.filterd (m0170394.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8PI4glC000882; Wed, 25 Sep 2019 14:08:28 -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=4oKNfmFm5MYdBZTOtGR3I0l4kh0RN1vju606V/MsnNI=; b=a5vPc7Y0ItDCVc06s3lzHmDJDOmGtYsKAgtyVQl/kzhLpRvLsucQxWjgtoZ9mVEWkQxs 2g21MgH7CiFv7Jr3M5ShKG22aii40s1VQX0AIFjQQtIBPWt2bXnonevOJUqckcl51vgB +PI700y8ihGV3GvkjbfRk0kJl9hlWFOjNO3txMt5yDMWrP9peqlhj8QX/lnPmB6B/8dZ OpgF9A5oMXp+fL0UIERNZbCDJG2o2hkz+toAK3YBrz2gWsd0RrRV/ppLj2I+EifY09os 8lP+NHJAEeb+eIQFSHXg+Q7XhYprtIPrNVAyK0gj2WnE4PNcPQCrH5nn0/3vAuP8d1yR AA== Received: from mx0b-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2v8cavg93b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Sep 2019 14:08:27 -0400 Received: from pps.filterd (m0089483.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8PI39i9012638; Wed, 25 Sep 2019 14:08:27 -0400 Received: from mailuogwdur.emc.com (mailuogwdur-nat.lss.emc.com [128.221.224.79] (may be forged)) by mx0b-00154901.pphosted.com with ESMTP id 2v83j2m6y5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 25 Sep 2019 14:08:27 -0400 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd54.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8PI8Gfo020701 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 25 Sep 2019 14:08:26 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd54.lss.emc.com x8PI8Gfo020701 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1569434906; bh=P2+EhtbYMO8OfKwZrE8stYw1M3o=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=gU4DvZV2Sqvw9NYEAh9M3uwWBcCQZc7owNGqHvRxotXnQTElpyoX3YRJ2iHxy9cgI xFQrNlX4weVR7F+QMkKV4n8GbZy7tWXDpUUTaRfN69dVpfpr+TwI6OVmtwp13izPJZ QXLTfWevdpfvtQ44enBrveOk9p8NRdN+zcU7JGCQ= Received: from mailusrhubprd01.lss.emc.com (mailusrhubprd01.lss.emc.com [10.253.24.19]) by maildlpprd55.lss.emc.com (RSA Interceptor); Wed, 25 Sep 2019 14:07:54 -0400 Received: from MXHUB307.corp.emc.com (MXHUB307.corp.emc.com [10.146.3.33]) by mailusrhubprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8PI7sO3020754 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Wed, 25 Sep 2019 14:07:55 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB307.corp.emc.com ([10.146.3.33]) with mapi id 14.03.0439.000; Wed, 25 Sep 2019 14:07:54 -0400 From: "Black, David" To: Jim Schaad , "saag@ietf.org" Thread-Topic: [saag] Improving the CHAP protocol Thread-Index: AQHVbhyVNSLAH6mw10yrI1pLte3B86c2rMeAgAKtrQCAAEGFkIABmpwAgAFzOzCAAEwxgP//xXLQ Date: Wed, 25 Sep 2019 18:07:54 +0000 Message-ID: References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com>, <1569336830344.45369@cs.auckland.ac.nz> <01ae01d573c7$97de44b0$c79ace10$@augustcellars.com> In-Reply-To: <01ae01d573c7$97de44b0$c79ace10$@augustcellars.com> 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-25T18:07:28.8351643Z; 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.105.8.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd01.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-25_08:2019-09-25,2019-09-25 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 bulkscore=0 phishscore=0 impostorscore=0 malwarescore=0 suspectscore=0 clxscore=1011 adultscore=0 mlxscore=0 mlxlogscore=905 spamscore=0 lowpriorityscore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909250156 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 mlxlogscore=993 impostorscore=0 phishscore=0 clxscore=1011 priorityscore=1501 mlxscore=0 spamscore=0 bulkscore=0 adultscore=0 lowpriorityscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909250156 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 18:08:39 -0000 I strongly prefer two, as none of the current hashes in the registry (MD5, = SHA1) ought to be used for new development, so registering two good hashes = would provide a fallback just in case unexpected crypto progress occurs in = attacks on SHA2 or SHA3. Thanks, --David > -----Original Message----- > From: Jim Schaad > Sent: Wednesday, September 25, 2019 1:35 PM > To: Black, David; saag@ietf.org > Subject: RE: [saag] Improving the CHAP protocol >=20 >=20 > [EXTERNAL EMAIL] >=20 > If you do that, I don't know if you want SHA3-256 or SHAKE. SHAKE seems = to > be used more from what I have seen so far. >=20 > Jim >=20 >=20 > -----Original Message----- > From: saag On Behalf Of Black, David > Sent: Wednesday, September 25, 2019 10:04 AM > To: Peter Gutmann ; saag@ietf.org > Subject: Re: [saag] Improving the CHAP protocol >=20 > Yes, and SHA3-256 while we're in there ... I plan to submit the request = to > IANA to do that by early next week. >=20 > Thanks, --David >=20 > > -----Original Message----- > > From: Peter Gutmann > > Sent: Tuesday, September 24, 2019 10:54 AM > > To: Black, David; saag@ietf.org > > Cc: Maurizio Lombardi > > Subject: Re: [saag] Improving the CHAP protocol > > > > > > Black, David writes: > > > > >The situation that we can't change is that iSCSI references the IANA > > >PPP CHAP registry for CHAP hash algorithms. > > > > So would the simplest solution then be just to add SHA-256 to the > registry? > > > > Peter. >=20 > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag From nobody Wed Sep 25 12:11:30 2019 Return-Path: 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 A21AA120288 for ; Wed, 25 Sep 2019 12:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net 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 dZewaa-H4AfH for ; Wed, 25 Sep 2019 12:11:27 -0700 (PDT) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (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 E2AC112022C for ; Wed, 25 Sep 2019 12:11:26 -0700 (PDT) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8PJ9lPm014207; Wed, 25 Sep 2019 12:11:16 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=19qIpN2313AytDBW9NyviGSS7dM0HC3rmeZ0Hg1ywUc=; b=GnpQQFiCD3s1cD1KqlU0uf8cowFEcuXUwYuaB8EO5Dy7G9SFX16L9pGSWRnnWMO5Rcky 6kalje0hQ+CS2N1VSVDJCYFzZAKK4DIePttKAQoJ8v/QPkWFZ6xrE45JcC5UrMuO0c20 CR1IX6PQQoymSukSTUEtAUNzkgJR23J6ZRhgMfJNdwUbpDyQGXf13g4VbeQFxodkoB4J V62SBYT9nNQGyGYr0ryhFg9GeHwiyg706QmajrF5LnlWG3me0AmeE1fLRM0FUpd4Lm2T 6HPSq67wFHszPxsqMoV2cDFxU9QkOZcfP6qoTayyBTjtlEJXYuPLBS0K5vrrbtHARzeP DA== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp2054.outbound.protection.outlook.com [104.47.36.54]) by mx0b-00273201.pphosted.com with ESMTP id 2v7kv2tnhp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 25 Sep 2019 12:11:15 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=d2qBSuOCdt2xzSw5Ni333AsB8WnePIOZ702dNLI4biBhXvoBAGMjCwD6kJnLQnsomotNT6dewc2AfOei2HbPLc2WJWCsKhvUFdpF2irivrgi9e7GeGx8gkxHh/9sH5JJcQirWNuavIK9sd7G050gETAU5h/IhnEjlQw6fkHFRP7oE0ob8vuaKPArcGvEhf+TrSpWHxp5dQ/oRQFHzB/boxy4jhmCwkb5Co+1O66z/h/7VnUbEThqMD0Zvylz5wt9KlYmYBEKsKzSyaSZQC7pDB7khZAHwCfcYz53edkUnt/C2vbVf0UiDJJbVbf0sw1CN8TJX5J9ESyMqYFlaV/kwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=19qIpN2313AytDBW9NyviGSS7dM0HC3rmeZ0Hg1ywUc=; b=M9oiF5B6nvg1i4uxi7j2rOm6oztHbcd38iftalIK1bjVl27Bd4SLQpc9GNApXsDxV/cWIGDwx8lBuKds2G5wvvzUrEyKHaEhTaBUDLlFKd0XJQFUDBzc4Z1wZkCZ/eLAZ2HqCWOGQ0M7Ie1XCHQH7yXEl+ukMThL5IivwQn205vuXQitlFJl5D/SlE74CmK7YTavGbpLtCVfgk0xFP4oaM1kRyMr9S2AQxaPoYLC96ZWTmMuDZdN4KL2+3JgNesJmwragWMck1KKm4f/zaXZh+Hdn6uxgQbktKVSOxCfJgfeRZ4U55dLX5nQnoS68/RVVaZVAlFbSI7G8qQZQDBJ6g== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.242.12) smtp.rcpttodomain=ietf.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none Received: from BL0PR05CA0023.namprd05.prod.outlook.com (2603:10b6:208:91::33) by MN2PR05MB7086.namprd05.prod.outlook.com (2603:10b6:208:193::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.11; Wed, 25 Sep 2019 19:11:12 +0000 Received: from BY2NAM05FT005.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e52::206) by BL0PR05CA0023.outlook.office365.com (2603:10b6:208:91::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.11 via Frontend Transport; Wed, 25 Sep 2019 19:11:12 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.242.12 as permitted sender) Received: from P-EXFEND-EQX-01.jnpr.net (66.129.242.12) by BY2NAM05FT005.mail.protection.outlook.com (10.152.100.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.2305.15 via Frontend Transport; Wed, 25 Sep 2019 19:11:12 +0000 Received: from P-EXBEND-EQX-02.jnpr.net (10.104.8.53) by P-EXFEND-EQX-01.jnpr.net (10.104.8.54) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 25 Sep 2019 12:11:11 -0700 Received: from P-EXBEND-EQX-01.jnpr.net (10.104.8.52) by P-EXBEND-EQX-02.jnpr.net (10.104.8.53) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Wed, 25 Sep 2019 12:11:11 -0700 Received: from p-mailhub01.juniper.net (10.104.20.6) by P-EXBEND-EQX-01.jnpr.net (10.104.8.52) with Microsoft SMTP Server (TLS) id 15.0.1367.3 via Frontend Transport; Wed, 25 Sep 2019 12:11:11 -0700 Received: from contrail-ubm16-mdb.svec1.juniper.net ([10.163.18.199]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id x8PJB9KQ012555; Wed, 25 Sep 2019 12:11:10 -0700 (envelope-from mdb@juniper.net) To: Jim Schaad CC: David Black , In-Reply-To: <01ae01d573c7$97de44b0$c79ace10$@augustcellars.com> References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com>, <1569336830344.45369@cs.auckland.ac.nz> <01ae01d573c7$97de44b0$c79ace10$@augustcellars.com> Comments: In-reply-to: Jim Schaad message dated "Wed, 25 Sep 2019 10:35:13 -0700." From: "Mark D. Baushke" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <26765.1569438669.1@contrail-ubm16-mdb.svec1.juniper.net> Date: Wed, 25 Sep 2019 12:11:09 -0700 Message-ID: <26766.1569438669@contrail-ubm16-mdb.svec1.juniper.net> X-EXCLAIMER-MD-CONFIG: e3cb0ff2-54e7-4646-8a04-0dae4ac7b136 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.242.12; IPV:CAL; SCL:-1; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(4636009)(376002)(396003)(346002)(39860400002)(136003)(199004)(189003)(186003)(478600001)(6916009)(46406003)(97876018)(76130400001)(81156014)(14444005)(8676002)(81166006)(8936002)(23726003)(5660300002)(76176011)(70206006)(97756001)(47776003)(305945005)(4326008)(126002)(26005)(316002)(11346002)(16586007)(4744005)(2906002)(336012)(476003)(426003)(70586007)(446003)(54906003)(486006)(86362001)(7696005)(356004)(26826003)(6246003)(117636001)(50466002)(229853002)(62816006); DIR:OUT; SFP:1102; SCL:1; SRVR:MN2PR05MB7086; H:P-EXFEND-EQX-01.jnpr.net; FPR:; SPF:SoftFail; LANG:en; PTR:InfoDomainNonexistent; A:1; MX:1; X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 04996dd2-054f-4347-3245-08d741ec2127 X-MS-TrafficTypeDiagnostic: MN2PR05MB7086: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:7219; X-Forefront-PRVS: 01713B2841 X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: LKw8UNYPoSDAX4XzEJi+QKdUxNUowYP3b+thiGUZyv6ffJBl1yh9845l5O9AKo458y82B77bKe/RFctMnqHlaNV2BfpbhkYcotoeiRwVeSc4dIrfI4/DbHiGPeqKIm7UBtepUZvJipM7hoaZ06fMIyS3c2fwxJ5HiGgFLpEWkQCBRluVJHIEqD7Yad8oU9oTmbyBRSljt4i0V8HBhO6pPBaddw+BwD6/gi1k+Qbtdq84djsB/rS2bBo43SBczlkoocjMKi8pcCPEyG7pZ4dtwDtSlKVBmbYaPS3ikU9tOTjFBTuvNdwJabAeEm3DEAbvs8QGHmZBYsO7qD0HUl5Q7/rXwy9ASfRcNdqlCTurL8+oYrIVjgd12cvFRBGrTMDY4j3kgei+kxDjyeBY5lga2WnKZmYU1mWQAOzQOVD3nu8= X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Sep 2019 19:11:12.0278 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 04996dd2-054f-4347-3245-08d741ec2127 X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.242.12]; Helo=[P-EXFEND-EQX-01.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR05MB7086 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-25_08:2019-09-25,2019-09-25 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 mlxscore=0 suspectscore=1 mlxlogscore=472 bulkscore=0 phishscore=0 spamscore=0 lowpriorityscore=0 priorityscore=1501 adultscore=0 clxscore=1011 malwarescore=0 impostorscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909250160 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Sep 2019 19:11:29 -0000 Jim Schaad writes: > If you do that, I don't know if you want SHA3-256 or SHAKE. SHAKE > seems to be used more from what I have seen so far. I think SHAKE256 is the better entry in my opinion if you want something for the future. I believe you will find implementations in popular crypto libraries (provided in alphabetical order) such as Bouncy Castle, Crypto++, Libgcrypt, and OpenSSL. -- Mark From nobody Thu Sep 26 00:45:32 2019 Return-Path: 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 9CC7512080F for ; Thu, 26 Sep 2019 00:45:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 DvRfYPk01hS4 for ; Thu, 26 Sep 2019 00:45:26 -0700 (PDT) Received: from EUR03-AM5-obe.outbound.protection.outlook.com (mail-eopbgr30071.outbound.protection.outlook.com [40.107.3.71]) (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 8833312004C for ; Thu, 26 Sep 2019 00:45:26 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OBOKNObZc2YFJNS38PmU548g0oTpLFo8Ux6kvTSU+DGVRxlB/BNLxkGEjcISPlRlNmAptPunFe8t4tNXGaOPfkBuR9HV6zob8kOOe53U8NMyA7pooBDEuAfS7ZItAwRt10KSD8l4lKSe/ypHfs6SajQsjALoEkB8CZuvN0aRV0FtDwGxi/SfxsKK65Da9jp4kcsRxmMbMEWEfVb7i3G51Xr7VQzx8TX+N4hjYMQ4KKJqOLypwLl6op19YpOvJkXuz0VcXwSMD4kqXRhmEXWgErlR0SMbDYnrKFyin+aRr26RLkBiU6AE3EcR6kZ8IB1j6MActtJRpXUSQiBx3yGqew== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YBFOGad8Xpa7ZoOeypwILdAoQ0D0RcFavmUJtsMTTPk=; b=jhlTyQTsRo49UO7579fW7YT6rUYqcs+Esj8rg41rwNtH4crWbKTQrfvLBSrlnEDQaqPT8R3yb20jSTVaZReRKX/ZHV9S8SZ7aHXq4ljjDURNoOHQhAZoDgVxXc7/X+4dOO1y1nOiOGNNytVFgIvkCdWLRKY+8+9UNqFKiC+W++LgFpct7J+2k11ZhIOhlCY+WNIlYBJortA5Sgz0SxqjdX85LFeAObLeN7bQHEybzndGonSbcgTEY4vKf6KOO0H0i57nkQZbnrR6CToux7rpPyn1VsrCT4aZhVcBKWdBJw8BakJBaKhTyeQL3F3S+N0V6vMBY+d0Rp5p4K8q+SSPjg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YBFOGad8Xpa7ZoOeypwILdAoQ0D0RcFavmUJtsMTTPk=; b=b9PApeQjgxTY0ojqeLO+dERqvEWPPFS1dyrvA3eV7yebE+8ZxF/O6V40FnSNJlbK+c9I4e5cQyKq1DYOyA297XBONPX7kEftCDN8KdU25mm6dD6VOc4RaBQSbUd6choyC+DYRzw0v9XRrKiUg1rHraCcxGXMW/VdWZ+zhhRg7Kw= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB4379.eurprd07.prod.outlook.com (20.176.164.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2327.9; Thu, 26 Sep 2019 07:45:24 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2305.013; Thu, 26 Sep 2019 07:45:24 +0000 From: John Mattsson To: "Mark D. Baushke" , Jim Schaad CC: "saag@ietf.org" Thread-Topic: [saag] Improving the CHAP protocol Thread-Index: AQHVbhyYCYcHWGngr0yyn5sVfxkQYac2abmAgAKtrACAAJaMgIABRZYAgAG2o4CAAAjIgIAAGs6AgAD0QoA= Date: Thu, 26 Sep 2019 07:45:24 +0000 Message-ID: <2558A4D5-B732-4862-9692-A86735A82BD1@ericsson.com> References: <9641f69d-0ffb-1c1d-7fb6-98ef4a54ad2c@redhat.com> <1569087342890.52733@cs.auckland.ac.nz> <4354cf7e-74f2-d36c-5fa0-587a2118a507@redhat.com> <1569336830344.45369@cs.auckland.ac.nz> <01ae01d573c7$97de44b0$c79ace10$@augustcellars.com> <26766.1569438669@contrail-ubm16-mdb.svec1.juniper.net> In-Reply-To: <26766.1569438669@contrail-ubm16-mdb.svec1.juniper.net> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [78.78.62.177] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d69a20ef-2aaa-4d64-7f41-08d742557d9e x-ms-traffictypediagnostic: HE1PR07MB4379: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0172F0EF77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(366004)(39860400002)(346002)(376002)(396003)(13464003)(189003)(199004)(99286004)(86362001)(486006)(14444005)(5660300002)(71200400001)(71190400001)(36756003)(186003)(76176011)(476003)(446003)(25786009)(26005)(2616005)(478600001)(256004)(14454004)(44832011)(66066001)(102836004)(6506007)(966005)(53546011)(8936002)(305945005)(76116006)(66946007)(11346002)(7736002)(66446008)(64756008)(66476007)(66556008)(8676002)(6436002)(110136005)(3846002)(33656002)(6116002)(58126008)(81166006)(81156014)(316002)(6246003)(4326008)(229853002)(6486002)(2906002)(6512007)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4379; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: L7jiXq+GkjHTi/CpOjvpNYTfhuGWDRp3doU2SWELBdRQ/fvw24TRgr1IED0XgrscHG96ja3jMUAsheJmv6c5+q21h2NYvzEtf5LUwvnwkKPtpKLdIHgQsGDlMUH8HL8mnh0U51ZTWTbC6T3pBNDyScJRvR/bcyWBKc036KU9mC4BYFxVEDvgCRRAW/NCxKe1zHtlQGX8wSSA713EEDwprI92GhwO7GdXxWf57I6XLUKUL1D9nUZt7Yyby/S3lH8lgd7luAyJ0VgwHn8WQ3YEBwj4BiQHH0gL61EPp5vm/86kmKEpeue+CAi1TfWWbZJDBqjOhMnEV0+jW0T6m9/PHxq+IsgTvakcweMwSt/eXokRq1SI/k275sqkmh+JJ+az75DAAvVuFCDdnGRWe5J0ltVtmRZAMy9V4ASCJbEnsPW4bEYQ0mCaXhTexZr7czFDJZ17KlqC4IkbD7ROenlLeg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <3F5554FC2CA8FC43B9DBE435C79051F7@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: d69a20ef-2aaa-4d64-7f41-08d742557d9e X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2019 07:45:24.2337 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 6E99xOIJBJC1ng1uw4ayeAm4ejzCZZCsdfFGO+Mggg+dni+tHfc+JsdA8a5zaklaHNv+j/AibbkSmFdeGaPebBPV3JZ130rH+Cy/14RC/VI= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4379 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 07:45:30 -0000 SSB3b3VsZCBhbHNvIHByZWZlciBTSEFLRSBjb21wYXJlZCB0byBTSEEzLTI1Ni4gSSB0aGluayBT SEFLRTEyOCBvZmZlciBlbm91Z2ggc2VjdXJpdHkgZm9yIHRoZSBmb3Jlc2VlYWJsZSBmdXR1cmUs IGJ1dCBqdXN0IFNIQUtFMjU2IG1heSBiZSBiZXR0ZXIgaWYgd2Ugd2FudCBhIHNpbmdsZSBhbGdv cml0aG0gdG8gZnVsZmlsIDI1Ni1iaXQgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGZyb20gZS5nLiBn b3Zlcm5tZW50cy4gRG8vd2lsbCBhbnkgY29uc3RyYWluZWQgSW9UIGRldmljZXMgdXNlIENIQVA/ IFRoZW4gdGhlaXIgcmVxdWlyZW1lbnRzIHNob3VsZCBiZSB0YWtlbiBpbnRvIGFjY291bnQuDQoN Ci9Kb2huDQoNCu+7vy0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzYWFnIDxzYWFn LWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiAiTWFyayBELiBCYXVzaGtlIiA8bWRiPTQw anVuaXBlci5uZXRAZG1hcmMuaWV0Zi5vcmc+DQpEYXRlOiBXZWRuZXNkYXksIDI1IFNlcHRlbWJl ciAyMDE5IGF0IDIxOjExDQpUbzogSmltIFNjaGFhZCA8aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbT4N CkNjOiAic2FhZ0BpZXRmLm9yZyIgPHNhYWdAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW3NhYWdd IEltcHJvdmluZyB0aGUgQ0hBUCBwcm90b2NvbA0KDQogICAgSmltIFNjaGFhZCA8aWV0ZkBhdWd1 c3RjZWxsYXJzLmNvbT4gd3JpdGVzOg0KICAgIA0KICAgID4gSWYgeW91IGRvIHRoYXQsIEkgZG9u J3Qga25vdyBpZiB5b3Ugd2FudCBTSEEzLTI1NiBvciBTSEFLRS4gU0hBS0UNCiAgICA+IHNlZW1z IHRvIGJlIHVzZWQgbW9yZSBmcm9tIHdoYXQgSSBoYXZlIHNlZW4gc28gZmFyLg0KICAgIA0KICAg IEkgdGhpbmsgU0hBS0UyNTYgaXMgdGhlIGJldHRlciBlbnRyeSBpbiBteSBvcGluaW9uIGlmIHlv dSB3YW50IHNvbWV0aGluZw0KICAgIGZvciB0aGUgZnV0dXJlLg0KICAgIA0KICAgIEkgYmVsaWV2 ZSB5b3Ugd2lsbCBmaW5kIGltcGxlbWVudGF0aW9ucyBpbiBwb3B1bGFyIGNyeXB0byBsaWJyYXJp ZXMNCiAgICAocHJvdmlkZWQgaW4gYWxwaGFiZXRpY2FsIG9yZGVyKSBzdWNoIGFzIEJvdW5jeSBD YXN0bGUsIENyeXB0bysrLA0KICAgIExpYmdjcnlwdCwgYW5kIE9wZW5TU0wuDQogICAgDQogICAg CS0tIE1hcmsNCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgIHNhYWcgbWFpbGluZyBsaXN0DQogICAgc2FhZ0BpZXRmLm9yZw0KICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2FhZw0KICAgIA0KDQo= From nobody Thu Sep 26 05:18:08 2019 Return-Path: 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 8C77C12013B; Thu, 26 Sep 2019 05:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.028 X-Spam-Level: X-Spam-Status: No, score=-2.028 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 fOF0yOIXF6Wl; Thu, 26 Sep 2019 05:17:59 -0700 (PDT) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-eopbgr80074.outbound.protection.outlook.com [40.107.8.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57F30120123; Thu, 26 Sep 2019 05:17:59 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=h1GnpLbDXDPiOF8mNk3MctX8Er9ejFJL/2Z3Y7NzPKzb8Kd885SrT9r3Fd8s53soLJ5Mj7wB/g836ZiSRFzD2CBwLn6WvtuxDDRyim7Sl5sMl01SkJHSxa3jLjn7lZpEpzxd3z7nQGa7yAUpNJKwPyaf3WwIUYfitZq61yda4k+wzJq1aKE1jYuUQ8ceFFRNyBew1WFixhC5BR51XhNNhCQheZutxYDg7qpPhOHCmju7MEmqZ09jRikeGJgcXp1hmwn69LJ3X9XVf76TFtR48lTkUpLFtU7g6UqFj547p8kEVg90w5ArZCF4p6puj12Xgc8SrrUIFgTTFyOcplu3CA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6BebWLUVQpUIKEwxD4aM7vNVpbiSo65dOQlRxvVgtlA=; b=VIs2Cdf9LeiEAuQFGlOLgnnexxejg5Rrt49W8KgiRSiC4+b+CfDSTGqgs63AyHZsE+dUXXVD+PKoxr+puVqdOJUCB6HnS8vL50i+ci4Yu7TLJnTlbrB2vjJHQ/L8EMf6dNQ37PNGF/XnSgEYjyiMFUVDjNzgqbp+yBfS7Jzp332W92SmXGOv85BJ9XgGcd1Spj4bOaQBOZausBu7a3WFeT6x0vzFioRdgyrzP/e7beohRIBqD0s9nIxYbL08OUeQyeaPbXSGzk2PhuC0bwooI9IlhC/reXt1qemTrJro+Kifo0LcrgSW2yUI3DDZ14ihU34T4rX10K0YTynzLPOIFA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6BebWLUVQpUIKEwxD4aM7vNVpbiSo65dOQlRxvVgtlA=; b=RO3PozcewCItqpPPDSuNbSlRDoa3MwHMSxBT+JZKPD9Y63NyhbkdH5xYckvMaZ7PoFnHdDpf+ZrL3RMycQiHAFYAU/Gilwj12EzRhS4xoncm+JZAIOfo2dTtvuaKOw/W0wvCk2CZXERRc+CWVIdUdjbxSCd6Qh+UPpNydPkRWww= Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB3484.eurprd07.prod.outlook.com (10.170.247.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2305.15; Thu, 26 Sep 2019 12:17:57 +0000 Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::c8fb:acc1:b00e:84ef%6]) with mapi id 15.20.2305.013; Thu, 26 Sep 2019 12:17:57 +0000 From: John Mattsson To: "TLS@ietf.org" , "saag@ietf.org" Thread-Topic: Lessons learned from TLS 1.0 and TLS 1.1 deprecation Thread-Index: AQHVdGRuT2dEqLFcbEmEm2g+1AcjWQ== Date: Thu, 26 Sep 2019 12:17:56 +0000 Message-ID: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com; x-originating-ip: [78.78.62.177] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 12dccb2c-83fb-4291-697d-08d7427b90a1 x-ms-traffictypediagnostic: HE1PR07MB3484: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0172F0EF77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(136003)(39860400002)(376002)(396003)(199004)(189003)(6486002)(26005)(102836004)(2616005)(36756003)(86362001)(186003)(476003)(44832011)(486006)(76116006)(7736002)(66946007)(6512007)(305945005)(2501003)(66476007)(66556008)(64756008)(66446008)(99286004)(256004)(8676002)(71200400001)(6436002)(81166006)(6116002)(5660300002)(478600001)(25786009)(3846002)(71190400001)(33656002)(14444005)(66066001)(316002)(6506007)(81156014)(58126008)(110136005)(8936002)(450100002)(14454004)(66574012)(2906002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3484; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kejBAQh1wUIQpu7M79hS9aZgvy+LE6tT4FER6G/0OfLGqoN7p1PG7MvVLADaF8+y/Vr3b5yeFpE/Mb4AiAnAdmWAeu2Cht6Q5A7U6UsxkpKlftRfqOS1VxJw7PziQTenEVo3Zdcwa8peDCENSl2H9UTFd3S/8GGIgW3nNAfzBq4b1+k28SgcTY/tYFdi3hBl6RupvfCt4H2b54audcVhtSAMLLQQIkFjFLaixqHTwYQT7aHK5ebykKhLCv2fe3wGHYBqfxSSqvfsvxS1dw5gYiFQIqsxUvGjOsf+uiqKU7kiXWRiTJngp/hL219kggKBYdeHE3tmuoeiVGEzbblq3/cFtTQiXj+KwQcCs/t/wrOxIwgftOo9Hbvdcg9DBJTK/0Q6Yd5kDNlXJav5WGqjKLLyMsuFTQ1y/zHZroI2LiM= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-Network-Message-Id: 12dccb2c-83fb-4291-697d-08d7427b90a1 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Sep 2019 12:17:56.9403 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: rWe8ZmxdOCl/mXX9TOGx2Ac5zYyfqlgw1SAdrt76HVHqHjNadfMNuBjtEZri7yV9e5qr4RlAXvSs/BdNkUINJWCqeisoLnoFH5bcd3QPAvs= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3484 Archived-At: Subject: [saag] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 12:18:02 -0000 SGksDQoNCkhvcGVmdWxseSwgd2UgaGF2ZSBsZWFybmVkIHNvbWUgbGVzc29ucyBmcm9tIHRoZSBU TFMgMS4wIGFuZCBUTFMgMS4xIGRlcHJlY2F0aW9uLiBUTFMgMS4wIGFuZCBUTFMgMS4xIGFyZSAo dG8gY2l0ZSBNYXJ0aW4gVGhvbXNvbikgYnJva2VuIGluIGEgbXlyaWFkIHN1YnRsZSB3YXlzIGFu ZCBzaG91bGQgYWNjb3JkaW5nIHRvIG1lIG9wdGltYWxseSBoYXZlIGJlZW4gZGVwcmVjYXRlZCB5 ZWFycyBhZ28uDQoNCjNHUFAgbWFuZGF0ZWQgc3VwcG9ydCBvZiBUTFMgMS4yIGluIFJlbC0xMyAo MjAxNSkgYnV0IGNvdWxkIGF0IHRoYXQgdGltZSBub3QgZm9yYmlkIHVzZSBvZiBUTFMgMS4xIGFz IHRoYXQgd291bGQgcG90ZW50aWFsbHkgYnJlYWsgaW50ZXJvcGVyYWJpbGl0eSB3aXRoIHNvbWUg UmVsLTEyIG5vZGVzICh0aGF0IGhhZCBUTFMgMS4yIGFzIHNob3VsZCBzdXBwb3J0KS4gVGhlIGxl c3NvbiAzR1BQIGxlYXJuZWQgZnJvbSB0aGlzIHdhcyB0aGUgbmVlZCB0byBhcyBlYXJseSBhcyBw b3NzaWJsZSBtYW5kYXRlIHN1cHBvcnQgb2YgbmV3IHByb3RvY29sIHZlcnNpb25zLiBXaXRoIFRM UyAxLjMsIDNHUFAgdG9vayBhY3Rpb24gZWFybHkgYW5kIFRMUyAxLjMgc3VwcG9ydCB3YXMgbWFu ZGF0ZWQgZm9yIG5ldHdvcmsgbm9kZXMgaW4gUmVsLTE1ICgyMDE4KSBhbmQgZm9yIG1vYmlsZSBw aG9uZXMgaW4gUmVsLTE2ICgyMDE5KS4NCg0KQXQgc29tZSBwb2ludCBpbiB0aW1lIHdlIHdpbGwg d2FudCB0byBkZXByZWNhdGUgVExTIDEuMi4gVG8gZW5hYmxlIHRoYXQsIFRMUyAxLjMgc3VwcG9y dCBzaG91bGQgYmUgbWFuZGF0ZWQgb3IgZW5jb3VyYWdlZCBhcyBtdWNoIGFzIHBvc3NpYmxlLiBJ IHdvdWxkIGxpa2UgdG8gYXZvaWQgYSBzaXR1YXRpb24gd2hlcmUgd2Ugd2FudCB0byBkZXByZWNh dGUgVExTIDEuMiBidXQgcmVhbGl6ZSB0aGF0IGl0IGNhbm5vdCBiZSBkb25lIGJlY2F1c2Ugc29t ZSBpbXBsZW1lbnRhdGlvbnMgb25seSBzdXBwb3J0IFRMUyAxLjIuIEhvdyBjYW4gSUVURiBlbmFi bGUgc21vb3RoZXIgYW5kIGZhc3RlciBkZXByZWNhdGlvbnMgaW4gdGhlIGZ1dHVyZT8gVGhlIGJy b3dzZXIgaW5kdXN0cnkgaGFzIGEgZGVjZW50IHRyYWNrIHJlY29yZCBvZiBhbGdvcml0aG0gZGVw cmVjYXRpb24gYW5kIEkgaG9wZSB0byBzb29uIHNlZSB0aGUgZm9sbG93aW5nIHdhcm5pbmcgaW4g bXkgYnJvd3NlcjoNCg0K4oCcVExTIDEuMiBpcyBvYnNvbGV0ZS4gRW5hYmxlIFRMUyAxLjMgb3Ig bGF0ZXIu4oCdDQoNCk90aGVyIGluZHVzdHJpZXMgaGF2ZSBsZXNzIHN0ZWxsYXIgdHJhY2sgcmVj b3JkcyBvZiBhbGdvcml0aG0gZGVwcmVjYXRpb24uDQoNCkhvdyBjYW4gSUVURiBiZSBtb3JlIHBy by1hY3RpdmUgcmVnYXJkaW5nIGRlcHJlY2F0aW9ucyBpbiB0aGUgZnV0dXJlPyBJbiB0aGUgYmVz dCBvZiB3b3Jkcywgbm9ib2R5IHNob3VsZCBiZSBzdXJwcmlzZWQgd2hlbiBJRVRGIGRlcHJlY2F0 ZXMgYSBwcm90b2NvbCB2ZXJzaW9uIG9yIGFsZ29yaXRobS4gTklTVCBhbmQgc2ltaWxhciBvcmdh bml6YXRpb25zIGluIG90aGVyIGNvdW50cmllcyBoYXZlIHRoZSBwcmFjdGljZSB0byBsb25nIHRp bWUgaW4gYWR2YW5jZSBwdWJsaXNoIGRlYWRsaW5lcyBmb3Igc2VjdXJpdHkgbGV2ZWxzLCBhbGdv cml0aG1zLCBhbmQgcHJvdG9jb2wgdmVyc2lvbnMuIENhbiB0aGUgSUVURiBkbyBzb21ldGhpbmcg c2ltaWxhciwgbm90IGp1c3QgZm9yIFRMUyBidXQgaW4gZ2VuZXJhbD8gRm9yIFRMUywgdGhlcmUg YXJlIHNldmVyYWwgdGhpbmdzIHRvIGRlcHJlY2F0ZSwgaW4gYWRkaXRpb24gdG8gTUQ1IGFuZCBT SEEtMSwgYWxzbyBQS0NTMS12MV81LCBSU0EtMjA0OCwgMjI0LWJpdCBFQ0MsIGZmZGhlMjA0OCwg YW5kIG5vbi1yZWNvbW1lbmRlZCBjaXBoZXIgc3VpdGVzIChTdGF0aWMgUlNBLCBDQkMsIERILCBO VUxMLCBldGMuKSBzaG91bGQgYmUgZGVwcmVjYXRlZCBpbiB0aGUgZnV0dXJlLg0KDQpDaGVlcnMs DQpKb2huDQoNCg== From nobody Thu Sep 26 06:03:13 2019 Return-Path: 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 394DE12002F; Thu, 26 Sep 2019 06:03:02 -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=akamai.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 jQMrpvvS0a-r; Thu, 26 Sep 2019 06:03:00 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 A510F12011D; Thu, 26 Sep 2019 06:03:00 -0700 (PDT) Received: from pps.filterd (m0122331.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8QCvtCT003229; Thu, 26 Sep 2019 14:02:40 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+kRdfeIquDcMJbG1l6aIeaJ40NPPCoutthKuFcG02CE=; b=BV+Xo/68xeWPe8HjHsGw/6UTSXL4aMDgaA9Rqz2i7OZDAAnDTR3/ll4k/pZOf2rVr2Vu nfJK4A2nfouynoqB9JIU9oXEIdQTnRKQFVVcoWhHKZ2OhW3+4sm5o8Dk+8KiawHL3Dm5 w3X4gu4seVf4SLcHLmHD5tWgOZ/l+sIV7qtLyi9lGZ9sjSv5TeOjaRJp5qa1GT7sxCxY S6gI1CFe1NRFaQuKQJA7SlhciGIJVMvlzdfMqiiQRFuroJNekpm2bQH3AHv8R+j1Dj5H emxYXPaoRiMj5wwqPLgj91YSSHD3/z725Bn3MkooUAFHhgfwsAiqfOioTiKPLSPBAHIr RA== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18] (may be forged)) by mx0b-00190b01.pphosted.com with ESMTP id 2v73q9m9j1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 26 Sep 2019 14:02:39 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.27/8.16.0.27) with SMTP id x8QD2JhD012567; Thu, 26 Sep 2019 09:02:38 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.57]) by prod-mail-ppoint1.akamai.com with ESMTP id 2v73vpx57e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 26 Sep 2019 09:02:38 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 26 Sep 2019 09:02:37 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1473.005; Thu, 26 Sep 2019 09:02:37 -0400 From: "Salz, Rich" To: John Mattsson , "TLS@ietf.org" , "saag@ietf.org" Thread-Topic: [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation Thread-Index: AQHVdGqrOKnGYrSipku+oSGSF7Gj3Q== Date: Thu, 26 Sep 2019 13:02:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/10.1d.0.190908 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.137] Content-Type: text/plain; charset="utf-8" Content-ID: <6B87407B955D4F468E876499D8E4F91F@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-09-26_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1908290000 definitions=main-1909260122 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-26_06:2019-09-25,2019-09-26 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 priorityscore=1501 impostorscore=0 suspectscore=0 adultscore=0 malwarescore=0 lowpriorityscore=0 clxscore=1011 bulkscore=0 mlxlogscore=999 spamscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909260122 Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 13:03:02 -0000 VGhlc2UgYXJlIGV4Y2VsbGVudCBwb2ludHMuICBQZXJoYXBzIHRoZXkgY2FuIGJlIHNxdWVlemVk IGludG8gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10bHMtb2xk dmVyc2lvbnMtZGVwcmVjYXRlLyAgPyAgSXQncyBiZWVuIHdhaXRpbmcgOTAgZGF5cywgYSBicmll ZiByZXNldCBtaWdodCBub3QgaHVydCA6KQ0KDQrvu79PbiA5LzI2LzE5LCA4OjE4IEFNLCAiSm9o biBNYXR0c3NvbiIgPGpvaG4ubWF0dHNzb249NDBlcmljc3Nvbi5jb21AZG1hcmMuaWV0Zi5vcmc+ IHdyb3RlOg0KDQogICAgSGksDQogICAgDQogICAgSG9wZWZ1bGx5LCB3ZSBoYXZlIGxlYXJuZWQg c29tZSBsZXNzb25zIGZyb20gdGhlIFRMUyAxLjAgYW5kIFRMUyAxLjEgZGVwcmVjYXRpb24uIFRM UyAxLjAgYW5kIFRMUyAxLjEgYXJlICh0byBjaXRlIE1hcnRpbiBUaG9tc29uKSBicm9rZW4gaW4g YSBteXJpYWQgc3VidGxlIHdheXMgYW5kIHNob3VsZCBhY2NvcmRpbmcgdG8gbWUgb3B0aW1hbGx5 IGhhdmUgYmVlbiBkZXByZWNhdGVkIHllYXJzIGFnby4NCiAgICANCiAgICAzR1BQIG1hbmRhdGVk IHN1cHBvcnQgb2YgVExTIDEuMiBpbiBSZWwtMTMgKDIwMTUpIGJ1dCBjb3VsZCBhdCB0aGF0IHRp bWUgbm90IGZvcmJpZCB1c2Ugb2YgVExTIDEuMSBhcyB0aGF0IHdvdWxkIHBvdGVudGlhbGx5IGJy ZWFrIGludGVyb3BlcmFiaWxpdHkgd2l0aCBzb21lIFJlbC0xMiBub2RlcyAodGhhdCBoYWQgVExT IDEuMiBhcyBzaG91bGQgc3VwcG9ydCkuIFRoZSBsZXNzb24gM0dQUCBsZWFybmVkIGZyb20gdGhp cyB3YXMgdGhlIG5lZWQgdG8gYXMgZWFybHkgYXMgcG9zc2libGUgbWFuZGF0ZSBzdXBwb3J0IG9m IG5ldyBwcm90b2NvbCB2ZXJzaW9ucy4gV2l0aCBUTFMgMS4zLCAzR1BQIHRvb2sgYWN0aW9uIGVh cmx5IGFuZCBUTFMgMS4zIHN1cHBvcnQgd2FzIG1hbmRhdGVkIGZvciBuZXR3b3JrIG5vZGVzIGlu IFJlbC0xNSAoMjAxOCkgYW5kIGZvciBtb2JpbGUgcGhvbmVzIGluIFJlbC0xNiAoMjAxOSkuDQog ICAgDQogICAgQXQgc29tZSBwb2ludCBpbiB0aW1lIHdlIHdpbGwgd2FudCB0byBkZXByZWNhdGUg VExTIDEuMi4gVG8gZW5hYmxlIHRoYXQsIFRMUyAxLjMgc3VwcG9ydCBzaG91bGQgYmUgbWFuZGF0 ZWQgb3IgZW5jb3VyYWdlZCBhcyBtdWNoIGFzIHBvc3NpYmxlLiBJIHdvdWxkIGxpa2UgdG8gYXZv aWQgYSBzaXR1YXRpb24gd2hlcmUgd2Ugd2FudCB0byBkZXByZWNhdGUgVExTIDEuMiBidXQgcmVh bGl6ZSB0aGF0IGl0IGNhbm5vdCBiZSBkb25lIGJlY2F1c2Ugc29tZSBpbXBsZW1lbnRhdGlvbnMg b25seSBzdXBwb3J0IFRMUyAxLjIuIEhvdyBjYW4gSUVURiBlbmFibGUgc21vb3RoZXIgYW5kIGZh c3RlciBkZXByZWNhdGlvbnMgaW4gdGhlIGZ1dHVyZT8gVGhlIGJyb3dzZXIgaW5kdXN0cnkgaGFz IGEgZGVjZW50IHRyYWNrIHJlY29yZCBvZiBhbGdvcml0aG0gZGVwcmVjYXRpb24gYW5kIEkgaG9w ZSB0byBzb29uIHNlZSB0aGUgZm9sbG93aW5nIHdhcm5pbmcgaW4gbXkgYnJvd3NlcjoNCiAgICAN CiAgICDigJxUTFMgMS4yIGlzIG9ic29sZXRlLiBFbmFibGUgVExTIDEuMyBvciBsYXRlci7igJ0N CiAgICANCiAgICBPdGhlciBpbmR1c3RyaWVzIGhhdmUgbGVzcyBzdGVsbGFyIHRyYWNrIHJlY29y ZHMgb2YgYWxnb3JpdGhtIGRlcHJlY2F0aW9uLg0KICAgIA0KICAgIEhvdyBjYW4gSUVURiBiZSBt b3JlIHByby1hY3RpdmUgcmVnYXJkaW5nIGRlcHJlY2F0aW9ucyBpbiB0aGUgZnV0dXJlPyBJbiB0 aGUgYmVzdCBvZiB3b3Jkcywgbm9ib2R5IHNob3VsZCBiZSBzdXJwcmlzZWQgd2hlbiBJRVRGIGRl cHJlY2F0ZXMgYSBwcm90b2NvbCB2ZXJzaW9uIG9yIGFsZ29yaXRobS4gTklTVCBhbmQgc2ltaWxh ciBvcmdhbml6YXRpb25zIGluIG90aGVyIGNvdW50cmllcyBoYXZlIHRoZSBwcmFjdGljZSB0byBs b25nIHRpbWUgaW4gYWR2YW5jZSBwdWJsaXNoIGRlYWRsaW5lcyBmb3Igc2VjdXJpdHkgbGV2ZWxz LCBhbGdvcml0aG1zLCBhbmQgcHJvdG9jb2wgdmVyc2lvbnMuIENhbiB0aGUgSUVURiBkbyBzb21l dGhpbmcgc2ltaWxhciwgbm90IGp1c3QgZm9yIFRMUyBidXQgaW4gZ2VuZXJhbD8gRm9yIFRMUywg dGhlcmUgYXJlIHNldmVyYWwgdGhpbmdzIHRvIGRlcHJlY2F0ZSwgaW4gYWRkaXRpb24gdG8gTUQ1 IGFuZCBTSEEtMSwgYWxzbyBQS0NTMS12MV81LCBSU0EtMjA0OCwgMjI0LWJpdCBFQ0MsIGZmZGhl MjA0OCwgYW5kIG5vbi1yZWNvbW1lbmRlZCBjaXBoZXIgc3VpdGVzIChTdGF0aWMgUlNBLCBDQkMs IERILCBOVUxMLCBldGMuKSBzaG91bGQgYmUgZGVwcmVjYXRlZCBpbiB0aGUgZnV0dXJlLg0KICAg IA0KICAgIENoZWVycywNCiAgICBKb2huDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBUTFMgbWFpbGluZyBsaXN0DQogICAgVExT QGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMN CiAgICANCg0K From nobody Thu Sep 26 06:50:29 2019 Return-Path: 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 639D6120077; Thu, 26 Sep 2019 06:50:28 -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=ham 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 V8KMJVbtGZOn; Thu, 26 Sep 2019 06:50:26 -0700 (PDT) Received: from mail-qk1-x741.google.com (mail-qk1-x741.google.com [IPv6:2607:f8b0:4864:20::741]) (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 05F851200C3; Thu, 26 Sep 2019 06:50:26 -0700 (PDT) Received: by mail-qk1-x741.google.com with SMTP id q203so1829334qke.1; Thu, 26 Sep 2019 06:50:25 -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=m2cmQfl1ce1CABd/YPT0WDDUSF12xu5WQvKGJMt3xcY=; b=JZ7LqRukQIDu/S2ZkJUsm8rGBjIhgdJamQEfJitStqpU15EqsoZTUxB0irlOAKwcza pHCJ65BPJf2hdq6yoJ27PiJmCnlN3kANtFqO7OsOxDe86sNsIf0/dO3N1QEb9QcC93A5 i3m6++7deiTZ7O5rOCjddJLk5As8JVGnMggR9IDgn7XQn9F/OSBrSC2Y64sxLx960qsU 6MVO52ozIRGSFoiG/I19gDWlWzf3BGNYydu2CphuYyoaz5AKxmu5E9ect0f8JwKzQCiJ q7w197c9ykpR6D/MwRJxVjaJU6VfX0D6Qzcc2VxvJ2pKc5bGwU0NCR1c9lZ/TnRR9Mda 8LaA== 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=m2cmQfl1ce1CABd/YPT0WDDUSF12xu5WQvKGJMt3xcY=; b=IS5oriLX1zpd6ahxKNkh222G9KY9Ht30jGi5UlN1IrSOsruOEnb68RrKT3N46YyfFq T6ZrsSNXDKFhcvhzrdl2H4GJwtDkvwBUCn4dHiq3Nv8+XpSKIz7l1GAe4xrjlTtYa9lM geUYN9XQ1YErzj3NNzypL+oLNPuPs5LQoYI9/CCcy89SJcKzLoq5OF5Hk1rublH19ll0 AKPb5ZC5NivaUIbd+IdY9/p963UiKDiAGsmNTwJ43vzMYI3SxF52p9VW9z8r2WsFYxoS 3Zpxuaqn4+HkZBOI69pTTEqepswGfH53xMt7MCmwx0KGRSCEyWqVhSpwUSB+nDr+Tge0 vjuA== X-Gm-Message-State: APjAAAUy4NXszNv9lqzoSzjVZahPfMghCJSpekiu/0oWERkQxa4agVHR MgJ9hja+H1L9TIMeIGlnX9U= X-Google-Smtp-Source: APXvYqzNcyfpF3K8YO/6d8Eof9VnwT71yovvNHCi3ieAAFOzK+OBOYrB6YuSNtCqMG7OuzcPenh5Jg== X-Received: by 2002:a05:620a:113a:: with SMTP id p26mr3354815qkk.353.1569505825070; Thu, 26 Sep 2019 06:50:25 -0700 (PDT) Received: from ?IPv6:2600:380:5a68:e5ec:3579:ecc6:dfb6:74ef? ([2600:380:5a68:e5ec:3579:ecc6:dfb6:74ef]) by smtp.gmail.com with ESMTPSA id c185sm1023873qkf.122.2019.09.26.06.50.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Sep 2019 06:50:24 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Kathleen Moriarty X-Mailer: iPhone Mail (16G102) In-Reply-To: Date: Thu, 26 Sep 2019 09:50:22 -0400 Cc: John Mattsson , "TLS@ietf.org" , "saag@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> References: To: "Salz, Rich" Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 13:50:28 -0000 Sent from my mobile device > On Sep 26, 2019, at 9:02 AM, Salz, Rich wrote: >=20 > These are excellent points. Perhaps they can be squeezed into https://dat= atracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ ? It's been wa= iting 90 days, a brief reset might not hurt :) >=20 This would not be a brief reset and I=E2=80=99d prefer not to see them combi= ned into the existing draft with WG agreement. With RFC7525, TLSv1.2 can be configured to be secure. I see the points made= , but don=E2=80=99t see the urgency as obsolete is different from depreciati= on. I think encouraging implementation of TLSv1.3 is good and important, but are= there other ways besides deprecation? NIST has pushed back their date for US government organizations to have a pl= an to support TLSv1.3, what=E2=80=99s the driver to get ahead of that? A vulnerability would speed things up, but I do hope that does not happen. Best regards, Kathleen=20 > =EF=BB=BFOn 9/26/19, 8:18 AM, "John Mattsson" wrote: >=20 > Hi, >=20 > Hopefully, we have learned some lessons from the TLS 1.0 and TLS 1.1 de= precation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken in a myri= ad subtle ways and should according to me optimally have been deprecated yea= rs ago. >=20 > 3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at that tim= e not forbid use of TLS 1.1 as that would potentially break interoperability= with some Rel-12 nodes (that had TLS 1.2 as should support). The lesson 3GP= P learned from this was the need to as early as possible mandate support of n= ew protocol versions. With TLS 1.3, 3GPP took action early and TLS 1.3 suppo= rt was mandated for network nodes in Rel-15 (2018) and for mobile phones in R= el-16 (2019). >=20 > At some point in time we will want to deprecate TLS 1.2. To enable that= , TLS 1.3 support should be mandated or encouraged as much as possible. I wo= uld like to avoid a situation where we want to deprecate TLS 1.2 but realize= that it cannot be done because some implementations only support TLS 1.2. H= ow can IETF enable smoother and faster deprecations in the future? The brows= er industry has a decent track record of algorithm deprecation and I hope to= soon see the following warning in my browser: >=20 > =E2=80=9CTLS 1.2 is obsolete. Enable TLS 1.3 or later.=E2=80=9D >=20 > Other industries have less stellar track records of algorithm deprecati= on. >=20 > How can IETF be more pro-active regarding deprecations in the future? I= n the best of words, nobody should be surprised when IETF deprecates a proto= col version or algorithm. NIST and similar organizations in other countries h= ave the practice to long time in advance publish deadlines for security leve= ls, algorithms, and protocol versions. Can the IETF do something similar, no= t just for TLS but in general? For TLS, there are several things to deprecat= e, in addition to MD5 and SHA-1, also PKCS1-v1_5, RSA-2048, 224-bit ECC, ffd= he2048, and non-recommended cipher suites (Static RSA, CBC, DH, NULL, etc.) s= hould be deprecated in the future. >=20 > Cheers, > John >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Sep 26 06:50:59 2019 Return-Path: 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 285F91208A9; Thu, 26 Sep 2019 06:50:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 Qy5658eFVvLW; Thu, 26 Sep 2019 06:50:41 -0700 (PDT) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A680812018B; Thu, 26 Sep 2019 06:50:41 -0700 (PDT) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 1D74238986; Thu, 26 Sep 2019 09:48:47 -0400 (EDT) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 665C11582; Thu, 26 Sep 2019 09:50:40 -0400 (EDT) From: Michael Richardson To: John Mattsson cc: "TLS\@ietf.org" , "saag\@ietf.org" In-Reply-To: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [saag] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 13:50:50 -0000 --=-=-= Content-Type: text/plain First, I think that we must recognize that the *IETF* does not have the same sectoral powers that 3GPP has. It is entirely appropriate what 3GPP did, and they seem to have learned the lessons they needed. John Mattsson wrote: > How can IETF be more pro-active regarding deprecations in the future? > In the best of words, nobody should be surprised when IETF deprecates a > protocol version or algorithm. NIST and similar organizations in other > countries have the practice to long time in advance publish deadlines > for security levels, algorithms, and protocol versions. Can the IETF do > something similar, not just for TLS but in general? For TLS, there are > several things to deprecate, in addition to MD5 and SHA-1, also > PKCS1-v1_5, RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended > cipher suites (Static RSA, CBC, DH, NULL, etc.) should be deprecated in > the future. I think that we can more easily deprecate these individual ciphers and cipher suites than we can entire TLS version numbers. The mere fact that we had to "hide" the TLS 1.3 version in the header the way that did speaks volumes to the problems in what I'll call the "secondary" security industry. There are significant incentives from enterprises to have companies come to "patch up" their broken systems. If we want enteprises to move faster, and move with us, then we will have to spend more time addressing the issues that they have. We may not like their problems, we may even strongly disagree, but we have to keep them in the tent. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [ --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl2MwjAACgkQgItw+93Q 3WXtOwf+JCO5rJKbcj4dC4Bv/fQEZ75B6/kzLhi0xJ53pcaVm7rM4zUzo69B3CST xOFI+sHGX5SJRYHmlDJBfp54YsdCnjrQQvV4qIg31GNZpGqa9H9TSuy2QiipIUbF grR9+hcETeO6puZSPPCc1t04C66tMvGBeuhaKT8HXVzYQ9ppbHqdiYJOozgX4CcX iDVnfeOIsXHkpeW0qvIQWfLL8OrUKskIo10Tpx8G1CrKK5yJV6L/XeyukE4RA98B i9AbwlPR+mTv/HJpvM5w+0GeJscxaj+OZUPAvTdeUI7umd/XSgXu5CYAWuYwBJyT 9DTJWlV4HwrZZII8HQVF6zc8AOIqkg== =oqyQ -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 26 06:51:30 2019 Return-Path: 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 476E41208B3; Thu, 26 Sep 2019 06:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.895 X-Spam-Level: X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=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 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 n7gZf3JQGG69; Thu, 26 Sep 2019 06:51:09 -0700 (PDT) Received: from mail-ua1-f47.google.com (mail-ua1-f47.google.com [209.85.222.47]) (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 A73E1120839; Thu, 26 Sep 2019 06:51:09 -0700 (PDT) Received: by mail-ua1-f47.google.com with SMTP id n2so778488ual.11; Thu, 26 Sep 2019 06:51:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=L673KrqYV3m85ireH46XDqxBxJGIHlq1NScojDcAKTE=; b=Z14uDSEflqVdo7oigeqDn035H3xr+VG4GdJO1Xt6CeK76UvlozBIb97JJoU7141fRu 9iTQ1VoVn/DUnmwFC3MgGPu+2Woao/9mrFWh8ivnTnEy7hHevuiC9NJiJvwYGfdSiqDT Cywi0ETKozCDbGs67rCze8hbppAyMSPC12rllgvg17AEKE+2hbIr38sf54/HbjYNjUhD IcxBQUi0lM6Z+I2Ro8QOzHnWU0mE2PnTgvuHKR6ByOQbA2ZIEBtya2jaohFlHU3RkGx+ DksX7rlvaIJo9N34bgOUh46PsCrYyv99FvJ2b9Xatd8zi/B73ky+EwBhhDnEbwToC3jO 5wVA== X-Gm-Message-State: APjAAAWd41beGOvrKa05vjnjr/v0A1MoWylvHMsSMlgFwmcqLquADk9y DLJe6Sf0Ka9AciqafMGcP3ah0sXPMImXnFtgoXFISg== X-Google-Smtp-Source: APXvYqwyH/0e1PkHgReWGdlZS8TlpiTjUemlpXH0RWBUamJwgYjAAe3SnSrhXLUW/K3pV5EE4Zt/ImFT2VQlYBflClg= X-Received: by 2002:ab0:6897:: with SMTP id t23mr1737156uar.88.1569505868644; Thu, 26 Sep 2019 06:51:08 -0700 (PDT) MIME-Version: 1.0 References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> In-Reply-To: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> From: Daniel Migault Date: Thu, 26 Sep 2019 09:50:57 -0400 Message-ID: To: John Mattsson Cc: "TLS@ietf.org" , "saag@ietf.org" Content-Type: multipart/alternative; boundary="000000000000c604e80593750ff1" Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 13:51:22 -0000 --000000000000c604e80593750ff1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for raising this discussion John, we have been struggling with this in curdle as well and ipsecme. This is also a topic that I believe would be useful to improve the security. One aspect is that some implementers go to the IANA pages and believe that everything on the pages is acceptable. I believe that it would be worth adding some status associated to the code points. Currently, in most cases a reference is associated to the code point. In some cases, the reference is the RFC or document creating that created the code point in other cases, the reference could be the RFC that deprecates the code point. There is no specific rules, and that is probably something that would worth being clarified. That being clarified, I still believe that it could be useful to have a some sort of indication like a column that indicates whether the code point is deprecated or not. This may involve additional terminology depending on the level of information needed. Another aspect would be to have software automatically checking which are the code points status. This would of course only solve one side of the problem as a device may end up on becoming silent, but that is probably what should occur to non maintained devices. Yours, Daniel On Thu, Sep 26, 2019 at 8:18 AM John Mattsson wrote: > Hi, > > Hopefully, we have learned some lessons from the TLS 1.0 and TLS 1.1 > deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken in a > myriad subtle ways and should according to me optimally have been > deprecated years ago. > > 3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at that time > not forbid use of TLS 1.1 as that would potentially break interoperabilit= y > with some Rel-12 nodes (that had TLS 1.2 as should support). The lesson > 3GPP learned from this was the need to as early as possible mandate suppo= rt > of new protocol versions. With TLS 1.3, 3GPP took action early and TLS 1.= 3 > support was mandated for network nodes in Rel-15 (2018) and for mobile > phones in Rel-16 (2019). > > At some point in time we will want to deprecate TLS 1.2. To enable that, > TLS 1.3 support should be mandated or encouraged as much as possible. I > would like to avoid a situation where we want to deprecate TLS 1.2 but > realize that it cannot be done because some implementations only support > TLS 1.2. How can IETF enable smoother and faster deprecations in the > future? The browser industry has a decent track record of algorithm > deprecation and I hope to soon see the following warning in my browser: > > =E2=80=9CTLS 1.2 is obsolete. Enable TLS 1.3 or later.=E2=80=9D > > Other industries have less stellar track records of algorithm deprecation= . > > How can IETF be more pro-active regarding deprecations in the future? In > the best of words, nobody should be surprised when IETF deprecates a > protocol version or algorithm. NIST and similar organizations in other > countries have the practice to long time in advance publish deadlines for > security levels, algorithms, and protocol versions. Can the IETF do > something similar, not just for TLS but in general? For TLS, there are > several things to deprecate, in addition to MD5 and SHA-1, also PKCS1-v1_= 5, > RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher suites (Stat= ic > RSA, CBC, DH, NULL, etc.) should be deprecated in the future. > > Cheers, > John > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --000000000000c604e80593750ff1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for raising this discussion John, we have been stru= ggling with this in curdle as well and ipsecme. This is also a topic that I= believe would be useful=C2=A0to improve the security.

O= ne aspect is that some implementers go to the IANA pages and believe that e= verything on the pages is acceptable. I believe that it would=C2=A0be worth= adding some status associated to the code points. Currently, in most cases= a reference is associated to the code point. In some cases, the reference = is the RFC or document creating that created the code point in other cases,= the reference could be the RFC that deprecates the code point. There is no= specific rules, and that is probably something that would worth being clar= ified. That being clarified, I still believe=C2=A0that it could=C2=A0be use= ful=C2=A0to have a some sort of indication like a column that indicates whe= ther the code point is deprecated or not. This may involve additional termi= nology depending on the level of information=C2=A0needed.=C2=A0
<= br>
Another aspect would be to have software automatically checki= ng which are the code points status. This would of course only solve one si= de of the problem as a device may end up on becoming silent, but that is pr= obably what should occur to non maintained devices.=C2=A0

Yours,=C2=A0
Daniel

=C2=A0=C2=A0
<= /div>
O= n Thu, Sep 26, 2019 at 8:18 AM John Mattsson <john.mattsson=3D40ericsson.com@dmarc.ietf.org>= ; wrote:
Hi,

Hopefully, we have learned some lessons from the TLS 1.0 and TLS 1.1 deprec= ation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken in a myriad = subtle ways and should according to me optimally have been deprecated years= ago.

3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at that time no= t forbid use of TLS 1.1 as that would potentially break interoperability wi= th some Rel-12 nodes (that had TLS 1.2 as should support). The lesson 3GPP = learned from this was the need to as early as possible mandate support of n= ew protocol versions. With TLS 1.3, 3GPP took action early and TLS 1.3 supp= ort was mandated for network nodes in Rel-15 (2018) and for mobile phones i= n Rel-16 (2019).

At some point in time we will want to deprecate TLS 1.2. To enable that, TL= S 1.3 support should be mandated or encouraged as much as possible. I would= like to avoid a situation where we want to deprecate TLS 1.2 but realize t= hat it cannot be done because some implementations only support TLS 1.2. Ho= w can IETF enable smoother and faster deprecations in the future? The brows= er industry has a decent track record of algorithm deprecation and I hope t= o soon see the following warning in my browser:

=E2=80=9CTLS 1.2 is obsolete. Enable TLS 1.3 or later.=E2=80=9D

Other industries have less stellar track records of algorithm deprecation.<= br>
How can IETF be more pro-active regarding deprecations in the future? In th= e best of words, nobody should be surprised when IETF deprecates a protocol= version or algorithm. NIST and similar organizations in other countries ha= ve the practice to long time in advance publish deadlines for security leve= ls, algorithms, and protocol versions. Can the IETF do something similar, n= ot just for TLS but in general? For TLS, there are several things to deprec= ate, in addition to MD5 and SHA-1, also PKCS1-v1_5, RSA-2048, 224-bit ECC, = ffdhe2048, and non-recommended cipher suites (Static RSA, CBC, DH, NULL, et= c.) should be deprecated in the future.

Cheers,
John

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--000000000000c604e80593750ff1-- From nobody Thu Sep 26 08:00:25 2019 Return-Path: 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 3669A120255; Thu, 26 Sep 2019 08:00:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.026, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 FP5J86_VbdvE; Thu, 26 Sep 2019 08:00:20 -0700 (PDT) Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) (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 7149D120938; Thu, 26 Sep 2019 08:00:20 -0700 (PDT) Received: by mail-vs1-f43.google.com with SMTP id p13so1826070vsr.4; Thu, 26 Sep 2019 08:00:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Jv7jP95Gd9nfFjJI4yQpf02CWn7UV4u+6Q6v5SZvQIE=; b=GAWYqymB783+WI8NVjbH8jmhWpRw2LaGImt3PVvrgkmEJPsTVdsfXRbQtkL3MWUaMb 3UdtMqVbciqldUexUCMM4I7OWyEFEvhx3XmYHhnv1DKjk1HF7JZ6lHG1Jpc4nZ2WFMrq 9zOCs2NK5OgmC3ExV0ddhUOpPYVOpBocaU25bUJqL7vbQ82zD99rQiZlerbrRSrSQobu HG/pdCpkaNYOcHBeY3BeW0hQGBQb/DDQUSa3VkAvbq70ZKiECOiybze1RfQtoAAxb3Gb m0jpW+jLYOw3Y1rc78aGsbeOW0NzXRiUA0Ugn4XynxcGiJ1WNnwmXNiAVjUuEeyWBAFG Cy3Q== X-Gm-Message-State: APjAAAVRw6x/OP8WRk2bHd/1/8wk+vCPj7dSg26aY2yzZq+PfIpDFJaM itIf0cCqYrAr5eTd/0IarioGobsU3rA0DelpDNg= X-Google-Smtp-Source: APXvYqy+xjG6Y3W29WO6o9chlozi5pUsK9GgCAjs/VDtJYRYDbw7akHmDca0ws1pG3TADTgfvfjKaUksR+9iN8oC75w= X-Received: by 2002:a05:6102:15a:: with SMTP id a26mr1915012vsr.97.1569510019421; Thu, 26 Sep 2019 08:00:19 -0700 (PDT) MIME-Version: 1.0 References: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> In-Reply-To: <8B2B78CF-F312-4F7A-8EB1-A712F309A754@gmail.com> From: Daniel Migault Date: Thu, 26 Sep 2019 11:00:07 -0400 Message-ID: To: Kathleen Moriarty Cc: "Salz, Rich" , John Mattsson , "TLS@ietf.org" , "saag@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002ddd9005937607c8" Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 15:00:24 -0000 --0000000000002ddd9005937607c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, My understanding of deprecating of TLS1.0 TLS 1.1 is that: a) new software do not use these versions b) existing software stop supporting these versions. I am not sure how likely a new software is to use TLS 1.0 or TLS 1.1 with TLS 1.2 and TLS 1.3 being widely deployed. It seems also a current best practise to take the latest version, and I am also not sure implementers considering TLS 1.0 or TLS 1.1 would read this document. That said, it might be good the current text provide a stronger recommendation to consider the latest version of TLS which is 1.3. For existing software, the reason to maintain these old versions is, as far as I understand, usually that the other side is composed of a legacy software. The deprecation on the server side, expects legacy devices to become enable to serve their purpose and that hopefully someone will unplug them. I believe that the document could emphasise a bit more and recommend to move to include TLS 1.3. In addition, I am not sure how relevant it is, but if a software is not yet supporting TLS 1.2 - that is supporting TLS 1.0 and TLS 1.1 - I believe that we should explicitly recommend it to move to TLS 1.3. """The expectation is that TLSv1.2 will continue to be used for many years alongside TLSv1.3.""" """Deprecation of these versions is intended to assist developers as additional justification to no longer support older TLS versions and to migrate to a minimum of TLSv1.2. Deprecation also assists product teams with phasing out support for the older versions to reduce the attack surface and the scope of maintenance for protocols in their offerings. """ The text above may be interpreted that TLS 1.2 is fine for a long time and there is not need to upgrade to TLS 1.3. It may be helpful to clarify that version compatibility should also consider TLS 1.3. I woudl suggest something around the lines: Even TLS 1.2 and TLS 1.3 are expected to co-exist for years, with the deployment of TLS 1.3, it is RECOMMENDED to envisioned the phase out of TLS 1.2 and start deploying TLS 1.3. In addition, software that do not support TLS 1.2 are RECOMMENDED to implement only TLS 1.3. Another way around may be to add a section: "Use TLSv1.3". Yours, Daniel On Thu, Sep 26, 2019 at 9:50 AM Kathleen Moriarty < kathleen.moriarty.ietf@gmail.com> wrote: > > > Sent from my mobile device > > > On Sep 26, 2019, at 9:02 AM, Salz, Rich wrote: > > > > These are excellent points. Perhaps they can be squeezed into > https://datatracker.ietf.org/doc/draft-ietf-tls-oldversions-deprecate/ > ? It's been waiting 90 days, a brief reset might not hurt :) > > > This would not be a brief reset and I=E2=80=99d prefer not to see them co= mbined > into the existing draft with WG agreement. > > With RFC7525, TLSv1.2 can be configured to be secure. I see the points > made, but don=E2=80=99t see the urgency as obsolete is different from dep= reciation. > > I think encouraging implementation of TLSv1.3 is good and important, but > are there other ways besides deprecation? > > NIST has pushed back their date for US government organizations to have a > plan to support TLSv1.3, what=E2=80=99s the driver to get ahead of that? > > A vulnerability would speed things up, but I do hope that does not happen= . > > Best regards, > Kathleen > > > =EF=BB=BFOn 9/26/19, 8:18 AM, "John Mattsson" 40ericsson.com@dmarc.ietf.org> wrote: > > > > Hi, > > > > Hopefully, we have learned some lessons from the TLS 1.0 and TLS 1.1 > deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken in a > myriad subtle ways and should according to me optimally have been > deprecated years ago. > > > > 3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at that > time not forbid use of TLS 1.1 as that would potentially break > interoperability with some Rel-12 nodes (that had TLS 1.2 as should > support). The lesson 3GPP learned from this was the need to as early as > possible mandate support of new protocol versions. With TLS 1.3, 3GPP too= k > action early and TLS 1.3 support was mandated for network nodes in Rel-15 > (2018) and for mobile phones in Rel-16 (2019). > > > > At some point in time we will want to deprecate TLS 1.2. To enable > that, TLS 1.3 support should be mandated or encouraged as much as possibl= e. > I would like to avoid a situation where we want to deprecate TLS 1.2 but > realize that it cannot be done because some implementations only support > TLS 1.2. How can IETF enable smoother and faster deprecations in the > future? The browser industry has a decent track record of algorithm > deprecation and I hope to soon see the following warning in my browser: > > > > =E2=80=9CTLS 1.2 is obsolete. Enable TLS 1.3 or later.=E2=80=9D > > > > Other industries have less stellar track records of algorithm > deprecation. > > > > How can IETF be more pro-active regarding deprecations in the future= ? > In the best of words, nobody should be surprised when IETF deprecates a > protocol version or algorithm. NIST and similar organizations in other > countries have the practice to long time in advance publish deadlines for > security levels, algorithms, and protocol versions. Can the IETF do > something similar, not just for TLS but in general? For TLS, there are > several things to deprecate, in addition to MD5 and SHA-1, also PKCS1-v1_= 5, > RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher suites (Stat= ic > RSA, CBC, DH, NULL, etc.) should be deprecated in the future. > > > > Cheers, > > John > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > _______________________________________________ > saag mailing list > saag@ietf.org > https://www.ietf.org/mailman/listinfo/saag > --0000000000002ddd9005937607c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

My und= erstanding of deprecating of TLS1.0 TLS 1.1 is that:=C2=A0
a) new softwa= re do not use these versions
b) existing software stop supporting these= versions.=C2=A0

I am not sure how likely a new software is to use T= LS 1.0 or TLS 1.1 with TLS 1.2 and TLS 1.3 being widely deployed. It seems = also a current best practise to take the latest version, and I am also not = sure implementers considering TLS 1.0 or TLS 1.1 would read this document. = That said,=C2=A0it might be good the current text provide a stronger recomm= endation to consider the latest version of TLS which is 1.3.=C2=A0

F= or existing software, the reason to maintain these old versions=C2=A0is, as= far as I understand, usually that the other side is composed of a legacy s= oftware. The deprecation on the server side, expects legacy devices to beco= me enable to serve their purpose and that hopefully someone will unplug the= m. I believe=C2=A0that the document could=C2=A0emphasise a bit more and rec= ommend to move to include TLS 1.3. In addition, I am not sure how relevant = it is, but if a =C2=A0software is not yet supporting TLS 1.2 - that is supp= orting TLS 1.0 and TLS 1.1 - I believe that we should explicitly recommend = it to move to TLS 1.3. =C2=A0

""&qu= ot;The expectation is that TLSv1.2 will continue to be used for many years = alongside TLSv1.3."""


"""Deprecati= on of these versions is intended to assist developers as
=C2=A0 =C2=A0ad= ditional justification to no longer support older TLS versions and
=C2= =A0 =C2=A0to migrate to a minimum of TLSv1.2.=C2=A0 Deprecation also assist= s product
=C2=A0 =C2=A0teams with phasing out support for the older vers= ions to reduce the
=C2=A0 =C2=A0attack surface and the scope of maintena= nce for protocols in their
=C2=A0 =C2=A0offerings.
"""=

The text above may be interpreted that TLS 1.2 is fine for a long t= ime and there is not need to upgrade to TLS 1.3. It may be helpful to clari= fy that version compatibility should also consider TLS 1.3. I woudl suggest= something around the lines:=C2=A0

Even TLS 1.2 and TLS 1.3 are expe= cted to co-exist for years, with the deployment of TLS 1.3, it is RECOMMEND= ED to envisioned the phase out of TLS 1.2 and start deploying TLS 1.3. In a= ddition, software that do not support TLS 1.2 are RECOMMENDED to implement = only TLS 1.3.

Another way around may be to add a section: "Use= TLSv1.3".=C2=A0

Yours,=20
Daniel

On Thu, Sep 26, 2019 at 9:50 AM Kathleen Moriarty <kathleen.moriarty.ietf@gma= il.com> wrote:


Sent from my mobile device

> On Sep 26, 2019, at 9:02 AM, Salz, Rich <rsalz@akamai.com> wrote:
>
> These are excellent points.=C2=A0 Perhaps they can be squeezed into https://datatracker.ietf.org/doc= /draft-ietf-tls-oldversions-deprecate/=C2=A0 ?=C2=A0 It's been wait= ing 90 days, a brief reset might not hurt :)
>
This would not be a brief reset and I=E2=80=99d prefer not to see them comb= ined into the existing draft with WG agreement.

With RFC7525, TLSv1.2 can be configured to be secure.=C2=A0 I see the point= s made, but don=E2=80=99t see the urgency as obsolete is different from dep= reciation.

I think encouraging implementation of TLSv1.3 is good and important, but ar= e there other ways besides deprecation?

NIST has pushed back their date for US government organizations to have a p= lan to support TLSv1.3, what=E2=80=99s the driver to get ahead of that?

A vulnerability would speed things up, but I do hope that does not happen.<= br>
Best regards,
Kathleen

> =EF=BB=BFOn 9/26/19, 8:18 AM, "John Mattsson" <john.matts= son=3D40= ericsson.com@dmarc.ietf.org> wrote:
>
>=C2=A0 =C2=A0 Hi,
>
>=C2=A0 =C2=A0 Hopefully, we have learned some lessons from the TLS 1.0 = and TLS 1.1 deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) b= roken in a myriad subtle ways and should according to me optimally have bee= n deprecated years ago.
>
>=C2=A0 =C2=A0 3GPP mandated support of TLS 1.2 in Rel-13 (2015) but cou= ld at that time not forbid use of TLS 1.1 as that would potentially break i= nteroperability with some Rel-12 nodes (that had TLS 1.2 as should support)= . The lesson 3GPP learned from this was the need to as early as possible ma= ndate support of new protocol versions. With TLS 1.3, 3GPP took action earl= y and TLS 1.3 support was mandated for network nodes in Rel-15 (2018) and f= or mobile phones in Rel-16 (2019).
>
>=C2=A0 =C2=A0 At some point in time we will want to deprecate TLS 1.2. = To enable that, TLS 1.3 support should be mandated or encouraged as much as= possible. I would like to avoid a situation where we want to deprecate TLS= 1.2 but realize that it cannot be done because some implementations only s= upport TLS 1.2. How can IETF enable smoother and faster deprecations in the= future? The browser industry has a decent track record of algorithm deprec= ation and I hope to soon see the following warning in my browser:
>
>=C2=A0 =C2=A0 =E2=80=9CTLS 1.2 is obsolete. Enable TLS 1.3 or later.=E2= =80=9D
>
>=C2=A0 =C2=A0 Other industries have less stellar track records of algor= ithm deprecation.
>
>=C2=A0 =C2=A0 How can IETF be more pro-active regarding deprecations in= the future? In the best of words, nobody should be surprised when IETF dep= recates a protocol version or algorithm. NIST and similar organizations in = other countries have the practice to long time in advance publish deadlines= for security levels, algorithms, and protocol versions. Can the IETF do so= mething similar, not just for TLS but in general? For TLS, there are severa= l things to deprecate, in addition to MD5 and SHA-1, also PKCS1-v1_5, RSA-2= 048, 224-bit ECC, ffdhe2048, and non-recommended cipher suites (Static RSA,= CBC, DH, NULL, etc.) should be deprecated in the future.
>
>=C2=A0 =C2=A0 Cheers,
>=C2=A0 =C2=A0 John
>
>=C2=A0 =C2=A0 _______________________________________________
>=C2=A0 =C2=A0 TLS mailing list
>=C2=A0 =C2=A0 TLS@iet= f.org
>=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/tls=
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
saag mailing list
saag@ietf.org
https://www.ietf.org/mailman/listinfo/saag
--0000000000002ddd9005937607c8-- From nobody Fri Sep 27 08:57:07 2019 Return-Path: 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 9D070120943 for ; Fri, 27 Sep 2019 08:57:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 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 A1YKNb4czXP1 for ; Fri, 27 Sep 2019 08:56:55 -0700 (PDT) Received: from 7.mo5.mail-out.ovh.net (7.mo5.mail-out.ovh.net [178.32.124.100]) (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 9E7E3120935 for ; Fri, 27 Sep 2019 08:56:55 -0700 (PDT) Received: from player746.ha.ovh.net (unknown [10.108.42.145]) by mo5.mail-out.ovh.net (Postfix) with ESMTP id C5671250542 for ; Fri, 27 Sep 2019 17:56:53 +0200 (CEST) Received: from simonbernard.eu (134.163-14-84.ripe.coltfrance.com [84.14.163.134]) (Authenticated sender: contact@simonbernard.eu) by player746.ha.ovh.net (Postfix) with ESMTPSA id C95B5A69C6C5; Fri, 27 Sep 2019 15:56:49 +0000 (UTC) To: Daniel Migault , John Mattsson Cc: "TLS@ietf.org" , "saag@ietf.org" References: <03B5BDAC-5B17-47B2-85D0-225DCCABDC42@ericsson.com> From: Simon Bernard Message-ID: Date: Fri, 27 Sep 2019 17:56:47 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BFCCFBF68655DCF6985B967F" Content-Language: en-US X-Ovh-Tracer-Id: 3550243884170557530 X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: 0 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedufedrfeeigdelfecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemucehtddtnecu Archived-At: Subject: Re: [saag] [TLS] Lessons learned from TLS 1.0 and TLS 1.1 deprecation X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 15:57:01 -0000 This is a multi-part message in MIME format. --------------BFCCFBF68655DCF6985B967F Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi,   My 2 cents, I think a kind of overview page with status about protocols, ciphers an others would helps a lot. Something near of what is done in https://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher   This would be the page to know to be updated about security deprecation and planned obsolescence.   If API was available to query this data, it could maybe be used by tools like : https://www.ssllabs.com/index.html Regards, Simon Le 26/09/2019 à 15:50, Daniel Migault a écrit : > Thanks for raising this discussion John, we have been struggling with > this in curdle as well and ipsecme. This is also a topic that I > believe would be useful to improve the security. > > One aspect is that some implementers go to the IANA pages and believe > that everything on the pages is acceptable. I believe that it would be > worth adding some status associated to the code points. Currently, in > most cases a reference is associated to the code point. In some cases, > the reference is the RFC or document creating that created the code > point in other cases, the reference could be the RFC that deprecates > the code point. There is no specific rules, and that is probably > something that would worth being clarified. That being clarified, I > still believe that it could be useful to have a some sort of > indication like a column that indicates whether the code point is > deprecated or not. This may involve additional terminology depending > on the level of information needed. > > Another aspect would be to have software automatically checking which > are the code points status. This would of course only solve one side > of the problem as a device may end up on becoming silent, but that is > probably what should occur to non maintained devices. > > Yours, > Daniel > > > On Thu, Sep 26, 2019 at 8:18 AM John Mattsson > > wrote: > > Hi, > > Hopefully, we have learned some lessons from the TLS 1.0 and TLS > 1.1 deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) > broken in a myriad subtle ways and should according to me > optimally have been deprecated years ago. > > 3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at > that time not forbid use of TLS 1.1 as that would potentially > break interoperability with some Rel-12 nodes (that had TLS 1.2 as > should support). The lesson 3GPP learned from this was the need to > as early as possible mandate support of new protocol versions. > With TLS 1.3, 3GPP took action early and TLS 1.3 support was > mandated for network nodes in Rel-15 (2018) and for mobile phones > in Rel-16 (2019). > > At some point in time we will want to deprecate TLS 1.2. To enable > that, TLS 1.3 support should be mandated or encouraged as much as > possible. I would like to avoid a situation where we want to > deprecate TLS 1.2 but realize that it cannot be done because some > implementations only support TLS 1.2. How can IETF enable smoother > and faster deprecations in the future? The browser industry has a > decent track record of algorithm deprecation and I hope to soon > see the following warning in my browser: > > “TLS 1.2 is obsolete. Enable TLS 1.3 or later.” > > Other industries have less stellar track records of algorithm > deprecation. > > How can IETF be more pro-active regarding deprecations in the > future? In the best of words, nobody should be surprised when IETF > deprecates a protocol version or algorithm. NIST and similar > organizations in other countries have the practice to long time in > advance publish deadlines for security levels, algorithms, and > protocol versions. Can the IETF do something similar, not just for > TLS but in general? For TLS, there are several things to > deprecate, in addition to MD5 and SHA-1, also PKCS1-v1_5, > RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher > suites (Static RSA, CBC, DH, NULL, etc.) should be deprecated in > the future. > > Cheers, > John > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------BFCCFBF68655DCF6985B967F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

  My 2 cents, I think a kind of overview page with status about protocols, ciphers an others would helps a lot. Something near of what is done in https://en.wikipedia.org/wiki/Transport_Layer_Security#Cipher
  This would be the page to know to be updated about security deprecation and planned obsolescence.
  If API was available to query this data, it could maybe be used by tools like : https://www.ssllabs.com/index.html

Regards,
Simon

Le 26/09/2019 à 15:50, Daniel Migault a écrit :
Thanks for raising this discussion John, we have been struggling with this in curdle as well and ipsecme. This is also a topic that I believe would be useful to improve the security.

One aspect is that some implementers go to the IANA pages and believe that everything on the pages is acceptable. I believe that it would be worth adding some status associated to the code points. Currently, in most cases a reference is associated to the code point. In some cases, the reference is the RFC or document creating that created the code point in other cases, the reference could be the RFC that deprecates the code point. There is no specific rules, and that is probably something that would worth being clarified. That being clarified, I still believe that it could be useful to have a some sort of indication like a column that indicates whether the code point is deprecated or not. This may involve additional terminology depending on the level of information needed. 

Another aspect would be to have software automatically checking which are the code points status. This would of course only solve one side of the problem as a device may end up on becoming silent, but that is probably what should occur to non maintained devices. 

Yours, 
Daniel

  

On Thu, Sep 26, 2019 at 8:18 AM John Mattsson <john.mattsson=40ericsson.com@dmarc.ietf.org> wrote:
Hi,

Hopefully, we have learned some lessons from the TLS 1.0 and TLS 1.1 deprecation. TLS 1.0 and TLS 1.1 are (to cite Martin Thomson) broken in a myriad subtle ways and should according to me optimally have been deprecated years ago.

3GPP mandated support of TLS 1.2 in Rel-13 (2015) but could at that time not forbid use of TLS 1.1 as that would potentially break interoperability with some Rel-12 nodes (that had TLS 1.2 as should support). The lesson 3GPP learned from this was the need to as early as possible mandate support of new protocol versions. With TLS 1.3, 3GPP took action early and TLS 1.3 support was mandated for network nodes in Rel-15 (2018) and for mobile phones in Rel-16 (2019).

At some point in time we will want to deprecate TLS 1.2. To enable that, TLS 1.3 support should be mandated or encouraged as much as possible. I would like to avoid a situation where we want to deprecate TLS 1.2 but realize that it cannot be done because some implementations only support TLS 1.2. How can IETF enable smoother and faster deprecations in the future? The browser industry has a decent track record of algorithm deprecation and I hope to soon see the following warning in my browser:

“TLS 1.2 is obsolete. Enable TLS 1.3 or later.”

Other industries have less stellar track records of algorithm deprecation.

How can IETF be more pro-active regarding deprecations in the future? In the best of words, nobody should be surprised when IETF deprecates a protocol version or algorithm. NIST and similar organizations in other countries have the practice to long time in advance publish deadlines for security levels, algorithms, and protocol versions. Can the IETF do something similar, not just for TLS but in general? For TLS, there are several things to deprecate, in addition to MD5 and SHA-1, also PKCS1-v1_5, RSA-2048, 224-bit ECC, ffdhe2048, and non-recommended cipher suites (Static RSA, CBC, DH, NULL, etc.) should be deprecated in the future.

Cheers,
John

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--------------BFCCFBF68655DCF6985B967F-- From nobody Fri Sep 27 11:23:21 2019 Return-Path: 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 D248812091D for ; Fri, 27 Sep 2019 11:23: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=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dell.com header.b=Qpu2hnaW; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=fny4R5gf 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 3ioF1op9Yasq for ; Fri, 27 Sep 2019 11:23:16 -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 3EBC312090D for ; Fri, 27 Sep 2019 11:23:16 -0700 (PDT) Received: from pps.filterd (m0170398.ppops.net [127.0.0.1]) by mx0b-00154904.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8RHxwfh013570; Fri, 27 Sep 2019 14:23:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dell.com; h=from : to : subject : date : message-id : content-type : content-transfer-encoding : mime-version; s=smtpout1; bh=YxB2wPZkWjbza5bj8s4oVK/LdsYu93uBnPVxCxdrkLE=; b=Qpu2hnaWFgxJWUuaXBO0BijpxTN168Eqn1aWPGwthWqGeQszNEZ5K29lW1+O3f0IVO9d 1FIsAMGRlshxbef0k/H45ehaRILitSKC3l7v7cgB/3cbTuf2YGS579yztoz6A1MinN9A 5hGXw/f7DYhwAu4FgUlKVZwO3kjQGa2aPNxWjOTe/uG9RZ7/MknesMwpIPLR2+jR6vMn Tgf0mLbJBjo5y+xpopJnHj/fCwDGwlrkwNwWG2WkAWy3btydEuVHuc0jRmrVhouB5ZTa K52wnvrJRtiKbkN61vLCgbmDoX1/ZjVDr58SAClDPvzGQWVCFvg1DTx5tx8GGilkVy7d Qw== Received: from mx0a-00154901.pphosted.com (mx0b-00154901.pphosted.com [67.231.157.37]) by mx0b-00154904.pphosted.com with ESMTP id 2v5f3b054x-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Sep 2019 14:23:15 -0400 Received: from pps.filterd (m0089484.ppops.net [127.0.0.1]) by mx0b-00154901.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id x8RI3raQ053547; Fri, 27 Sep 2019 14:23:14 -0400 Received: from mailuogwhop.emc.com (mailuogwhop-nat.lss.emc.com [168.159.213.141] (may be forged)) by mx0b-00154901.pphosted.com with ESMTP id 2v989w9qrp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 27 Sep 2019 14:23:14 -0400 Received: from maildlpprd06.lss.emc.com (maildlpprd06.lss.emc.com [10.253.24.38]) by mailuogwprd01.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8RINCdj008428 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 27 Sep 2019 14:23:13 -0400 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd01.lss.emc.com x8RINCdj008428 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1569608594; bh=4732iXrQNLT3lIozZFIqvoin1bY=; h=From:To:Subject:Date:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=fny4R5gfmDczT23ZcClsetu1So15y8kPwflWiFN+ST6zwLPbJPYflU4SPqOjoPtW9 qfq9TjB27VWOuAHZ4hyNQev9JlKBn4B/3aNQqJdtD9DI7wb+i7kl2ATCo65FgakKOZ 9CZN12IWEGqSfz2kdpVNr6A6iP28+oGWfN0g+0qU= Received: from mailusrhubprd02.lss.emc.com (mailusrhubprd02.lss.emc.com [10.253.24.20]) by maildlpprd06.lss.emc.com (RSA Interceptor); Fri, 27 Sep 2019 14:22:52 -0400 Received: from MXHUB312.corp.emc.com (MXHUB312.corp.emc.com [10.146.3.90]) by mailusrhubprd02.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id x8RIMqZ8026321 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Fri, 27 Sep 2019 14:22:53 -0400 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB312.corp.emc.com ([10.146.3.90]) with mapi id 14.03.0439.000; Fri, 27 Sep 2019 14:22:52 -0400 From: "Black, David" To: Maurizio Lombardi , "saag@ietf.org" Thread-Topic: Improving the CHAP protocol - conclusion Thread-Index: AdV1YI7WvMgpiyJvSUaFhAD5cVGTUg== Date: Fri, 27 Sep 2019 18:22:52 +0000 Message-ID: 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-27T18:22:19.7795331Z; 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd02.lss.emc.com X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.95,1.0.8 definitions=2019-09-27_08:2019-09-25,2019-09-27 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 priorityscore=1501 mlxlogscore=999 mlxscore=0 lowpriorityscore=0 malwarescore=0 spamscore=0 bulkscore=0 impostorscore=0 adultscore=0 phishscore=0 clxscore=1015 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909270150 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 lowpriorityscore=0 adultscore=0 priorityscore=1501 impostorscore=0 spamscore=0 phishscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 clxscore=1015 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-1908290000 definitions=main-1909270150 Archived-At: Subject: [saag] Improving the CHAP protocol - conclusion X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Sep 2019 18:23:19 -0000 SSdtIHJlc3BvbmRpbmcgdG8gTWF1cml6aW8ncyBvcmlnaW5hbCBtZXNzYWdlIHRvIGV4cGxhaW4g d2hhdCB3ZSAoTWF1cml6aW8gYW5kIHlvdXJzIHRydWx5KSBhcmUgZ29pbmcgdG8gZG8gYW5kIHdo eS4gIEZpcnN0IG9mIGFsbCwgd2Ugd2FudCB0byB0aGFuayBldmVyeW9uZSB3aG8gY29udHJpYnV0 ZWQgdG8gdGhpcyBwcm9kdWN0aXZlIGRpc2N1c3Npb24uDQoNClRoZSBUTDtEUiBjb25jbHVzaW9u IGlzIHRoYXQgd2Ugd2lsbCBhc2sgSUFOQSB0byByZWdpc3RlciBTSEEtMjU2IChmcm9tIHRoZSBT SEEyIGZhbWlseSkgYW5kIFNIQTMtMjU2IChmcm9tIHRoZSBTSEEzIGZhbWlseSkuICBQZXRlciBH dXR0bWFuIHN0YXRlZCB0aGUgZnVuZGFtZW50YWwgcmVhc29uIGZvciByZWdpc3RlcmluZyB0aGVz ZSBiYXNpYyBtZW1iZXJzIG9mIGVhY2ggaGFzaCBmYW1pbHkgYmV0dGVyIHRoYW4gSSBjb3VsZDoN Cg0KPiBXaGF0IHRoZSBvcmlnaW5hbCBwb3N0ZXIgYXNrZWQgZm9yIGlzIHNvbWV0aGluZyBGSVBT IGNvbXBsaWFudC4gIElmIHlvdSB3YW50DQo+IHRvIGNvbnZpbmNlIHNhaWQgdW1wdGVlbiBiYWpp bGxpb24gZGV2aWNlcyB0byBzd2l0Y2gsIHlvdSdkIGJldHRlciB1c2UgdGhlDQo+IHVuaXZlcnNh bC1zdGFuZGFyZCBGSVBTLWNvbXBsaWFudCBoYXNoIGFsZ29yaXRobSB0aGF0IGV2ZXJ5dGhpbmcg c3VwcG9ydHMsDQo+IHdoaWNoIGlzIFNIQS0yNTYsIG5vdCBhIGJ1bmNoIG9mIHdpZXJkbyBmYXNo aW9uLXN0YXRlbWVudCBhbGdvcml0aG1zIHRoYXQNCj4gbm90aGluZyBzdXBwb3J0cywgd2hpY2gg aXMgbW9zdCBvZiB0aGUgb3RoZXIgc3R1ZmYgdGhhdCdzIGJlZW4gc3VnZ2VzdGVkLg0KDQpUaGF0 J3MgdGhlIHByaW1hcnkgcmVhc29uIHRvIHJlZ2lzdGVyIFNIQS0yNTYgaW4gcHJlZmVyZW5jZSB0 byBTSEEtNTEyLzI1NiBhbmQgdG8gcmVnaXN0ZXIgU0hBMy0yNTYgaW4gcHJlZmVyZW5jZSB0byBT SEFLRTI1Ni4NCg0KRm9yIFNIQTIgaGFzaGVzLCB0aGUgbWVzc2FnZSBleHRlbnNpb24gYXR0YWNr IHRoYXQgbW90aXZhdGVkIGRldmVsb3BtZW50IG9mIFNIQS01MTIvMjU2IGRvZXMgbm90IGFwcGVh ciB0byBiZSByZWxldmFudCB0byBDSEFQLCBhdCBsZWFzdCBhcyB1c2VkIGJ5IGlTQ1NJLg0KDQpG b3IgU0hBMyBoYXNoZXMsIGEgcmVnaXN0cmF0aW9uIG9mIFNIQUtFMjU2IHdvdWxkIGhhdmUgdG8g aW5jbHVkZSBhbiBvdXRwdXQgc2l6ZSAoZCksIHdoaWNoIHdvdWxkIGJlIDI1NiBiaXRzLiAgRm9y IGEgMjU2IGJpdCBvdXRwdXQsIHRoZSBkaWZmZXJlbmNlIGJldHdlZW4gU0hBS0UyNTYgYW5kIFNI QTMtMjU2IHR1cm5zIG91dCB0byBiZSB3aGV0aGVyICcwMScgKDIgYml0cykgb3IgJzExMTEnICg0 IGJpdHMpIGlzIGFwcGVuZGVkIHRvIHRoZSBpbnB1dCBiZWZvcmUgcnVubmluZyB0aGUgY29yZSBL ZWNjYWsgaGFzaCBjYWxjdWxhdGlvbiBbMV0sIHdoaWNoICh3aGlsZSBpbXBvcnRhbnQgdG8gZGlz dGluZ3Vpc2ggdXNlIG9mIHRob3NlIHR3byBoYXNoZXMpIHNlZW1zIHRvIGxhY2sgYW55IHNlcmlv dXMgc2VjdXJpdHkgb3IgY3J5cHRvIGRpZmZlcmVuY2UuICBJbiBhZGRpdGlvbiwgdGhlIExpbnV4 IGtlcm5lbCAobG9jYXRpb24gb2YgYW4gaW1tZWRpYXRlbHkgaW1wb3J0YW50IGlTQ1NJIGltcGxl bWVudGF0aW9uKSBoYXMgcnVubmluZyBjb2RlIGZvciBTSEEzLTI1NiwgYnV0IG5vdCBmb3IgU0hB S0UyNTYuDQoNClsxXSBodHRwczovL2VuLndpa2lwZWRpYS5vcmcvd2lraS9TSEEtMyNJbnN0YW5j ZXMNCg0KT25jZSBhZ2FpbiwgbWFueSB0aGFua3MgdG8gZXZlcnlvbmUgd2hvIGNvbnRyaWJ1dGVk LCAtLURhdmlkDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpEYXZpZCBMLiBCbGFjaywgU2VuaW9yIERpc3Rpbmd1aXNoZWQg RW5naW5lZXINCkRlbGwgRU1DLCAxNzYgU291dGggU3QuLCBIb3BraW50b24sIE1BwqAgMDE3NDgN CisxICg3NzQpIDM1MC05MzIzIE5ld8KgwqAgIE1vYmlsZTogKzEgKDk3OCkgMzk0LTc3NTQNCkRh dmlkLkJsYWNrQGRlbGwuY29tDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogc2FhZyA8c2FhZy1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWF1 cml6aW8gTG9tYmFyZGkNCj4gU2VudDogV2VkbmVzZGF5LCBTZXB0ZW1iZXIgMTgsIDIwMTkgODoy NSBBTQ0KPiBUbzogc2FhZ0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbc2FhZ10gSW1wcm92aW5nIHRo ZSBDSEFQIHByb3RvY29sDQo+IA0KPiANCj4gW0VYVEVSTkFMIEVNQUlMXQ0KPiANCj4gSGVsbG8s DQo+IA0KPiBJIGFtIHdvcmtpbmcgdG8gc29sdmUgdGhlIHByb2JsZW0gb2YgRklQUyAoRmVkZXJh bCBJbmZvcm1hdGlvbiBQcm9jZXNzaW5nDQo+IFN0YW5kYXJkcykNCj4gY29tcGxpYW5jZSB3aXRo IHRoZSBpU0NTSS9DSEFQIGF1dGhlbnRpY2F0aW9uIHByb3RvY29sLg0KPiBDSEFQIGlzIGRlc2Ny aWJlZCBpbiBSRkMgMTk5NDogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzE5OTQuDQo+ IFRoaXMgZW1haWwgaXMgdG8gc3RhcnQgZGlzY3Vzc2lvbiwgYW5kIGxvb2sgZm9yIGd1aWRhbmNl Lg0KPiANCj4gQWxsIHRoZSBtYWpvciBpbXBsZW1lbnRhdGlvbnMgb2YgQ0hBUCBmb3IgaVNDU0kg dXNlIE1ENSBhcyB0aGUgb25seQ0KPiBzdXBwb3J0ZWQgaGFzaCBmdW5jdGlvbi4NCj4gVW5mb3J0 dW5hdGVseSwgTUQ1IGlzIG5vdyBjb25zaWRlcmVkIGluc3VmZmljaWVudCBmb3IgRklQUyBhbmQg aXNu4oCZdCBhbGxvd2VkDQo+IGl0IHRvIGJlIHVzZWQgb24gRklQUy1lbmFibGVkIHN5c3RlbXMu DQo+IEFzIGEgY29uc2VxdWVuY2UsIHdoZW4gRklQUyBtb2RlIGlzIGFjdGl2ZSwgdGhlIENIQVAg YXV0aGVudGljYXRpb24NCj4gZG9lc27igJl0IHdvcmsuDQo+IA0KPiBBcyByZXBvcnRlZCBieSBJ QU5BLCB0aGUgU0hBMSBhbGdvcml0aG0gY291bGQgYmUgdXNlZCBhcyBhbiBhbHRlcm5hdGl2ZSB0 bw0KPiBNRDU6DQo+IGh0dHBzOi8vd3d3LmlhbmEub3JnL2Fzc2lnbm1lbnRzL3BwcC1udW1iZXJz L3BwcC1udW1iZXJzLnhtbCNwcHAtDQo+IG51bWJlcnMtOQ0KPiBidXQgdGhlIHVzZSBvZiBTSEEx IG9uIEZJUFMgc3lzdGVtcyBoYXMgYmVlbiBkZXByZWNhdGVkIGFuZCB3aWxsIHNvb24gYmUNCj4g cGhhc2VkIG91dC4NCj4gDQo+IEkgdGhlcmVmb3JlIHByb3Bvc2VkIHRvIGFkZCBhIG1vcmUgbW9k ZXJuIGhhc2ggYWxnb3JpdGhtIChsaWtlIFNIQTMtMjU2KQ0KPiB0byB0aGUgbGlzdCBvZiBhcHBy b3ZlZCBDSEFQIGF1dGhlbnRpY2F0aW9uIGFsZ29yaXRobXMuDQo+IERhdmlkIEJsYWNrIHN1Z2dl c3RlZCB0byBjb25zaWRlciBhZGRpbmcgU0hBLTI1NiBhbmQgU0hBLTUxMi8yNTYgaW4NCj4gYWRk aXRpb24gdG8gU0hBMy0yNTYNCj4gYW5kIGFza2VkIG1lIHRvIHNlbmQgYW4gZW1haWwgdG8gdGhp cyBtYWlsaW5nIGxpc3Q6DQo+IA0KPiANCj4gRGF2aWQgQmxhY2sgd3JvdGU6DQo+IC0tLS0tLS0t LS0tLS0NCj4gTXkgc2Vuc2Ugb2YgdGhlIElFVEYgdmlldyBvbiBzZWN1cmUgaGFzaGVzIGlzIHRo YXQgTUQ1IGFuZCBTSEExIGFyZQ0KPiBicm9rZW4sIHdoZXJlYXMgXA0KPiB0aGUgU0hBMiBhbGdv cml0aG1zIGFyZSBwcm92aW5nIHRvIGJlIGxvbmdlci1saXZlZCAobW9yZSByZXNpc3RhbnQgdG8g YXR0YWNrKQ0KPiB0aGFuIFwNCj4gZXhwZWN0ZWQsIGFuZCB0aGUgU0hBMyBhbGdvcml0aG1zIGFy ZSBmaW5lLg0KPiANCj4gVGhhdCBzdWdnZXN0cyB0aGF0IHJlZ2lzdHJhdGlvbiBvZiBjb2RlcG9p bnRzIGZvciBib3RoIFNIQTIgYW5kIFNIQTMgd291bGQNCj4gYmUgYSBnb29kIFwNCj4gdGhpbmcg dG8gZG8sIGFzIG9wcG9zZWQgdG8gb25seSBTSEEzLiAgSSdkIHN1Z2dlc3Qgc3RhcnRpbmcgd2l0 aCBlaXRoZXIgU0hBLQ0KPiAyNTYgb3IgXA0KPiBTSEEtNTEyLzI1NiAoYm90aCBhcmUgU0hBMiBo YXNoZXMpIGluIGFkZGl0aW9uIHRvIFNIQTMtMjU2LCBhcyBhbGwgdGhyZWUNCj4gaGF2ZSB0aGUg XA0KPiBzYW1lIDI1Ni1iaXQgb3V0cHV0IHNpemUuDQo+IA0KPiBGaWd1cmluZyBvdXQgZXhhY3Rs eSB3aGF0IHNob3VsZCBiZSBkb25lIGhlcmUgKGUuZy4sIHdoaWNoIFNIQTIgdmFyaWFudCB0bw0K PiByZWdpc3RlcikgXA0KPiB3b3VsZCBiZW5lZml0IGZyb20gc29tZSBkaXNjdXNzaW9uIGF0IElF VEYuICBJIHdvdWxkIHN0YXJ0IHdpdGggdGhlIFNlY3VyaXR5DQo+IEFyZWEncyBcDQo+IHNhYWdA aWV0Zi5vcmcgbWFpbGluZyBsaXN0LiAgSW4gYWRkaXRpb24sIGFzIGlTQ1NJIGZhbGxzIHdpdGhp biBJRVRGJ3MgVHJhbnNwb3J0IFwNCj4gQXJlYSwgdGhlIFRyYW5zcG9ydCBBcmVhIERpcmVjdG9y cyBvdWdodCB0byBiZSBsb29wZWQgaW4gYmVmb3JlaGFuZC4NCj4gLS0tLS0tLS0tLS0NCj4gaHR0 cHM6Ly9tYXJjLmluZm8vP2w9dGFyZ2V0LWRldmVsJm09MTU2NzU1NTMzOTEyMzUwJnc9Mg0KPiAN Cj4gDQo+IA0KPiBUaGFuayB5b3UsDQo+IE1hdXJpemlvIExvbWJhcmRpDQo+IA0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzYWFnIG1haWxpbmcg bGlzdA0KPiBzYWFnQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2FhZw0K