From nobody Thu Oct 15 12:12:46 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26A8C3A12E0; Thu, 15 Oct 2020 12:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=josefsson.org header.b=VXTcEK3+; dkim=pass (2736-bit key) header.d=josefsson.org header.b=Jz9dWor1 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 XZ4coPpLksY1; Thu, 15 Oct 2020 12:12:36 -0700 (PDT) Received: from uggla.sjd.se (uggla.sjd.se [IPv6:2001:9b1:8633::107]) (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 5FE553A1268; Thu, 15 Oct 2020 12:12:35 -0700 (PDT) DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=ed20b09; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mHNDIgHe4Vhn6QACVz5prFUrdzftaDvaMVkxk1fYJLI=; b=VXTcEK3+xT+Ojh5c6tQSMkK9L x2C4MD5uXgssts/ffAN4I/drNyYyo1LPE+IBdS3KfMPNrD7qCfqcNdAy2SQAA==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=josefsson.org; s=rsa20b09; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:References:Subject:Cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=mHNDIgHe4Vhn6QACVz5prFUrdzftaDvaMVkxk1fYJLI=; b=Jz9dWor1G8AtAdFOK0X+u97hn xv23TZiQAUgp7iZyLWLYcqrrfbEjemtK7tyckl0v+nuotRIUQvP6fUnXSG2nHQjceyIYY0YYZ7YIg WWwgUo3T6nbw/l+70zJC96oi+lfbFYbqXuSxASxBlnfWlUG/Pc2Ya06CHBLYpZ7ryyAz/Q7q2T/ni atxrCVAm7TonBgfLQ/bSSe0a/TJRaWcF00KlrQfFOt+LGm7iXn3nkeHfzJUAjPo2fQGKbSx/ik26E AVCsITonXFzZmfssB9qU3kNHCVwEhG3/vLSBOlMVopKolIwdE2KlQAqyUnzxK7riAWKOQeB7BzNaX 8hK+8l/4EX6n6WqhCZ7CoJgjtXCcJU+sTe6nUGTxbt+P3FICO5uaNd0kFsD4gY7Hdu3ePvZjTHkNK hFeRvIjdtm+0FQqZRfViNGlTurrqbBDww4DSd4lKrqtk79; Received: from 31-208-42-58.cust.bredband2.com ([31.208.42.58]:52800 helo=latte) by uggla.sjd.se with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kT8ft-0006pK-In; Thu, 15 Oct 2020 19:12:30 +0000 From: Simon Josefsson To: Robbie Harwood Cc: "Cantor\, Scott" , Benjamin Kaduk , "draft-ietf-kitten-sasl-saml-ec\@ietf.org" , "kitten\@ietf.org" References: <20200902230243.GH16914@kduck.mit.edu> OpenPGP: id=B1D2BD1375BECB784CF4F8C4D73CF638C53C06BE; url=https://josefsson.org/key-20190320.txt X-Hashcash: 1:22:201015:draft-ietf-kitten-sasl-saml-ec@ietf.org::8rT/9EYYzLdzJ3ZD:1P+Z X-Hashcash: 1:22:201015:kaduk@mit.edu::AC24aJ1rrW+KtS8o:0xxs X-Hashcash: 1:22:201015:cantor.2@osu.edu::UG0zwsjtevAbWJRq:3pV6 X-Hashcash: 1:22:201015:kitten@ietf.org::1ehMWfx0AOXr8Kzs:4uf4 X-Hashcash: 1:22:201015:rharwood@redhat.com::/mqondCMyJF2F0yS:Dtu7 Date: Thu, 15 Oct 2020 21:12:28 +0200 In-Reply-To: (Robbie Harwood's message of "Thu, 10 Sep 2020 16:50:52 -0400") Message-ID: <87r1pzjobn.fsf@latte.josefsson.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-uggla-rspamd: ----- Score: -5.2 Action: no action Symbol: ARC_NA(0.00) Symbol: RCVD_VIA_SMTP_AUTH(0.00) Symbol: FROM_HAS_DN(0.00) Symbol: TO_MATCH_ENVRCPT_ALL(0.00) Symbol: MIME_GOOD(-0.20) Symbol: RCPT_COUNT_FIVE(0.00) Symbol: TO_DN_ALL(0.00) Symbol: NEURAL_HAM(-0.00) Symbol: RCVD_COUNT_ONE(0.00) Symbol: SIGNED_PGP(-2.00) Symbol: FROM_EQ_ENVFROM(0.00) Symbol: MIME_TRACE(0.00) Symbol: ASN(0.00) Symbol: RCVD_TLS_ALL(0.00) Symbol: BAYES_HAM(-3.00) Message-ID: 87r1pzjobn.fsf@latte.josefsson.org Archived-At: Subject: Re: [kitten] AD review of draft-ietf-kitten-sasl-saml-ec-19 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Oct 2020 19:12:39 -0000 --=-=-= Content-Type: text/plain Robbie Harwood writes: > "Cantor, Scott" writes: > >> While I appreciate the detailed review, mostly for my own educational >> purposes, I simply don't have anything close to the cycles it would >> take to redo the document to such a degree. Nobody is funding me to >> work on it, and events have long since overtaken it. >> >> I was hoping that it was more or less close to workable, and it's a >> vast improvement over the clearly-broken SAML and OAuth mechanisms >> that got rubber-stamped a long while back. That mistake is frankly >> what really motivated me at the time to work on it, but that was many >> years ago now. > > Appreciate your frankness here. With my shepherd hat on: > > Simon, do you think you have cycles to take this on? Hi. Apparently, I don't either. I would appreciate help with it. The reason for my lack of enthusiasm is my deployment experience with the "rubber-stamped" SAML SASL mechanism. I implemented it and it worked fine. Scott's SAML-EC approach would work even better and provide better security and more features. However neither provide anything that is likely to work in the real world with IMAP, SMTP and other common protocols: the problem is that client applications expect to open up tens of sessions to the server, and that authentication has to be quick and automatic for the user experience to work well. There are many ideas on how to solve that problem, and I believe we have discussed this before, but it is not realistic for me to find time to work on that problem now, and until that work is ready, working on SAML-EC has not felt worthwhile for me since it would have the same usability issue. /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSjzJyHC50xCrrUzy9RcisI/kdFogUCX4ifHAAKCRBRcisI/kdF opjkAP0dd8Nbykq/N1AoP1p+npGzMHczCTdIJuQfP/Bpg3OO/AEA8NHmVY7AuuDa DeTLEdEO1LLe/TE/L88EUOK8sOPohgc= =pfKz -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Oct 29 15:48:57 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D063A084D; Thu, 29 Oct 2020 15:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.099 X-Spam-Level: X-Spam-Status: No, score=-1.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=live.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 1HJu7UQcP2C3; Thu, 29 Oct 2020 15:48:53 -0700 (PDT) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11olkn2070.outbound.protection.outlook.com [40.92.19.70]) (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 7FE743A0317; Thu, 29 Oct 2020 15:48:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=htJnG/67zwGwOWC2k0Cju3l6X3p/lhxQ7GrtX9hz3R4HEfM7T8WaZWCoOp98NeodQUNR6O3R/QFK/HWJcoS3sBqhvUarww2RGwvY7wg/dk4bOkRTLXLe1qvT9u89zoE4v9JcFrCrILgKjstJv+gBPlDTmUK5/I03KaVzsIl/gecfOIldSSoKZcC53xIPSajr3z0A9+RHRGFojcInnJMCNAsq8k3JWxw9vk0c4xP8Dwv+c78XPGdMZpOsFbsvraZ+DW8tAcJ5sQraO468Vj/3wRj+li7Oq8QQo2fT9MCXSzCNdtvwQK3PTCxyxY/B4ra/5Z7hxwDbv/VditBxRMyr9Q== 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=U25Gki4eWYDvyTzP/XsrhP84CXm8rRBYed3/hGQwr2M=; b=OhGfTmlHcH1obPCwd3UCFJcaGQF2QfgGISMlt4vqYR0cb8Sz6TMr81Q8VVtcdXzPAELNPJuSvKDk5VIAOMoGVC3lRz96SFWDsvRu/ZGvfVUaPH0mbD4PcYZz20/gZTGiiBFz32fR69e/wcDO0Dg6R3/8pwkHWvRFdmBDQv2cPA5/17YRAxhTYAXxrboaLWAfFmrniMtsaYicNZ6Wwqg0O6EvjSLte3ILoTSnB7RXNSMC5POiPVuRSPqsQYkdxX/XSF6tpsg3rNm6OlXUhTUZcHIpAKPAlyswPxt0/FPRgrrEmQU0oy97klY9o0QrCf6KztRDn9vwZF8Ua0I8RnPeNA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=U25Gki4eWYDvyTzP/XsrhP84CXm8rRBYed3/hGQwr2M=; b=kduDfJVNMjciCQhC+6d8puJAu+Pf4ogFYxbFRV4npbzrVXO7eXEQUF/8var9/RjpPIWULtIKc9vOE0Mnv8Fqk9Sqm6CQUP8mveipWiNJltOLNxJzOJqRQ7lb23kbF6wWZUL87N9j3wT8Au5ex4SbAlHsoJjB7sGXiAYtAi4PjbAbBGW8KcASdtwSS5WZZdcM8hB/fiAMUuVHx4B1JzVwsgXVWr+U65dh7Ns/dzN/hcK578ZP7vIR+r5jsojfa7sspi5bwODej8dep+E0/oKDGj82qoLWXJNV5MbMYqbeSEPfXyKoIuVvobKEBcA9yiOOyqvbzX4AYBr1xYAY/F4oaw== Received: from DM6NAM11FT058.eop-nam11.prod.protection.outlook.com (2a01:111:e400:fc4d::41) by DM6NAM11HT256.eop-nam11.prod.protection.outlook.com (2a01:111:e400:fc4d::425) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Thu, 29 Oct 2020 22:48:48 +0000 Received: from DM5PR14MB1308.namprd14.prod.outlook.com (2a01:111:e400:fc4d::4d) by DM6NAM11FT058.mail.protection.outlook.com (2a01:111:e400:fc4d::216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3520.17 via Frontend Transport; Thu, 29 Oct 2020 22:48:48 +0000 Received: from DM5PR14MB1308.namprd14.prod.outlook.com ([fe80::f1a5:adad:5758:2de4]) by DM5PR14MB1308.namprd14.prod.outlook.com ([fe80::f1a5:adad:5758:2de4%10]) with mapi id 15.20.3499.027; Thu, 29 Oct 2020 22:48:48 +0000 From: Ludovic BOCQUET To: Robbie Harwood , Jim Fenton , "kitten@ietf.org" CC: "draft-ietf-kitten-password-storage@ietf.org" Thread-Topic: [kitten] Comments on draft-ietf-kitten-password-storage-00 Thread-Index: AQHWgx8GB467h9kG20m5bHwptIPHSal0/TqAgDqFl7Q= Importance: high X-Priority: 1 Date: Thu, 29 Oct 2020 22:48:48 +0000 Message-ID: References: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:D0FC931A60BFE00E20C8FE2E3A327D2C47A25064A1F6D2B7F711C961F25B2164; UpperCasedChecksum:84C9634737A82C78810C1D015A3E8FDE060D04BC5A9948750222C5A28C8F7C3B; SizeAsReceived:7043; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [NGPP1rPWWe44k8PRl70tMHHgJC0sB2s8] x-ms-publictraffictype: Email x-incomingheadercount: 47 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 2ba04058-2925-4a5f-1a92-08d87c5ccc73 x-ms-traffictypediagnostic: DM6NAM11HT256: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: EvQ+quZH5icILqJN4Yys9sFFjcKTi0vSXHMi/39S4xAiB4LDH2gO35mEJIjhrbJCNryHtyG12mKj6gfGbOnv0YiD/RCr65z8Ebk/N/BUF6jJUUnaw0IYLbgsdtl1DKp7wQqNHqfg9dmaXnhxkuR2pM0NtRKaWcixfKzB0W3OVn2dVtR9R1pGdPhdrzP7tV8ze6oYIPXOFtu9SMZQdUDPcbdemKAuvF8W1xMb1bBUEWnUFxL1K1RaTm5zJe8hB4Uu x-ms-exchange-antispam-messagedata: lK2yzH3iyuur/swOgFmYd+Cbj5znoX60hG1ixakNgX1CHtc1kdZfqnG/fDZS+JhOBfjvsLKDLFcxf7/qaO3N2FzfRgu6Tj12ujYg3EHb/J1/XoXm1E4sWD9fovg15cJeEPxvXCFR4hSa8MYKluNFRA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM5PR14MB130837085BB6E5FB1B592469B8140DM5PR14MB1308namp_" MIME-Version: 1.0 X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT058.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 2ba04058-2925-4a5f-1a92-08d87c5ccc73 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2020 22:48:48.0516 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6NAM11HT256 Archived-At: Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Oct 2020 22:48:56 -0000 --_000_DM5PR14MB130837085BB6E5FB1B592469B8140DM5PR14MB1308namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, I have done comments a long time ago about the previous draft-whited-kitten= -password-storage but my changes are not here, the author has maybe forgott= en it. There are some problems here: * SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS * SCRAM-SHA-1, SCRAM-SHA-256 It must be: * SCRAM-SHA-256-PLUS, SCRAM-SHA-256 * SCRAM-SHA-1-PLUS, SCRAM-SHA-1 Source: RFC8600: https://tools.ietf.org/html/rfc8600 * "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant = SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [R= FC7677] SHOULD be preferred over SHA-1 variants [RFC5802])" In the same time, I think that we must to add two new official SCRAM drafts= of the same author of SCRAM: Currently SCRAM-SHA-512-PLUS and SCRAM-SHA-512 are missing: - https://tools.ietf.org/html/draft-melnikov-scram-sha-512 Currently SCRAM-SHA3-512-PLUS and SCRAM-SHA3-512 are missing: - https://tools.ietf.org/html/draft-melnikov-scram-sha3-512 We can have: * EXTERNAL * SCRAM-SHA3-512-PLUS, SCRAM-SHA3-512 * SCRAM-SHA-512-PLUS, SCRAM-SHA-512 * SCRAM-SHA-256-PLUS, SCRAM-SHA-256 * SCRAM-SHA-1-PLUS, SCRAM-SHA-1 * PLAIN * DIGEST-MD5, CRAM-MD5 Explanation: * EXTERNAL * SCRAM-SHA3-512-PLUS, SCRAM-SHA3-512 (my request based on RFC8600: fro= m the best to the worst) * SCRAM-SHA-512-PLUS, SCRAM-SHA-512 (my request based on RFC8600: from = the best to the worst) * SCRAM-SHA-256-PLUS, SCRAM-SHA-256 (my request based on RFC8600: from = the best to the worst) * SCRAM-SHA-1-PLUS, SCRAM-SHA-1 (my request based on RFC8600: from the = best to the worst) * PLAIN * DIGEST-MD5, CRAM-MD5 (2 bad already with good order: from the best to= the worst) If you do not respect the RFC8600, it must be: * EXTERNAL * SCRAM-SHA3-512-PLUS, SCRAM-SHA-512-PLUS, SCRAM-SHA-256-PLUS, SCRAM-SH= A-1-PLUS * SCRAM-SHA3-512, SCRAM-SHA-512, SCRAM-SHA-256, SCRAM-SHA-1 * PLAIN * DIGEST-MD5, CRAM-MD5 Explanation: * EXTERNAL * SCRAM-SHA3-512-PLUS, SCRAM-SHA-512-PLUS, SCRAM-SHA-256-PLUS, SCRAM-SH= A-1-PLUS (good order: from the best to the worst) * SCRAM-SHA3-512, SCRAM-SHA-512, SCRAM-SHA-256, SCRAM-SHA-1 (good order= : from the best to the worst) * PLAIN * DIGEST-MD5, CRAM-MD5 (2 bad already with good order: from the best to= the worst) Thanks in advance. Regards, BOCQUET Ludovic ________________________________ From: Kitten on behalf of Robbie Harwood Sent: Tuesday, September 22, 2020 4:59 PM To: Jim Fenton ; kitten@ietf.org Cc: draft-ietf-kitten-password-storage@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00 Jim Fenton writes: > Hi, > > I'm not generally up to speed on the work of the kitten WG, but someone > pointed out this draft and thought I'd be interested, and I am. Please > bear that in mind if some of my suggestions conflict with GSS-API, > Kerberos, etc. And I'm not familiar with the various SASL mechanisms so > don't have any comments on them. Hi Jim, thanks for taking a look. Sam, have you had a chance to take a look at the review? Thanks, --Robbie --_000_DM5PR14MB130837085BB6E5FB1B592469B8140DM5PR14MB1308namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all,

I have done comments a long time ago about the = previous draft-whited-kitten-password-storage but my changes are not h= ere, the author has maybe forgotten it.

There are some problems here:
  • SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS
  • SCRAM-SHA-1, SCRAM-SHA-256=
It must be:
  • SCRAM-SHA-256-PLUS, SCRAM-SHA-256
  • SCRAM-SHA-1-PLUS, SCRAM-SHA-1=
  • "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS varia= nt SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants= [RFC7677] SHOULD be preferred over SHA-1 variants [RFC5802])"

In the sa= me time, I think that we must to add two new official SC= RAM drafts of the same author of SCRAM:

Currently SCRAM-SHA-512-PL= US and SCRAM-SHA-512 are missing:
- https://tools.ietf.org/html/draft-melnikov-scra= m-sha-512

Currently SCRAM-SHA3-512-PLUS and SCRAM-SHA3-512 are missi= ng:
- https://tools.ietf.org/html/draft-melnikov-scra= m-sha3-512

We can have:
  • EXTERNAL
  • SCRAM-SHA3-5= 12-PLUS, SCRAM-SHA3-512
  • SCRAM-SHA-512-PLUS, SCRAM-SHA-512
  • SCRAM-SHA-256-PLUS, SCRAM-SHA-256
  • SCRAM-SHA-1-PLUS, SCRAM-SHA-1
  • PLAIN
  • DIGEST-MD5, CRAM-MD5

Explanation:
  • EXTERNAL
  • SCRAM-SHA3-5= 12-PLUS, SCRAM-SHA3-512 (my request based on RFC8600: from the best to the worst)
  • SCRAM-SHA-512-PLUS, SCRAM-SHA-512 = (my request based on RFC8600: from the best to the worst)
  • SCRAM-SHA-256-PLUS, SCRAM-SHA-256 (my req= uest based on RFC8600: from the best to the worst)
  • SCRAM-SHA-1-PLUS, SCRAM-SHA-1 (my request based on RFC8600: from the best to the worst)
  • PLAIN
  • DIGEST-MD5, CRAM-MD5 (2 bad already with good order: from the best to the worst)

If you do not respect the RFC8600, it must be:
  • EXTERNAL
  • SCRAM-SHA3-5= 12-PLUS, SCRAM-SHA-512-PLUS, SCRAM-SHA-256-PLUS,&nb= sp;SCRAM-SHA-1-PLUS=
  • SCRAM-SHA3-= 512, SCRAM-SHA-512, SCRAM-SHA-256, SCRAM-SHA-1
  • PLAIN
  • DIGEST-MD5, CRAM-MD5
    • =
Explanation:
  • EXTERNAL
  • SCRAM-SHA3-5= 12-PLUS, SCRAM-SHA-512-PLUS, SCRAM-SHA-256-PLUS, SCRAM-SHA-1-PLUS (good order: from the best = to the worst)
  • SCRAM-SHA3-512, SCRAM-SHA-512, SCRAM-SHA-256, SCRAM-SHA-1 (good order: from the best to the worst)<= br>
  • PLAIN
  • DIGEST-MD5, CRAM-MD5 (2 bad already with good order: from the best to the worst)

Thanks in advance.

Regards,

BOCQUET Ludovic


From: Kitten <kitten-b= ounces@ietf.org> on behalf of Robbie Harwood <rharwood@redhat.com>=
Sent: Tuesday, September 22, 2020 4:59 PM
To: Jim Fenton <fenton@bluepopcorn.net>; kitten@ietf.org <k= itten@ietf.org>
Cc: draft-ietf-kitten-password-storage@ietf.org <draft-ietf-kitte= n-password-storage@ietf.org>
Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage= -00
 
Jim Fenton <fenton@bluepopcorn.net> writes:<= br>
> Hi,
>
> I'm not generally up to speed on the work of the kitten WG, but someon= e
> pointed out this draft and thought I'd be interested, and I am. Please=
> bear that in mind if some of my suggestions conflict with GSS-API,
> Kerberos, etc. And I'm not familiar with the various SASL mechanisms s= o
> don't have any comments on them.

Hi Jim, thanks for taking a look.

Sam, have you had a chance to take a look at the review?

Thanks,
--Robbie
--_000_DM5PR14MB130837085BB6E5FB1B592469B8140DM5PR14MB1308namp_-- From nobody Thu Oct 29 17:40:48 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBB563A0799; Thu, 29 Oct 2020 17:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=samwhited.com header.b=lVKIVxFj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dNr1PLCm 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 wUWnmANmM6WA; Thu, 29 Oct 2020 17:40:45 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 448C33A0769; Thu, 29 Oct 2020 17:40:45 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 8065C5C0152; Thu, 29 Oct 2020 20:40:44 -0400 (EDT) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Thu, 29 Oct 2020 20:40:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type:content-transfer-encoding; s=fm1; bh=h3 8mrh6z4htSol6mzYGOQFa0zcw4oXtqBA7i4LxMRT0=; b=lVKIVxFjt49lVbIbXO 09qhCkaQ3FW4vhXO/3GtWRD4QOvUFA78rr7VOZPswLYKYG4DtzQnZxq5xwu9vl3F 2Z/QXRgd5hOKOcy9fZDMwemzv9VqVL/DDOUUCKwIA70W3EdnP61rIm4n6i4OSkFk Zh1QvKe9qK+jFo6lyxzOTsoZwpAlhyfsm8FHZL86XVXP+XIcvVUwU2uMnrMvIXJz TdT+2l21qxfIgZcsun9PVIERsXMEjHIl3diV32cFOXihvUv2TSw/4Iz/t1SZhGoM ay6uymwP+cviBQo8QBIAOKE5gcGCCKAUrwiH2eYtYKOyf3XsXngS8mVFNowsCjAM P4Kw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=h38mrh6z4htSol6mzYGOQFa0zcw4oXtqBA7i4LxMR T0=; b=dNr1PLCmb5QTcgDlbKZZ/oF8GqrGNfmfF8IfI80BSQC6rbqTs2+NTs+Yn a3ejwFRHf9ibdaFsvK2wCpVdsGcJiOaT9UdkzLHpxKFog0r5NJpU9qTjTD6adYEe IBpfncLrNShglAjSsjItczn3uBeO78LSMyS0WBj9T4xuDhfWZuQGN5u8dFHY3IKP SeoTU/bdqtK9PLzjDnXoBIA1JXKsjiHzMiJv4OJFTq/umxRvAresZlEhHcK9CD3D mq0+KG5whlkzTI6wZ/t7WVPTSqQQcSr+Q/7B91ZRgvYr2JQkXSQTvXKY5kZNa59g F6xiHPD17ttEyakrONGKKxSwNuqJg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleeggddvgecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfurghm ucghhhhithgvugdfuceoshgrmhesshgrmhifhhhithgvugdrtghomheqnecuggftrfgrth htvghrnhepfeduudekkeeuteeuleefgeeuvdeuvdffhedvveeiffeghefhjefftdevveeu vdffnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id C30EE1460062; Thu, 29 Oct 2020 20:40:43 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35 Mime-Version: 1.0 Message-Id: <099cf65d-5a57-4e64-93cd-8504aa3bb97d@www.fastmail.com> In-Reply-To: References: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net> Date: Thu, 29 Oct 2020 20:40:23 -0400 From: "Sam Whited" To: "Ludovic BOCQUET" , "Robbie Harwood" , "Jim Fenton" , "KITTEN Working Group" Cc: "draft-ietf-kitten-password-storage@ietf.org" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 00:40:47 -0000 Hi Ludovic, On Thu, Oct 29, 2020, at 18:48, Ludovic BOCQUET wrote: > * "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS > variant SHOULD be preferred over the SCRAM-SHA-256 variant, and SHA= - > 256 variants [RFC7677] SHOULD be preferred over SHA-1 variants > [RFC5802])" I disagree with the RFC on this regard, but if further evidence can be provided I'm all ears. There are no known pre-image attacks against SHA-= 1, and the weaknesses I'm aware of at least won't matter for SCRAM since= SHA-1 is only used in the HMAC so to me it seems preferable to encourage= channel binding first, and the specific hash second. That being said, channel binding isn't actually very useful right now since there's no way to negotiate it and the existing methods are insecure without the TLS master secret fix, so maybe it doesn't matter either way. I am certainly not an expert and will bow to expert opinion if consensus= is against me, so I'd love more feedback on this. > In the same time, I think that we must to add two new official SCRAM > drafts of the same author of SCRAM: > > Currently SCRAM-SHA-512-PLUS and SCRAM-SHA-512 are missing: > - https://tools.ietf.org/html/draft-melnikov-scram-sha-512 > > Currently SCRAM-SHA3-512-PLUS and SCRAM-SHA3-512 are missing: > - https://tools.ietf.org/html/draft-melnikov-scram-sha3-512 I'm keeping an eye on those and am very excited to see them coming along! I'd prefer that they go through expert review first though before adding them to this document (although I do think it's appropriate to do so since they're both just I-Ds right now, so I don't feel strongly about this). I wouldn't want this document to go to RFC and still be referencing those I-Ds, but I don't know what the IETF position on this is; either way it seems worth waiting and keeping an eye on them for now. Thanks for your feedback! =E2=80=94Sam From nobody Thu Oct 29 18:38:55 2020 Return-Path: X-Original-To: kitten@ietf.org Delivered-To: kitten@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8AFCB3A0045; Thu, 29 Oct 2020 18:38:47 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: kitten@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.21.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: kitten@ietf.org Message-ID: <160402192743.6499.15301027108342670717@ietfa.amsl.com> Date: Thu, 29 Oct 2020 18:38:47 -0700 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-password-storage-01.txt X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 01:38:48 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Common Authentication Technology Next Generation WG of the IETF. Title : Best practices for password hashing and storage Author : Sam Whited Filename : draft-ietf-kitten-password-storage-01.txt Pages : 13 Date : 2020-10-29 Abstract: This document outlines best practices for handling user passwords and other authenticator secrets in client-server systems making use of SASL. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-password-storage/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-kitten-password-storage-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-password-storage-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Oct 29 18:45:24 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 803713A045E for ; Thu, 29 Oct 2020 18:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=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=samwhited.com header.b=nmmWESga; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hfWdx5No 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 XF7KcklybcDe for ; Thu, 29 Oct 2020 18:45:22 -0700 (PDT) Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E90D63A0408 for ; Thu, 29 Oct 2020 18:45:21 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 0FD08A32; Thu, 29 Oct 2020 21:45:20 -0400 (EDT) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Thu, 29 Oct 2020 21:45:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm1; bh=MDu7TdItb1/Vk2uIHKliaXS3LRrxfcA Ky6ntAlrptjw=; b=nmmWESgaq71E4hb+Ee8Vpqvd1f4fjHX1ccRMRnxp78qFAqm V9ynaFFR2IWz19EZiSKr/HNe5FvapaPmrKyN/qzFmS7obQ09ggKL9EzirbfAuhmk tmZH3y9+GOi/eAcwaviXduvxiQX8xF8fYTH37IgCF0zZ1hfDdB9imcG38X6Hnfux GqYkFirOahCTqI26p5cS4Pxs0lT7OEHqeF6qxi7/jZWzh2d3BGPvFyu7kuDd5gRJ puVitfBr0OvByb/b0ZdRzw+qdsPnhxOZatclNzXPfwhAh+FSh0vA/vrXsIa+kNzg 3arEOpmjBj1aVvltp1W03DJ4gkb5NlYUW95u7QQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=MDu7Td Itb1/Vk2uIHKliaXS3LRrxfcAKy6ntAlrptjw=; b=hfWdx5NovLf+4Khqi5rrmm 0zeuoC71Lf9PDA0KMJTm4MBeWrrAfbRuXnR2rRqj7FHarPmz2LVMlMoTx2qebQ9A Dy+cvOw0KlqHtQFexl0OUFeJtTxPqOxtVuks/XIsaZdwX8ysR84itBCQ5Ox2ZCcg RXIulUSWtbJTKvqwyD/0Y/ahGCqmQgEaPa5MkL90XOlxF1HjLHrX/fFydRKpTohB 88wVqisL4HOARozowazS6YtlHdlTPv8OpF6VHq+WIIMMiPr+MnV823clxOMBmAHZ LX94Op68R6AxdZjCPu1W75JuAKwi1CdHwvxWMeBlF0d8nlBOGmItDVi5V0hIV59A == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleeggdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfufgrmhcu hghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrghtth gvrhhnpeduvdfgkeeviedtkedugefhfeevhfehieejheejhfefieffhfduhefggfeuieej keenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepshgrmhesshgrmhifhhhithgvugdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 278341460062; Thu, 29 Oct 2020 21:45:20 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35 Mime-Version: 1.0 Message-Id: <1ba8e285-1b39-42aa-8359-94f94f7a6287@www.fastmail.com> In-Reply-To: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net> References: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net> Date: Thu, 29 Oct 2020 21:44:58 -0400 From: "Sam Whited" To: "Jim Fenton" , "KITTEN Working Group" Content-Type: text/plain Archived-At: Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Oct 2020 01:45:24 -0000 Hi Jim et al, Thanks for your reviews, I have published version 01 of the I-D which I believe captures all of your feedback. Thanks again, Sam On Fri, Sep 4, 2020, at 20:53, Jim Fenton wrote: > Hi, > > I'm not generally up to speed on the work of the kitten WG, but > someone pointed out this draft and thought I'd be interested, and I > am. Please bear that in mind if some of my suggestions conflict with > GSS-API, Kerberos, etc. And I'm not familiar with the various SASL > mechanisms so don't have any comments on them. > > 1.1 Terminology > > Since the term "salt" is so widely used in this document, it would be > good to reference a specific definition, since RFC 4949, SP 800-132, > and SP 800-63-3 all have different definitions. > > For "pepper", does "not unique" mean that there is one pepper value > for the entire database that is stored separately? This would be OK if > the database is salted as well (need to de-duplicate cases where > different users have the same password). > > 3.1 Mechanisms > > The end of paragraph 4 talks about providing a strong authenticator > assurance level. In NIST SP 800-63B, authenticator assurance level is > a categorization of authentication transactions (1-3), and single- > factor authentication such as a password is only ever AAL1 regardless > of how it's done. I suggest a different term be used here. > > 4.1 SASL requirements > > Hashes that are unsuitable for use with authenticators such as SHA256: > Should explain what makes them unsuitable. I gather that's because > SHA256 is too fast, especially with all the stuff developed for > cryptocurrency mining. But really all hashes are too fast to be used > alone; they need to be used iteratively or as part of a key derivation > function that is hopefully time- and memory-hard. > > 4.2 Storage > > Salts don't really need to be random; they just need to be unique, and > long enough to make it impractical to construct a rainbow table. "If > it is stored": the salt, I assume? Please be specific. The pepper > value should be stored at arm's length from everything else, such as > in an HSM or otherwise separate place (example: > https://github.com/jimfenton/rehash ). Storing the pepper in an > environment variable seems like a really bad idea to me. > > As I mentioned above, a minimum salt length of 16 bytes seems > excessive. NIST SP 800-63B requires 32 bits. Similarly, 32 bytes for > the pepper is more than is really needed; SP 800-63B calls for 112 > bits (but calls it a "salt" which is confusing). > > 4.3 Authentication and rotation > > Paragraph 2, "iteration count" - some algorithms refer to this as a > work factor so suggest "iteration count or work factor". > > Paragraph 3, Pepper rotation: In cases where the password is salted > and iteratively hashed, and then a keyed hash with the pepper value is > performed after that, it has been suggested that the keyed hash could > be replaced by a keyed encryption, which has the advantage of allowing > the key to be rotated by sending the verifier values to the peppering > process, which could decrypt the verifiers with the old key and > reencrypt with the new key. This makes a lot of sense; encryption > isn't really a problem here because there isn't a practical brute > force threat. > > 6. Password complexity > > Replace blacklist with blocklist, denylist, or something else > of course. > > "(when paired with the same email or other uniquely identifying > information)" - This would only result in denial of use of a password > if it was used by the same account, when really we want to deny the > use of things like passw0rd entirely. So just compare against the list > without identifying information (which you don't want to have anyway). > I'd leave out the part about commonly used patterns -- that leads down > a slippery slope to the complex composition rules we have today, when > really we just want to make sure common passwords aren't used. So if > "aaaaaaaa" is considered a common password, just put it on the > blocklist. > > I'm happy to discuss any of this further. Thanks for putting together > this draft. > > -Jim > > > -- Sam Whited From nobody Fri Oct 30 20:11:41 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31BB53A084D for ; Fri, 30 Oct 2020 20:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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 XBruPKXQU9PJ for ; Fri, 30 Oct 2020 20:11:38 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.196]) (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 3F57B3A0858 for ; Fri, 30 Oct 2020 20:11:38 -0700 (PDT) Received: from oxuslxaltgw04.schlund.de ([10.72.76.60]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LvDe8-1kQHFr1AiQ-010JbQ for ; Sat, 31 Oct 2020 04:11:37 +0100 Date: Fri, 30 Oct 2020 22:11:36 -0500 (CDT) From: steve@tobtu.com To: "kitten@ietf.org" Message-ID: <1616000628.98654.1604113896801@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev23 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:0bXpoFi3dfrtWwHbVLb6fJC122hfNshQOnfVdD3QlS0JFYIVfSW HREYq4Jx2Q7WnhdFzpLTtUSX+QPSuGUeAA7glOH/leaeHft9q+/lXT3zL+iIS/Y6NCvrIG9 z83zZPFaqyG4WUBpiL9yCP75IkD1oHC3xFlEQf5b2M6TbRf+OeBJIstyJDBeTpSykOG03Wb BM6I/uxi7MubQmcD8YK4g== X-UI-Out-Filterresults: notjunk:1;V03:K0:iTgYWEkPExk=:Y/D1t0x1QehGUVJdv02jHH rNckQjE8izPUQHQRq2ydcV3LU4yqlKymTh/bIj4PWA8I4So7TBILaJViM6mWYqEHRO4jTLDbU wr8r8aY7Lr0ZsxbCnxT5E/D06vnxiYqohK1a1OPQ4Kh8Uz8MdMGl8C658iDrulHxvhuHfLgAx SVSbG/5o2tFsV7xV4CrQwFrPE8vF5tcoT33P+43L+gJbRX+anMUG34/9DZaYLPfejM3BMk4PJ 5xFl7EzZbMmV5TB9aE5tNCrRSdul/sPL9TCgRJzMSG+3fjEuM3cOM1hSgAaAmNqSC23rnycAP cI9rd/ONZvhWArWzpO04WZaeMFTUjpylxzw9d8+fYzdtY0BRPjUyHL5sPOYLwDfxyK9MUN+Rw 8nPHILKlu+p/40i+Ah91ouGUcTRKu3MsUlrDWj6qJvReMAFFbi1/wd1FnBvES Archived-At: Subject: [kitten] Password KDF settings on draft-ietf-kitten-password-storage-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 03:11:40 -0000 For section 5 "KDF Recommendations" you should aim for an attacker to be slower than 10 kH/s/GPU for password authentication and slower than 1 kH/s/GPU for encryption. This is the current recommendation from professionals in the field. A GPU is a current high end GPU but not ultra high end, as those tend to have a lower performance per cost. A "GPU" is currently an "RTX 3080". There is another way professionals look at settings and that's the defender taking <100ms for password authentication and <1000ms for encryption. The password authentication <100ms is assuming one thread because for authentication you care about throughput and it's >10 auths/s/core. I like to look at limiting the attacker as that tells you minimums for good. Looking at defender's time sets a maximum which might still make it bad. Also a defender's hardware varies a lot and settings are all over the place, but we know what GPUs attackers can use. You should also state that these are minimum values for password authentication and that minimums should change when faster hardware or software is released. Minimums for password authentication (<10 kH/s/GPU): Argon2id: m=32*1024, t=1, p=1 * (unchanged) bcrypt: cost 9 ** PBKDF2-SHA1: 720,000 PBKDF2-SHA256: 310,000 PBKDF2-SHA512: 120,000 scrypt: N=32768 (N=2^15), r=8, p=1 * (unchanged) Minimums for encryption (<1 kH/s/GPU): Argon2id: m=256*1024, t=1, p=1 * *** bcrypt: cost 12 (even though this doesn't really make sense unless you wrap the output in a KDF) PBKDF2-SHA1: 7,200,000 PBKDF2-SHA256: 3,100,000 PBKDF2-SHA512: 1,200,000 scrypt: N=262144 (N=2^18), r=8, p=1 * *** * According to theoretical maximum speeds (see below) memory should be at least 36.2 MiB, 48.3 MiB, 362 MiB, and 483 MiB respectively. Actual memory bandwidth utilization is lower so I just went with 32 MiB and 256 MiB. Bandwidth utilization would need to be less than 88%, 66%, 71%, and 53% respectively on these settings. Which seems very likely. Side note on parameters, you can lower memory usage and increase t for Argon2id and p for scrypt. Basically you can think of it like: Argon2id: m * t >= 32768 (or this to be more accurate: m * (3 * (t - 1) + 2) >= 65536) scrypt: N * p >= 32768 ** It's on the cusp of being cost 9 and there's an optimization that should push it over the line to cost 9. (see next section) *** It is likely that using 128 MiB will be <1 kH/s/GPU due to reaching the point where doubling memory quarters attacker's speed. Bandwidth utilization would need to be less than 35% and 26% respectively on these settings with 128 MiB. ---- Benchmarks (https://gist.github.com/Chick3nman/bb22b28ec4ddec0cb5f59df97c994db4): PBKDF2-HMAC-SHA1 (i=1000): 7135.9 kH/s PBKDF2-HMAC-SHA256 (i=1000): 3029.2 kH/s PBKDF2-HMAC-SHA512 (i=1000): 1179.3 kH/s bcrypt (cost=5): 75778 H/s **** To get settings for <10kH/s/GPU with PBKDF2 take the speed and divide by 10 and round up (multiply by 1000 to get speed for "1 iteration" then divided by 10000 H/s to get iterations for 10 kH/s). For bcrypt the number of iterations is (1+2*2^cost). The formula to get bcrypt cost for <10kH/s is (started with "speed * (1 + 2 * 2^5) / (1 + 2 * 2^cost) = 10000 H/s" and solved for cost): cost = ceiling(log2((speed * (1 + 2 * 2^5) / 10000 - 1) / 2)) Settings for <10kH/s/GPU: PBKDF2-HMAC-SHA1: 720,000 PBKDF2-HMAC-SHA256: 310,000 PBKDF2-HMAC-SHA512: 120,000 bcrypt: 8 **** **** I have an optimization that should put it over the line to cost 9 (which is at >78930 H/s in a benchmark for cost 5). It has not been benchmarked on an RTX 3080 and there's an issue with it on the current version of hashcat that I need to fix. This was benchmarked on an older version of hashcat and on a different card. The increased speed means an RTX 3080 would be cost 9 for <10kH/s/GPU. Since the RTX 3080 has more shared memory, it would benefit even more from this optimization. Anyway I don't have actual benchmarks to back this up, but bcrypt should be cost 9 for <10kH/s/GPU. ---- For memory hard algorithms like Argon2 and scrypt, we're going to need to look at theoretical numbers. Looking at the bandwidth from https://en.wikipedia.org/wiki/List_of_Nvidia_graphics_processing_units#GeForce_30_series an RTX 3080 has 760.0 GB/s. For scrypt, it reads 1x and writes like 0.5x (depends on time-memory optimization) the memory used in the algorithm: N = 2^ceiling(log2(gpuBandwidth / 10000 / 1.5 / 128 / r / p)) For Argon2, the first iteration reads 1x and writes 1x the memory used in the algorithm and after that it reads 2x and writes 1x: m = ceiling(gpuBandwidth / 10000 / (2 + 3 * (t - 1)) / 1024 / 4 / p) * 4 * p Note the "ceiling(.../4/p)*4*p" this is because Argon2 rounds down 37,110 to 37,108 (for 760.0 GB/s, t=1, p=1). With Argon2 you have more leeway with the exact amount of memory but usually you round up the the nearest nice binary number. ---- Benchmarks for RTX 2080 Super (https://gist.github.com/epixoip/47098d25f171ec1808b519615be1b90d) > Hashmode: 8900 - scrypt (Iterations: 1) > Speed.#4.........: 1115.7 kH/s (7.23ms) @ Accel:16 Loops:1 Thr:16 Vec:1 Settings are N=1024, r=1, p=1 and GPU bandwidth utilization is about 44%. The runtime on it "7.23ms" is a little low so the speed should be higher with custom settings because less time is wasted in API calls. > Hashmode: 9300 - Cisco-IOS $9$ (scrypt) (Iterations: 1) > Speed.#4.........: 46069 H/s (99.74ms) @ Accel:16 Loops:1 Thr:8 Vec:1 Settings are N=16384, r=1, p=1 and GPU bandwidth utilization is about 29%. The low amount of GPU bandwidth utilization is interesting and I'm likely off with my estimates above as those are theoretical maximum speeds. Also as you use more memory you hit a point where doubling memory quarters attacker's speed. Hmm it appears it's not utilizing a lot of memory. Ignoring the scrypt time-memory optimization, it's only using 96 MiB and 768 MiB and the card has 8 GiB. From nobody Sat Oct 31 13:17:25 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18BC3A0E83 for ; Sat, 31 Oct 2020 13:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=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=samwhited.com header.b=eiyhkcjJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Mf/lllNW 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 ZZf8gr38XhbZ for ; Sat, 31 Oct 2020 13:17:22 -0700 (PDT) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 764CE3A0E82 for ; Sat, 31 Oct 2020 13:17:22 -0700 (PDT) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id B9AE55C0079 for ; Sat, 31 Oct 2020 16:17:21 -0400 (EDT) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Sat, 31 Oct 2020 16:17:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=samwhited.com; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm1; bh=KGdAU 2K4Ab1bbqsvofpKczh1ZrUIOUO8yDFLJ10xxR0=; b=eiyhkcjJf4jka7Ku9ZZ1g shOPp0fbBCecQ8Sb0O5OggQPqorIic+Q6gPXoq4lkIzFhccAsSAQV8h14hKkoMbt k1PDKEXz2g5jfjd/v1xyQBtQoIEltoDIdz4PS484LqcUnd7bF+FxMCZEiBEjxMr4 474PCp7FktS6uGqxu/Hs7bEyFlId6rEI7fneTgSffY2ev0/+8QqRGz5Yb5Ng+/gf v0jEPrfGNQPxcEH16allI1lMfeepUMHXUjQ3htsoj36q8IHSh6Unj3i1SRGh0f7h nzG1uW0c+byCyz6pHz24JvvslpX8x2KtA63nxNhh4lTH2bH7iBi5vesVqzBPG8S3 Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=KGdAU2K4Ab1bbqsvofpKczh1ZrUIOUO8yDFLJ10xx R0=; b=Mf/lllNWat6RxqdOgS+OnVYsBZ4ITOxSja587ESV6ezldu4a8BYRSaY7l PBIaL2vQ2YMoaXPIOMhPVJGLCw9Xxk9UQC6yTxf20KSKDLBjiYNs+0jFOp4SoU/4 vqfto4vVAl/jCsLwR6HlLQsQHpM77+4NWO09Y3rKQIdepDOF31qZPkNZfzR9V+Nv UuKN/p95zVovIn4ps6IKzArAtC9okye3F6IeCOc/qLw094M+ClpSkSDDttfNnRWm n9/zQNgkhL/KD6yS3sEJYNYKfI812WSggxuE5WgLLRNE21QdAwyHJEaNc0I81Iip jLIWKLvG9yvdvZmR8YOASteu2wsMg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleejgddufeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufgr mhcuhghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrg htthgvrhhnpedvffeuvdduhfefvdeiheeukeffhfekjeevgffggedtlefhhffhieevkedu vefhjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4FF061460062; Sat, 31 Oct 2020 16:17:21 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-530-g8da6958-fm-20201021.003-g69105b13-v35 Mime-Version: 1.0 Message-Id: In-Reply-To: <1616000628.98654.1604113896801@email.ionos.com> References: <1616000628.98654.1604113896801@email.ionos.com> Date: Sat, 31 Oct 2020 16:17:00 -0400 From: "Sam Whited" To: "KITTEN Working Group" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] =?utf-8?q?Password_KDF_settings_on_draft-ietf-kitten-pa?= =?utf-8?q?ssword-storage-01?= X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 31 Oct 2020 20:17:24 -0000 Hi, On Fri, Oct 30, 2020, at 23:11, steve@tobtu.com wrote: > This is the current recommendation from professionals in the field. Do you have a citation for these recommendations? As I mentioned in our private emails I'm hesitant to publish original research that hasn't been peer reviewed. Of course, if after undergoing expert review the folks here come to similar conclusions I'm happy to update the doc. For now I'm just using recommendations from OWASP and NIST. Including recommendations for how long a single round of your KDF should= take on some theoretical "average" hardware might be a good idea if we can come to a conclusion about what that hardware is. > You should also state that these are minimum values for password > authentication and that minimums should change when faster hardware or= > software is released. The latest draft of the document (-01) does so. =E2=80=94Sam From nobody Sat Oct 31 18:02:03 2020 Return-Path: X-Original-To: kitten@ietfa.amsl.com Delivered-To: kitten@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 481F13A0B39 for ; Sat, 31 Oct 2020 18:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=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 vzdsw2o0ft2r for ; Sat, 31 Oct 2020 18:02:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) (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 D5B853A0B3B for ; Sat, 31 Oct 2020 18:01:59 -0700 (PDT) Received: from oxuslxaltgw03.schlund.de ([10.72.76.59]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1Mna9J-1k7yoD0yFJ-00jWgq for ; Sun, 01 Nov 2020 02:01:56 +0100 Date: Sat, 31 Oct 2020 20:01:55 -0500 (CDT) From: steve@tobtu.com To: KITTEN Working Group Message-ID: <1557889497.117270.1604192515476@email.ionos.com> In-Reply-To: References: <1616000628.98654.1604113896801@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev23 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:RHKDvJLO8Nidunx90fNMXGLg/K4hdiq41vfnDN7tXjn9IvsNro8 Bhlwk2pYCpVBbOGLsr6rpQZq2XgKYXbBIdgR4cyElioAGkZCOlBWw6Z13/j4mumKOLVjuTZ I0GoTxTOz0x+vDRWAoCn85X1P0UEQHkTP8cX6U+cWzJQd/FzuUbn4GYLEy6SSfQZbFFFlGQ VmiqNYT5rLKw1vlAy6NcQ== X-UI-Out-Filterresults: notjunk:1;V03:K0:QAcWBy0oqC0=:vDERDxwh3JQFX/zi+2skPV CsA8iKslDSTfkX7VCLk/lKkoweGIDwtutThTlSShdFRxtpdchw0D3jW2WXETziOfb4MPVzu4V OWpKQer045x3Mv+GG/ElrtipLuP1W/4fphMAW1hFVC0jLYGbCSwbe/qWYoWozGJUh7c3x4ZZg KJMN4UsneMt/5IhyGWuNthNUSx1rA+N35fXNWXUWLedC11gUBrTAPLXTdyhqNUTuSISop/zmp NjCbuE1BSEdrZGHeC4pXbr6Enp8IjpbdshPe5Is/Z/91kC8VVoeichIpZyARYGKuwHmOUjxZN FSEfbzKVuoCT+PnSEkvjKtXpsWq86X1+YFwhyspSawLVpTWYk4KeTM2/R7ErzDZ8GUmozRi1A X9XhWURONfYPfewRWs7DduNFKgxAb1UbpFEGD5o6VnSqABeqoRDUg27mNreOn Archived-At: Subject: Re: [kitten] Password KDF settings on draft-ietf-kitten-password-storage-01 X-BeenThere: kitten@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Common Authentication Technologies - Next Generation List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 01 Nov 2020 01:02:01 -0000 > On 10/31/2020 3:17 PM Sam Whited wrote: > > Hi, > > On Fri, Oct 30, 2020, at 23:11, steve@tobtu.com wrote: > > This is the current recommendation from professionals in the field. > > Do you have a citation for these recommendations? Two panelists from the Password Hashing Competition (Jeremi Gosney and me). I believe Jeremi is the one who first stated the recommendation of <10 kH/s/GPU for password authentication. He has a company that sells password cracking hardware to large companies and governments. Also Sam Croley, an esteemed professional password cracker, agrees. If you want I could probably find a few others in the industry that agree, but it is unlikely that anyone is going to write a paper on this topic as it's more like a tweet than a paper. > As I mentioned in our > private emails I'm hesitant to publish original research that hasn't > been peer reviewed. Of course, if after undergoing expert review the > folks here come to similar conclusions I'm happy to update the doc. You told me to post it on the IETF mailing list for review. So I collected everything I wrote and updated it for *-01 and for RTX 3080 since that just replaced the RTX 2080 Super as a "GPU". > For > now I'm just using recommendations from OWASP and NIST. Note that the recommendation from OWASP for bcrypt was briefly changed to cost 12 by one person and switched back to cost 10. Their defense cited your draft as why to keep it at cost 12. Until I pointed out that they are now citing each other. > > You should also state that these are minimum values for password > > authentication and that minimums should change when faster hardware or > > software is released. > > The latest draft of the document (-01) does so. Only PBKDF2 says that the settings are a minimum. Oh the "should change when faster hardware" that was in *-00. I must of missed that the first time I read it and obviously it wasn't highlighted in the diff.