From nobody Sun Nov 1 02:11:26 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 320B33A102A for ; Sun, 1 Nov 2020 02:11:24 -0800 (PST) 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=t1mJefUJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=d/Voh6zh 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 3agbAmMd3vRv for ; Sun, 1 Nov 2020 02:11:22 -0800 (PST) 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 2B05F3A1022 for ; Sun, 1 Nov 2020 02:11:22 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 818A35C0099 for ; Sun, 1 Nov 2020 05:11:21 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Sun, 01 Nov 2020 05:11:21 -0500 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=XQm5j JLymDNaSxFec5psr2K9GNMeN5TTt+C9IOEZVBU=; b=t1mJefUJ0uAfV7IurDarG Wcr00R8YCs5jeUOfmRhn3r8rCfaAbEhtRuWSRenkTrnr20mVVji6PxmiqWZDQVS2 47NL00Ks8kXixufu66k/Sbu+8mqa2eddmXwhcSMsIHDFwxmyX28I6kE00re7Lf/n U1av1SHLZ5iTOYKFx2M3WYLU0ShW5PsnSibiw8/8Nkcxyx58a92bjV0Rss7fT2HN PjMJk/ICsAJNa1lAFupcJdZ35d3h/p0uUy/eJs/JhipZdXWEHdrbUWNXKcv0K0Jy 5eXwoZX2g2anNVw5wnydbDhxkmw6JwrDeB5DSzZIv/12m7TKaZZB0T8FOnOONsGw A== 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=XQm5jJLymDNaSxFec5psr2K9GNMeN5TTt+C9IOEZV BU=; b=d/Voh6zhgBqGCbCrgRXG6vgKgFSwfq8UoMhWU8w3+N1nVLS3YfiQavxSf EbaMeamQ0JfipGyinXqTwPSsw1ZXo0gNGN5gfWn2GOzafnN/YVkWryh09+/aDbLH Q9fl+3a/5P9dnpLwl7rLiZ4D3yckQSvegcJlCf3SukZpdKgOjhrkiGjmeOnH5sCn o6YTNX2NgyYiN9HyODlKprLIrUDLdfgUjsksoQcp05wPeBM3ZbSW1gvzT10sxLRg wgdGVp5lvHDO9hRlfonXtMX2Cq371CUkCCnzp/7qSeflksk3m+VUW8GLW2KG5i3j wChbAjw/2/Ck0z8SFzXOOZc4m60ZQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrleelgddugecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfurghm ucghhhhithgvugdfuceoshgrmhesshgrmhifhhhithgvugdrtghomheqnecuggftrfgrth htvghrnhepveehfeekgffhtddvvdffuedvveejteefteehveduuddvteeuhfdvieeiudeg feeinecuffhomhgrihhnpehofigrshhprdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepshgrmhesshgrmhifhhhithgvugdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 15D221460062; Sun, 1 Nov 2020 05:11:21 -0500 (EST) 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: <67b8bf34-030d-43db-abd7-4ab6573c4d9e@www.fastmail.com> In-Reply-To: <1557889497.117270.1604192515476@email.ionos.com> References: <1616000628.98654.1604113896801@email.ionos.com> <1557889497.117270.1604192515476@email.ionos.com> Date: Sun, 01 Nov 2020 05:10:45 -0500 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: Sun, 01 Nov 2020 10:11:24 -0000 On Sat, Oct 31, 2020, at 21:01, steve@tobtu.com wrote: > 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. Oh yes, that's definitely not good; the document I see (https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_S= heet.html#bcrypt) still shows 12 though, do they have other recommendations listed somewhere else? > Only PBKDF2 says that the settings are a minimum. Oops, I thought I updated all these values but I guess I missed them. Sorry about that, will fix with the next draft. Thanks! =E2=80=94Sam From nobody Tue Nov 3 06:27:51 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 A350B3A0B9D; Tue, 3 Nov 2020 06:27:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, 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 (1024-bit key) header.d=isode.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 hRzg6uPTc1-Z; Tue, 3 Nov 2020 06:27:48 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 20D063A0BAD; Tue, 3 Nov 2020 06:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1604413666; d=isode.com; s=june2016; i=@isode.com; bh=FV2PNDB3ZkvUeZYoEOxEjwttUJaI/rZRxgR9Wu02tHY=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=vDaKWqFeiuRmZrVcDESRt1XK5/ReiS+dTkT3icyDZ19s2Y0fwgq9R2SX5C4nJnYwLy7ABt 6et4Dgxvru8bZDSVntS9eb9LblgDlVUDKsin3BHY5vZFJ8dfGh54OtTvOzP9oQv4+z7s9W asbXuZRsoU7eKVwp3BJ5PXTeLHmXXJA=; Received: from [172.27.251.239] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 3 Nov 2020 14:27:45 +0000 From: Alexey Melnikov To: Sam Whited , Ludovic BOCQUET , Robbie Harwood , Jim Fenton , KITTEN Working Group Cc: "draft-ietf-kitten-password-storage@ietf.org" References: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net> <099cf65d-5a57-4e64-93cd-8504aa3bb97d@www.fastmail.com> Message-ID: Date: Tue, 3 Nov 2020 14:27:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 In-Reply-To: <099cf65d-5a57-4e64-93cd-8504aa3bb97d@www.fastmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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: Tue, 03 Nov 2020 14:27:50 -0000 Hi Sam, I tend to agree with Ludovic on ordering. More on this below: On 30/10/2020 00:40, Sam Whited wrote: > 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 I think trust in SHA-1 is diminishing, so it will be phased out even if HMAC-SHA-1 is still considered to be Ok. I think at this point we shouldn't encourage use of SHA-1 with SCRAM, unless this is required for backward compatibility reasons. > channel binding first, and the specific hash second. That I agree with. So maybe the following ordering: SCRAM-SHA-256-PLUS SCRAM-SHA-1-PLUS SCRAM-SHA-256 SCRAM-SHA-1 ? > 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. Fixing channel binding for TLS 1.3 is something that we need to do anyway. But this is a separate discussion. > 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. Fair point. Best Regards, Alexey From nobody Tue Nov 3 06:56:56 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 7C8BC3A0C73 for ; Tue, 3 Nov 2020 06:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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 (1024-bit key) header.d=isode.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 ILDlkupJwlZ2 for ; Tue, 3 Nov 2020 06:56:54 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 459AA3A0C63 for ; Tue, 3 Nov 2020 06:56:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1604415413; d=isode.com; s=june2016; i=@isode.com; bh=HJFppgQ6cAbDhImRfMirDWc9t8Za310pETmz1ID34Pc=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=mT4/AB67hVIPpoP9q2xi/+Vf/qCgGlRV2c0eodPkh0goEdJlvaE/rrF5rkdaoDMOuyCj+f M/KKTZQrkNQEs0dUg2Y8ClTiY8sz/6+yF15OWuHXWKraW251XLYjslznCJ5Qcxn57OKusU yTWPGgb/xZENw4+XKyLNee7uVtwdoHM=; Received: from [172.27.251.239] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Tue, 3 Nov 2020 14:56:53 +0000 From: Alexey Melnikov To: Sam Whited Cc: "kitten@ietf.org" Message-ID: <50594cb1-1827-814f-1dfa-28a8d9449ce7@isode.com> Date: Tue, 3 Nov 2020 14:56:38 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: [kitten] Comments 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: Tue, 03 Nov 2020 14:56:56 -0000 Hi Sam, I just had a quick read of -01. There are some things I need to think=20 about and might comment on later on. But a few small questions/comments below: > 4.2.=C2=A0 Storage > > =C2=A0=C2=A0 Servers MUST always store passwords only after they have been= salted > =C2=A0=C2=A0 and hashed using a strong KDF.=C2=A0 A distinct salt SHOULD b= e used for > =C2=A0=C2=A0 each user, and each SCRAM family supported.=C2=A0 Salts SHOUL= D be > =C2=A0=C2=A0 generated using a cryptographically secure random number gene= rator. > =C2=A0=C2=A0 The salt MAY be stored in the same datastore as the password.= If it > =C2=A0=C2=A0 is stored alongside the password, it SHOULD be combined with = a pepper > =C2=A0=C2=A0 stored in the application configuration, or a secure location= other > =C2=A0=C2=A0 than the datastore containing the salts. Can you describe in more details what the last quoted sentence means for=20 a server SCRAM implementation? Does this mean reading (or deriving) salt=20 for a particular user and appending pepper to it, then using the=20 combined string as SCRAM salt? Either way, I think you should either=20 give an example or clarify with text. > 5.3.=C2=A0 PBKDF2 > > =C2=A0=C2=A0 PBKDF2 [RFC8018] is used by the SCRAM [RFC5802] family of SAS= L > =C2=A0=C2=A0 mechanisms. > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= Parameter=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Value=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 | > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > =C2=A0=C2=A0=C2=A0 | Minimum iteration count (c) | 10,000=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Sorry, I might have missed this discussion, but I am curious to know=20 where this number came from. (And a note to myself: I should update=20 SCRAM-SHA-512 draft to match). Best Regards, Alexey From nobody Tue Nov 3 16:54:36 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 AE2BC3A12F3 for ; Tue, 3 Nov 2020 16:54:34 -0800 (PST) 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_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 ojxAOeyftKZN for ; Tue, 3 Nov 2020 16:54:33 -0800 (PST) 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 522413A12AD for ; Tue, 3 Nov 2020 16:54:33 -0800 (PST) Received: from oxuslxaltgw04.schlund.de ([10.72.76.60]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0LuwOl-1k9CIY1DBB-0102Aj for ; Wed, 04 Nov 2020 01:54:31 +0100 Date: Tue, 3 Nov 2020 18:54:30 -0600 (CST) From: steve@tobtu.com To: "kitten@ietf.org" Message-ID: <1765727465.185643.1604451270638@email.ionos.com> In-Reply-To: <50594cb1-1827-814f-1dfa-28a8d9449ce7@isode.com> References: <50594cb1-1827-814f-1dfa-28a8d9449ce7@isode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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:Y7Xa5Jez2lzPrGXHMbLEt4f3+brbYT5DRPie+wV5PDY9LNsSPHS b6xIxqpk3Herk8WceQAWkXBF/t+qB60RtptJfHkCs6lRPejzYtowyyFyfU19YyCuELThKF0 XzdVM1HhQJrauMOA96ZCBJ8z8ETz+yNEpNrjlHVGMpMFZ9JjEInIt1w0tP9fTN6n8lCww5O AFWpGTx0Ykr8wkDCRGKqw== X-UI-Out-Filterresults: notjunk:1;V03:K0:SLz7uXOF7AA=:uDILluoe4WzTcRfWJVwUQX jQ531GBgQd1/jLn9zUqKPkx0f/Lfuyu937DW561yD/2EP+PiS919cMukeYbpRS4KryoIknCyg 0GCgk/Stk67LDpuxjlajFuUFHNXFSXIZTNVcaOenRiEQbGuXpHxsZKQOZ4zvcXHOphelnVR/i ZneDyxp7E6fh468xAHq06t7EVTuYSL6HyBJb2gG+CHsKdJ3GtnNQcNcfEIp9rMWJCybIqhdFm tYAVy6/yoklN07/AGaKKq4TBhw3X35mm7BHWt5ObA67qE+Ou9gUHCWDDe+sJHigKm91YTb5Xv D5/WMsujDaoCQg76fd3YPl8TMp9kLyRh6NRKCRwuX8EmpRgG5PdpUHs5jdjn4us1bzMkyGMxM 2jgy7OPd8HxN1US5rYno8WGoqM423pvtsEdTaWWrZKD5QFldn3soiIQlavdPD Archived-At: Subject: Re: [kitten] Comments 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: Wed, 04 Nov 2020 00:54:35 -0000 > On 11/03/2020 8:56 AM Alexey Melnikov wrote: >=20 > > 5.3.=C2=A0 PBKDF2 > > > > =C2=A0=C2=A0 PBKDF2 [RFC8018] is used by the SCRAM [RFC5802] family of = SASL > > =C2=A0=C2=A0 mechanisms. > > > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > > =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0 Parameter=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | Value= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0 | > > +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > > =C2=A0=C2=A0=C2=A0 | Minimum iteration count (c) | 10,000=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | >=20 > Sorry, I might have missed this discussion, but I am curious to know=20 > where this number came from. (And a note to myself: I should update=20 > SCRAM-SHA-512 draft to match). NIST currently says at least 10,000 and everyone copied it from them. It wa= s changed from 1,000 in 2000 to 10,000 in 2016 (https://web.archive.org/web= /20160624033024/https://pages.nist.gov/800-63-3/sp800-63b.html#memorized-se= cret-verifiers). From nobody Tue Nov 3 16:56:39 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 E07093A12F3 for ; Tue, 3 Nov 2020 16:56:37 -0800 (PST) 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 ulPfKhGYxCdH for ; Tue, 3 Nov 2020 16:56:36 -0800 (PST) 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 7B9C33A12FC for ; Tue, 3 Nov 2020 16:56:36 -0800 (PST) Received: from oxuslxaltgw04.schlund.de ([10.72.76.60]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MeTLU-1k1sHP2oNw-00aUHj for ; Wed, 04 Nov 2020 01:56:35 +0100 Date: Tue, 3 Nov 2020 18:56:35 -0600 (CST) From: steve@tobtu.com To: "kitten@ietf.org" Message-ID: <826092494.185664.1604451395074@email.ionos.com> In-Reply-To: <1083773715.184522.1604446745441@email.ionos.com> References: <1616000628.98654.1604113896801@email.ionos.com> <1557889497.117270.1604192515476@email.ionos.com> <67b8bf34-030d-43db-abd7-4ab6573c4d9e@www.fastmail.com> <1083773715.184522.1604446745441@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:QhWhFLwyDr0r5fl02SrL4lWP0rbAReOjDKS7PFBO2dTrw5yW4AO GUAz6vIr5CE9rIDip8CE9rXD/TXoNd2+rh4BrN0o0m6Oc0kkGuGot1HiiEHVsrM1GS8FeVa HyHyWWWHVMXDed53ekCpNor9Gi0qNh8wG6fGOPKO+i7/D0RlOuYAVUBUbPgIfmulNsfr4vI gNYSclLOMSvwIbsJSPNsw== X-UI-Out-Filterresults: notjunk:1;V03:K0:zMdra+ZhsqM=:10rFNb+rtrH+1QCW+BbbKf h+2+oZFtf6bbH+d9BdCWGqg1BxBdC4v+h+MQ+djR3/8lcZnHup3t9QZpz7gR+4P47f1dVP0kc 132LkmhKYuetDrRPe2a9FlDeZrAFjukhWh3p9QGvKAeYy8VGuzXmXd3zgaQpAbMQpXNkIw8oc WowhENi8DPnMuddC6eT8xdnsf+QHoL/soEnUrH6F4M/lRQ+czgmqC84qgbZpyS3nasUFYy5d8 ogB5qmiTQmuNjQ1aw/e/l1Qs9N1CkHgcWiWPdxyttTVpyHo+xcCqmQB1MJHfJnsJjpws1z8VF sVzN24mkPfHFwTABnEFLbjVqAP1k2pP/QZSeCXJXBXIf2nA/RJB94Vg7ra1FiUe5m/VRZohLf 4vDuQxiP8N2eiGRwECIai69tttyIY1ztte5DtAl813G8OIx8WryMajI7CJqhM 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: Wed, 04 Nov 2020 00:56:38 -0000 Oops I didn't reply on list: > On 11/03/2020 5:39 PM steve@tobtu.com wrote: > > > > On 11/01/2020 4:10 AM Sam Whited wrote: > > > > > > On Sat, Oct 31, 2020, at 21:01, steve@tobtu.com wrote: > > > 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. > > > > Oh yes, that's definitely not good; the document I see > > (https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#bcrypt) > > still shows 12 though, do they have other recommendations listed > > somewhere else? > > If you are taking bcrypt cost 12 from OWASP, then you should take PBKDF2 100,000 iterations too. Since those are the "well if you can, go for these numbers". Just a reminder bcrypt cost is exponential so cost 12 is 16 times harder than cost 8 and cost 8 is equivalent to PBKDF2-SHA256 300,000 iterations. Note both cost 8 and 300,000 iterations are just over 10 kH/s/GPU thus are considered not good. > > "The default work factor for Bcrypt is 10, and this should generally be raised to 12 unless operating on older or lower-powered systems." > > "The work factor for PBKDF2 is implemented through the iteration count, which should be at least 10,000 (although values of up to 100,000 may be appropriate in higher security environments)." From nobody Wed Nov 4 05:06:43 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 BAC4C3A11C1; Wed, 4 Nov 2020 05:06:41 -0800 (PST) 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=pdJQREfd; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=oZ2NrPiH 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 BFKob4sztl3A; Wed, 4 Nov 2020 05:06:39 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDEC63A0365; Wed, 4 Nov 2020 05:06:38 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id E3C125C00F4; Wed, 4 Nov 2020 08:06:37 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Wed, 04 Nov 2020 08:06:37 -0500 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=Dz yHOPv4wpRjcQGWzC8BjcKgc5Ix85Pc4EXzvK7iD2E=; b=pdJQREfdUQ4U5hgcEt zjNjnLzSbr/ViRY9mx2DMm2X3XMU52Lc0GKy76Bf+/bcHZ0SJert+M5DUi3tjhRh YtdAWnob3OUEd7iRe7ykYkCdAfTxW0ZwnOq1jJbh0y+QhU6gr8sblNn8HmhzZXnT 5y+jOKlaZH+mi2UNrHUlLC9vBLJlCaw1yNT21i+b1IViJKEUW7HLPLT7ynsY4aYp MQk3xxY3ZjhPEOyX1bz5MQOJdfdnruj64oA69NDkEc1vw0fiQlcWnufqFg5vVhxG O+OcAd2m+Qz5EE3rvgLkFqcVtjiK89qEtWjMSioBl0tS+AjsqDaPrP+HX9IZvHPC dJlg== 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=DzyHOPv4wpRjcQGWzC8BjcKgc5Ix85Pc4EXzvK7iD 2E=; b=oZ2NrPiHqm/EDfBD8JPUk548ZzzfqkRavPF7HsZlGzF+maOnbGqMZMo6B SEbrrMk3FY36DW9pLuN7hgiULtmhLS0kE9C8X3Ysk1mKNNKMlzV5SPiF7u61OktF 35OZ8TWkFNStClerwNImyry59XcKgW30oYXK+9vmVsDrjbN8dehkV2KHSxZmY8M7 unRNx0BNRFXNyfgbih6wdSeNxC1inUv1zK3+YxcS4Z/2+8wfK4skPm0gPN9k1TGs xIzZ8vaLntPTZwhUv18BlSLCsWGq0CZn28hUbgZd5BKXBYGyOo49AaCC6dVXcFFK hHVdw/ZFHHf+BlPjKONrhrNGcg6cA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddthedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufgr mhcuhghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrg htthgvrhhnpeefuddukeekueetueelfeeguedvuedvffehvdevieffgeehhfejffdtveev uedvffenucffohhmrghinhepihgvthhfrdhorhhgnecuvehluhhsthgvrhfuihiivgeptd enucfrrghrrghmpehmrghilhhfrhhomhepshgrmhesshgrmhifhhhithgvugdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 120D21460062; Wed, 4 Nov 2020 08:06:36 -0500 (EST) 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: References: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net> <099cf65d-5a57-4e64-93cd-8504aa3bb97d@www.fastmail.com> Date: Wed, 04 Nov 2020 08:06:16 -0500 From: "Sam Whited" To: "Alexey Melnikov" , "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: Wed, 04 Nov 2020 13:06:42 -0000 Responses inline. TL;DR I agree. On Tue, Nov 3, 2020, at 09:27, Alexey Melnikov wrote: > That I agree with. So maybe the following ordering: >=20 > SCRAM-SHA-256-PLUS > SCRAM-SHA-1-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1 That seems fine to me, I'll update in the next version. > Fixing channel binding for TLS 1.3 is something that we need to do=20 > anyway. But this is a separate discussion. See also https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-= bindings-for-tls13/, I'd love your feedback there too. =E2=80=94Sam From nobody Wed Nov 4 05:10:12 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 757983A11D9 for ; Wed, 4 Nov 2020 05:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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_H2=-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=bQUqHL3p; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=qSNNkBdf 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 J1E6i5LJsAhG for ; Wed, 4 Nov 2020 05:10:09 -0800 (PST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F94A3A11F4 for ; Wed, 4 Nov 2020 05:10:09 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7F8A3EC6; Wed, 4 Nov 2020 08:10:07 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Wed, 04 Nov 2020 08:10:07 -0500 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=GL coP3eBwOkH3mcq18W1+n/udmS+iYG3+lNskgEMRu8=; b=bQUqHL3pQLHvlSvSIN l6EwOty1ZpxthSZQRH02ks1DSbE3MkKoFeuMxqqJzr/WJnig4za4RHCNXS8+ubz1 Woz+ZMLxDBOCPNXEAEDUixjG6N9ndPufrOt1pmPvYcFwfZ1CdmVrMXHMlwU1EQI1 ndxYKaoBS1cLw7atjp/U7p632INk32Ya+uj59sA9J9iYfJUKJs+Inj2flYsAzYMV BbDGcBbeGLuM0+dzDaSTVz6/Aq9cbrF5Efbn9YTDhdsyaSqZlkaxbPJINFq17UZd PbD05Y8Ed7FYV1afYQm2Y6QHhKwvPZ5Z0eP5bvYwmUza1/OknmpUKt6biVn3qa4c oniA== 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=GLcoP3eBwOkH3mcq18W1+n/udmS+iYG3+lNskgEMR u8=; b=qSNNkBdfT6Lfl5v6Irn4E6y6drDC0uRs4PbAdZCFpd5pxs3r9b0ZX695h VqIxTufV7FzpbNbBLc8lezvGIjA1nYChMiMbmxqMAz+RZ2c87ryCi/36CLT0JVL+ 1xd5gCne+UnCG8W9zQUcGYDb8X8HVANnkbuk65kjsBqXkTjbsp2T6qX+VSw9ovJD OzYBD7G3l9qRLNJVvHlUhu0Qg/qMAMVJF3GS46Va1F8dKhfH1egV5eVXQLVPQi1d Qv85hMmeCPEB2yT5irSFfOsHwhZ00ftQzQe8z0e2yntvQFviPRo7/Tzlbavnem17 mr3DkHwwSpQyIjbRwjBkilzKjAcJg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddthedghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufgr mhcuhghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrg htthgvrhhnpeevheefkefghfdtvddvffeuvdevjeetfeetheevudduvdetuefhvdeiiedu geefieenucffohhmrghinhepohifrghsphdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9259D1460062; Wed, 4 Nov 2020 08:10:06 -0500 (EST) 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: <8406b49c-714e-4b03-9dee-2d43e9804006@www.fastmail.com> In-Reply-To: <50594cb1-1827-814f-1dfa-28a8d9449ce7@isode.com> References: <50594cb1-1827-814f-1dfa-28a8d9449ce7@isode.com> Date: Wed, 04 Nov 2020 08:09:46 -0500 From: "Sam Whited" To: "Alexey Melnikov" Cc: "KITTEN Working Group" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] Comments 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: Wed, 04 Nov 2020 13:10:11 -0000 On Tue, Nov 3, 2020, at 09:56, Alexey Melnikov wrote: > Can you describe in more details what the last quoted sentence means f= or=20 > a server SCRAM implementation?=20 Yes, thanks, I've earmarked this for an update to be clear about how you= apply a pepper. In KDFs that don't handle salts themselves, appending t= he pepper to your own salt is enough. In KDFs that automatically create = a salt, you'd want to append it to the password. Basically use peppers e= xactly the same way you'd use a salt. > Sorry, I might have missed this discussion, but I am curious to know=20= > where this number came from. (And a note to myself: I should update=20= > SCRAM-SHA-512 draft to match). I took it from OWASP (https://cheatsheetseries.owasp.org/cheatsheets/Pas= sword_Storage_Cheat_Sheet.html#pbkdf2), I believe NIST uses the same num= ber. =E2=80=94Sam From nobody Wed Nov 4 05:51:42 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 ACBE53A127A for ; Wed, 4 Nov 2020 05:51:40 -0800 (PST) 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=F32SNiQi; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=X0hfS4EN 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 SsVbvBLyHS-S for ; Wed, 4 Nov 2020 05:51:39 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A6DD3A1272 for ; Wed, 4 Nov 2020 05:51:39 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id C29BAA97 for ; Wed, 4 Nov 2020 08:51:38 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Wed, 04 Nov 2020 08:51:38 -0500 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=joCW7 qUlRQfVnacitamPU024HSKa5h3sEQobHfjOTdA=; b=F32SNiQi/ELGh5KNLTzIw kgRsSRa3hg/H1Rg8XSok65Xdzx9G1zOgbYReJDq5yM9yPFdZuk++ykFnz+AyVdDa n8jTy22EE0huuzC7seAomv5KXYgbH/5V4LdpUu3rTK8DAcdsjoLdHDgEJQvr4Sgc Zz6iyA72xkqCiwDr9mkmUfKM1YVAXqToOIjPC8XEz/Fz9YMlSdQr1kJ3Sc7x+sZH JNxj/ch7/8XLAOeDrmpyVhBOv8SCrtnIxO1NcJ44XzdaJMoCCQSaQ2thI/1pFUbI dCyZ1vfMq3KUIKag6J34su/7bxzxEb/yXUGgucKgGW8EsQh4dmn+1s6ifNSevnV6 g== 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=joCW7qUlRQfVnacitamPU024HSKa5h3sEQobHfjOT dA=; b=X0hfS4ENFBQlcM0GMfANNGZsbO3hhNNV7UXpZ6WKbLlFeKDZvvHVt4WPV 3aKOMULAzbL1iWgPBWh6fdDcgRbTSNB8RdRa69YE9Dac2LSIJiP/CMXoGvoBJ7Bz H/s9ZOAy6y1pV2N6bGoymUb1cIOhPIhLevUUjO/UzmUNaeIX+IY8QkvYTOeZYJmu 77fzVVQnxdUqd2oNVsmHv+m5ptB0V2C7QwzdY2L3sZORwWr8a1ghLztF6uJwM3Pb AtYcNav6BdaVbhcCE4FTwxyznnkBBq5Fbg3n4Ms/YTphdy2iPTP9rLa9p6S67huo 2ibuIOcOzO5bgKP4L0dpm/F2pep8w== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddthedgheelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufgr mhcuhghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrg htthgvrhhnpedvffeuvdduhfefvdeiheeukeffhfekjeevgffggedtlefhhffhieevkedu vefhjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 07BCB1460062; Wed, 4 Nov 2020 08:51:37 -0500 (EST) 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: <8406b49c-714e-4b03-9dee-2d43e9804006@www.fastmail.com> References: <50594cb1-1827-814f-1dfa-28a8d9449ce7@isode.com> <8406b49c-714e-4b03-9dee-2d43e9804006@www.fastmail.com> Date: Wed, 04 Nov 2020 08:51:17 -0500 From: "Sam Whited" To: "KITTEN Working Group" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] Comments 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: Wed, 04 Nov 2020 13:51:41 -0000 Actually, I'll just mention that it gets appended to the password. Since= the salt isn't secret (and some algorithms append it to the output hash in plaintext), you should never append your pepper to your salt. Let's not mix secrets with things that aren't secret and might be leaked. =E2=80=94Sam On Wed, Nov 4, 2020, at 08:09, Sam Whited wrote: > Yes, thanks, I've earmarked this for an update to be clear about how > you apply a pepper. In KDFs that don't handle salts themselves, > appending the pepper to your own salt is enough. In KDFs that > automatically create a salt, you'd want to append it to the password. > Basically use peppers exactly the same way you'd use a salt. From nobody Wed Nov 4 06:40:04 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 2BFD43A0AD3 for ; Wed, 4 Nov 2020 06:40:03 -0800 (PST) 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 gcdC40C8sM0P for ; Wed, 4 Nov 2020 06:40:00 -0800 (PST) Received: from mail.zash.se (ip3-20.bon.riksnet.se [77.110.10.20]) (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 A5ED43A03FC for ; Wed, 4 Nov 2020 06:39:59 -0800 (PST) Received: from localhost (localhost [::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mail.zash.se (Postfix) with ESMTPSA id B451C6E2C4F; Wed, 4 Nov 2020 15:39:54 +0100 (CET) Date: Wed, 4 Nov 2020 15:39:45 +0100 From: Kim Alvefur To: Sam Whited Cc: Alexey Melnikov , KITTEN Working Group Message-ID: <20201104143945.fcs4pbatucouiwe2@carcharodon.zash.se> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="qo4yhvmbpovxbovh" Content-Disposition: inline In-Reply-To: <8406b49c-714e-4b03-9dee-2d43e9804006@www.fastmail.com> User-Agent: NeoMutt/20180716 Archived-At: Subject: Re: [kitten] Comments 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: Wed, 04 Nov 2020 14:40:03 -0000 --qo4yhvmbpovxbovh Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Nov 04, 2020 at 08:09:46AM -0500, Sam Whited wrote: >On Tue, Nov 3, 2020, at 09:56, Alexey Melnikov wrote: > > Can you describe in more details what the last quoted sentence means > > for a server SCRAM implementation? > > Yes, thanks, I've earmarked this for an update to be clear about how > you apply a pepper. In KDFs that don't handle salts themselves, > appending the pepper to your own salt is enough. In KDFs that > automatically create a salt, you'd want to append it to the password. > Basically use peppers exactly the same way you'd use a salt. On Wed, Nov 04, 2020 at 08:51:17AM -0500, Sam Whited wrote: > Actually, I'll just mention that it gets appended to the password. > Since the salt isn't secret (and some algorithms append it to the > output hash in plaintext), you should never append your pepper to your > salt. Let's not mix secrets with things that aren't secret and might > be leaked. I don't see how pepper makes sense in SCRAM. There is no slot for it in the protocol and the bits that go into the key derivation function must be known by the client as well as the server, so I don't see how it can be kept a secret. --=20 Regards, Kim "Zash" Alvefur --qo4yhvmbpovxbovh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEPlIRnvhTxZZ4279rre2ad7Z60ykFAl+ivTEACgkQre2ad7Z6 0yndyA//RFke05KaxJWwsXBXRZvFmsbSIeAiCjEsQqE3YLz9uy5fTHc30q9y9UjD KlkKDUyHpK7Ockx4Hm6LdjRPVFbRmUf9+SbNu7bGksF1SLoO+VePctUDhFl3UR2X +IEBcoRgPVAsz0kuEx8VrFO7d2UgTUFJYc4MclIsMIVt0frfkygYyZ+fmDKsXUd0 U5Xc2utSdZEd4XQ7nU+dluxh8FqGDctnUWzNv4lcNHhN/wmqGJBtzPbKetZxqnqq b2BGT1bm4h600zl0ADi6YO60g+OMu6yT3Bw4tooFhLYbMlrf9Fwhtp/sXVu6xxdh fQJxcJXx7PVWqKpdsyTSjqXjVgANR3HAaUFTHSVQa+0tgal4pAjS+9pnhCpA6L4f XKrv7FqaxBo/rq6ZvA7MqHB1nIi1CSH26MKV1R1mOvnlWD7+N434IC7E+1IGe3dC v+6oKzo0ktZ1XL4SH9dRMU53BqxpS5v+2RrgqBrS5VU7VvtVqjpb0kzJdXLieCXf 9Akxp4Vb+Zv5zUStKX6T+ZgiYO/Zsjh10YEyzLBOn+5TDq3a6JVA2ZROfsTci1PL BAaXmgBSOBBAOMab3QktDA2XRyKJvmNYA06SsSith7gRW8csD9Pm7p3HgXFSIAc3 JRezEaOsLXyWxIwObOJIXTKedCwronuBRPpQtozR33Am/VKFjkc= =r5Xn -----END PGP SIGNATURE----- --qo4yhvmbpovxbovh-- From nobody Wed Nov 4 06:44:16 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 8A50E3A12B9 for ; Wed, 4 Nov 2020 06:44:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, 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 (1024-bit key) header.d=isode.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 zDheujj5QmxQ for ; Wed, 4 Nov 2020 06:44:13 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id D36963A12AF for ; Wed, 4 Nov 2020 06:44:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1604501051; d=isode.com; s=june2016; i=@isode.com; bh=2JkTF+KsDiCc4bVFVVA/fmhgnD4XVhN+dmR4i1Firh4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=jcY/hoclqCbI85baLfasQVe0J7mbdsvKRc1fAbFDJ6EPx2uPSYMDSeiB1wUpajWlz4zQme ir/XndjBY4m6Vd0VGEh8y+9T3RXtnntZh3m3/Ue5VP06eJE4jAMbCgQivt7bnMdpGNCPSn w/qmngaldIgb560CE4bpdqtMdBHbVRk=; Received: from [172.27.252.25] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Wed, 4 Nov 2020 14:44:11 +0000 To: Kim Alvefur , Sam Whited Cc: KITTEN Working Group References: <20201104143945.fcs4pbatucouiwe2@carcharodon.zash.se> From: Alexey Melnikov Message-ID: Date: Wed, 4 Nov 2020 14:43:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 In-Reply-To: <20201104143945.fcs4pbatucouiwe2@carcharodon.zash.se> MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [kitten] Comments 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: Wed, 04 Nov 2020 14:44:15 -0000 On 04/11/2020 14:39, Kim Alvefur wrote: > On Wed, Nov 04, 2020 at 08:09:46AM -0500, Sam Whited wrote: >> On Tue, Nov 3, 2020, at 09:56, Alexey Melnikov wrote: >> > Can you describe in more details what the last quoted sentence means >> > for a server SCRAM implementation? >> >> Yes, thanks, I've earmarked this for an update to be clear about how >> you apply a pepper. In KDFs that don't handle salts themselves, >> appending the pepper to your own salt is enough. In KDFs that >> automatically create a salt, you'd want to append it to the password. >> Basically use peppers exactly the same way you'd use a salt. > > On Wed, Nov 04, 2020 at 08:51:17AM -0500, Sam Whited wrote: >> Actually, I'll just mention that it gets appended to the password. >> Since the salt isn't secret (and some algorithms append it to the >> output hash in plaintext), you should never append your pepper to your >> salt. Let's not mix secrets with things that aren't secret and might >> be leaked. > > I don't see how pepper makes sense in SCRAM. There is no slot for it in > the protocol and the bits that go into the key derivation function must > be known by the client as well as the server, so I don't see how it can > be kept a secret. Right. If it is combined with salt, SCRAM client needs to be notified of the combined value. From nobody Wed Nov 4 08:25:58 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 61ED53A0DA4 for ; Wed, 4 Nov 2020 08:25:56 -0800 (PST) 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=bLbWiKV2; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Ec95oHT4 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 hWYIwqAz8UFP for ; Wed, 4 Nov 2020 08:25:55 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2316B3A0D8B for ; Wed, 4 Nov 2020 08:25:55 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 4F67FAED; Wed, 4 Nov 2020 11:25:54 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Wed, 04 Nov 2020 11:25:54 -0500 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=ak MZpw8qdRJ3FeKL+rTRIuJVi/JJ8sWqhhEM3Q7/Hns=; b=bLbWiKV2qWVGlG6xiM Quf3hsXtk4E5Dztryy+/j1pjpFN0VK6YGPceJ2qTGGWysz3wgAsfWMHwkAhAor/g 7sGi/RFI/n4sEERWI0X5fQW5U5ZNzqjSOt+rVt61fJN00mRjG0OKD3nm/6O2Wufu RZU4m4JJwv2qJOZQqkpspoZcwTMNK+785zCzYugF8fB67FruGULHOWX78iAALtT+ Uz+l7KfYrYacQiskoQ0M/tySgr45SmSs4rTaYsOIDXS8CMw1gLtyki2tefLLJqnY n2c+NXSYdf+n8XmS3v0vEewT75yZCTPLXQkz7Kmzf/whbPpJoUIyIN8abiXXOzE3 yGfw== 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=akMZpw8qdRJ3FeKL+rTRIuJVi/JJ8sWqhhEM3Q7/H ns=; b=Ec95oHT4g/Bp1jsJsJq45Ejo0DSRrm9yvKSW0Th77bGTeSNiKtvhs4ery xaRh7ux3NyqdE5jCOxSLnDnXFdO4B+LFf+GxcfqRayAJewFF3hWuT8Rc2jBqZBk3 befPc5Tz8KFCk1aT7rk8SgYbDFO5pcAiNA34NxuNLDSq5mND7xNmXfyHQj0HPNkO KEm++4ZtpxsbjT9rkNGZaudghmRk8NbNnnOELDDR8bD1Kj9B1c3B4ul3Mspy1qQy hBfGtTRlYgvc3c4HFG0l/aVHTC2xKr9EhM+c9V7wiFzjqOX7s81MaqJ85W4DCY5N ACI9Hs6ABRj+cNNP9MUx9IpbfPJ/g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddthedgkeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufgr mhcuhghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrg htthgvrhhnpedvffeuvdduhfefvdeiheeukeffhfekjeevgffggedtlefhhffhieevkedu vefhjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 175371460062; Wed, 4 Nov 2020 11:25:53 -0500 (EST) 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: <20201104143945.fcs4pbatucouiwe2@carcharodon.zash.se> References: <20201104143945.fcs4pbatucouiwe2@carcharodon.zash.se> Date: Wed, 04 Nov 2020 11:25:32 -0500 From: "Sam Whited" To: "Kim Alvefur" Cc: "Alexey Melnikov" , "KITTEN Working Group" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] Comments 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: Wed, 04 Nov 2020 16:25:56 -0000 I'll clarify that as well; you're right that it doesn't make sense with SCRAM, only for eg. PLAIN with a strong KDF used on the server. Note that this along with the lack of agility is one of the reasons I'm always hesitant to recommend SCRAM to people. This is something I'd be curious to get this groups take on: I generally think that a MITM is not= likely how your password will be stolen, therefore SCRAM is of little value since it makes agility harder in case a weakness is discovered in the KDF or the implementation, it makes it harder to use a pepper (though peppers are arguably of limited value too), etc. Figuring out that balancing act is tough though, and I'm not sure which is more or less likely to result in compromise in a real world attack. =E2=80=94Sam On Wed, Nov 4, 2020, at 09:39, Kim Alvefur wrote: > On Wed, Nov 04, 2020 at 08:09:46AM -0500, Sam Whited wrote: > >On Tue, Nov 3, 2020, at 09:56, Alexey Melnikov wrote: > > > Can you describe in more details what the last quoted sentence > > > means for a server SCRAM implementation? > > > > Yes, thanks, I've earmarked this for an update to be clear about > > how you apply a pepper. In KDFs that don't handle salts > > themselves, appending the pepper to your own salt is enough. In > > KDFs that automatically create a salt, you'd want to append it to > > the password. Basically use peppers exactly the same way you'd use > > a salt. > > On Wed, Nov 04, 2020 at 08:51:17AM -0500, Sam Whited wrote: > > Actually, I'll just mention that it gets appended to the password. > > Since the salt isn't secret (and some algorithms append it to the > > output hash in plaintext), you should never append your pepper to > > your salt. Let's not mix secrets with things that aren't secret and > > might be leaked. > > I don't see how pepper makes sense in SCRAM. There is no slot for it > in the protocol and the bits that go into the key derivation function > must be known by the client as well as the server, so I don't see how > it can be kept a secret. > > -- > Regards, Kim "Zash" Alvefur > > Attachments: > * signature.asc --=20 Sam Whited From nobody Wed Nov 4 10:03:33 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 24CCE3A0EDB; Wed, 4 Nov 2020 10:03:32 -0800 (PST) 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 uQBth9xsPKTo; Wed, 4 Nov 2020 10:03:30 -0800 (PST) Received: from NAM04-BN3-obe.outbound.protection.outlook.com (mail-oln040092009082.outbound.protection.outlook.com [40.92.9.82]) (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 A66273A0E50; Wed, 4 Nov 2020 10:03:09 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LfFsg5rLBKAfeXWJIJHorRspBx/n2mJshlGhsEo45wDNJJr77+v3d1rpsEla8LNrkCxfgiw7xDnQiwJ1EY2w7XDaNPOdoe2DnvuT7/le7HDi7PGFxvXA5Dh3y2RnB9UfWRnii+57oS1AljvaEqafgK/ydySIluXIYnO5WJVxw9k/ZMOnmYU9XlX2Rs4IsXkSDOX8q2Ph9BSgvPC1+omBchJsv1J0Xmww3nKXTi6JbuSidd826efNdRWbksq9Xd9DDR2Dez6Jha4tO+3kYaM8/edvM7PZOH8uMIp4baP3sQslllgkDiL4bNKfAroQ269siQZP1U7G1DXNhqhtqcnAMA== 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=efyCk8b7dDEbrKmew3DcmulaHFB+dmuQ6P9kjRycFjo=; b=V/vD5lfVa715d0edKKL6NscgR7qDMskSQyYUSHvjLPfPmepBkEejM4oeNg4SoORTJehif7o1Yp+dIbdZW1AEfra6z6FCdKs/hyIKTOBzViW58dRAQram3tQhvJBkK4ik+JpnqOawxrNCGF44qhZjstLg8HQjUlkeylwC8tgjLx5l4sYXehrwnQAV/lVIhFFIEvEqWuHFv9CDFPg6AIyLsdVtP32iyDFdsUHwGYYonrMuzoQ9XZWRdkAdtPc0MVZ/SxEEpcPCBCJzT/0laGrGfitwkH8TPpQQbFHZilX2K+Wm6yh0s2lINDtkKEcZe8mXFBSrZXNJAYG2mDmUkPbV2Q== 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=efyCk8b7dDEbrKmew3DcmulaHFB+dmuQ6P9kjRycFjo=; b=eqL3vCXUqBWAKfdoAMUNIl1pQJTUUAUEQ5ffI07gq178k1VqBXNZea/dDMIPmhsSpsE4PvU2+xeYPwuGaILkyNtF/U2tjgjGoaHcaV4pMfbU1FRc3myVBFzT1LR74mj/W8Upa7vChQAXjIJiA2b4j9F45fAKYBZTv50DhPp0ZgyrcLEnQ1MOUC+PPipbYQdvtAOJKybbub8bdpapmUwU9IFokEUM9jPYapLM+T4L5huoIGa6Md3/zJt43QmRsZ+7f1SSv8ZK9WfAi39LUmgjRkZC8EvhE5wk57ZZnXHkWhySo0gj4pjoA8BUr/pvRHuCfjzGUYZy5D4XwHuEKyLitg== Received: from BN8NAM04FT039.eop-NAM04.prod.protection.outlook.com (2a01:111:e400:7e85::41) by BN8NAM04HT209.eop-NAM04.prod.protection.outlook.com (2a01:111:e400:7e85::308) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.21; Wed, 4 Nov 2020 18:03:06 +0000 Received: from DM5PR14MB1308.namprd14.prod.outlook.com (2a01:111:e400:7e85::41) by BN8NAM04FT039.mail.protection.outlook.com (2a01:111:e400:7e85::164) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3520.17 via Frontend Transport; Wed, 4 Nov 2020 18:03:06 +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.032; Wed, 4 Nov 2020 18:03:06 +0000 From: Ludovic BOCQUET To: Sam Whited , Alexey Melnikov , Robbie Harwood , Jim Fenton , KITTEN Working Group CC: "draft-ietf-kitten-password-storage@ietf.org" Thread-Topic: [kitten] Comments on draft-ietf-kitten-password-storage-00 Thread-Index: AQHWgx8GB467h9kG20m5bHwptIPHSal0/TqAgDqFl7SAACFxgIAHMG2AgAF7oQCAACWCkA== Importance: high X-Priority: 1 Date: Wed, 4 Nov 2020 18:03:06 +0000 Message-ID: References: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net> <099cf65d-5a57-4e64-93cd-8504aa3bb97d@www.fastmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:8A6344BB6B58EDC3C9D47DA71BDD440ABBF6328B64C77F05EABB969F4DD50605; UpperCasedChecksum:1B5C6F5915B17B3315920D54B5CA06B9B11A03CA3FB98C75383A30BDDD39A79A; SizeAsReceived:7417; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [grFDEqGvwus0CmKplt++sRbfrD/lTvHN] x-ms-publictraffictype: Email x-incomingheadercount: 47 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: d787cf00-e5a3-4fd4-7884-08d880ebe182 x-ms-traffictypediagnostic: BN8NAM04HT209: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: QoSnFFL1HZPYdjFSWs1QjgJRWipXpPUhAMii2p7IZhu4HxltNiNODL/LJK0QSDgfFGFiwlRS5KdicL5W9fGhZ9qKOOOO55c5v5y3j+9iUi6Vn1RWQs/Jge2JrgQJzmWsRzA0WwLNpBlBWwYcu+F7yKKQwehCTxVkwrtz5lnMocR1X3B1OmSCmAcFGJOBQNocesivwT3KcSGKngqMgeg3xtbc6CRrIZFeOb4pgyOIvjJxk3EA52eFLITHz9Y6q7IH x-ms-exchange-antispam-messagedata: bC5KmmMzqL0H0HfLfBdVZbckTIjZYs6Vve3cH5/RMKrKrHfOtfqPEnz93P/j+f2U8jqYopMSB8jq0m39DEj+p2EsSHIqX2VMxAT5c1XtpKTk6bsQbxnj47t5mDCmQDgxY2K9Uk5HS8/KGDtjnFLjHQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM5PR14MB13088072C2B2970C804FFBE6B8EF0DM5PR14MB1308namp_" MIME-Version: 1.0 X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: BN8NAM04FT039.eop-NAM04.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: d787cf00-e5a3-4fd4-7884-08d880ebe182 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Nov 2020 18:03:06.1199 (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: BN8NAM04HT209 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: Wed, 04 Nov 2020 18:03:32 -0000 --_000_DM5PR14MB13088072C2B2970C804FFBE6B8EF0DM5PR14MB1308namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello all, After my comments that I have done some months ago about the bad SCRAM orde= r, my relaunch in this public list and after the reply of Alexey Melnikov (= Author of several RFCs: https://datatracker.ietf.org/person/alexey%20melnik= ov), thanks to Sam for finally listening to me. Do not forget to add in the next version of "draft-ietf-kitten-password-sto= rage" Internet-Draft: * SCRAM-SHA3-512-PLUS * SCRAM-SHA-512-PLUS * SCRAM-SHA3-512 * SCRAM-SHA-512 To have: * SCRAM-SHA3-512-PLUS * SCRAM-SHA-512-PLUS * SCRAM-SHA-256-PLUS * SCRAM-SHA-1-PLUS * SCRAM-SHA3-512 * SCRAM-SHA-512 * SCRAM-SHA-256 * SCRAM-SHA-1 Note: The final "draft-ietf-kitten-password-storage" must be validated like= a RFC after the next two I-Ds, it is really important. Linked to: * https://tools.ietf.org/html/draft-melnikov-scram-sha3-512 * https://tools.ietf.org/html/draft-melnikov-scram-sha-512 It is not linked to IETF, but in the same time, do not forget to update the= XEP-0438 with my comments too: * https://xmpp.org/extensions/xep-0438.html Thanks in advance. Regards, BOCQUET Ludovic ________________________________ From: Sam Whited Sent: Wednesday, November 4, 2020 1:06 PM To: Alexey Melnikov ; Ludovic BOCQUET ; Robbie Harwood ; Jim Fenton ; KITTEN Working Group Cc: draft-ietf-kitten-password-storage@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00 Responses inline. TL;DR I agree. On Tue, Nov 3, 2020, at 09:27, Alexey Melnikov wrote: > That I agree with. So maybe the following ordering: > > SCRAM-SHA-256-PLUS > SCRAM-SHA-1-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1 That seems fine to me, I'll update in the next version. > Fixing channel binding for TLS 1.3 is something that we need to do > anyway. But this is a separate discussion. See also https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bin= dings-for-tls13/, I'd love your feedback there too. =97Sam --_000_DM5PR14MB13088072C2B2970C804FFBE6B8EF0DM5PR14MB1308namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Hello all,
Linked to:

It is not linked to IETF, but in the same time, do not = forget to update the XEP-0438 with my comments too:

Thanks in advance.

Regards,

BOCQUET Ludovic

From: Sam Whited <sam@= samwhited.com>
Sent: Wednesday, November 4, 2020 1:06 PM
To: Alexey Melnikov <alexey.melnikov@isode.com>; Ludovic BOCQU= ET <lbxmpp@live.com>; Robbie Harwood <rharwood@redhat.com>; Jim= Fenton <fenton@bluepopcorn.net>; KITTEN Working Group <kitten@iet= f.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
 
Responses inline. TL;DR I agree.

On Tue, Nov 3, 2020, at 09:27, Alexey Melnikov wrote:
> That I agree with. So maybe the following ordering:
>
> SCRAM-SHA-256-PLUS
> SCRAM-SHA-1-PLUS
> SCRAM-SHA-256
> SCRAM-SHA-1

That seems fine to me, I'll update in the next version.

> Fixing channel binding for TLS 1.3 is something that we need to do > anyway. But this is a separate discussion.

See also https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for= -tls13/, I'd love your feedback there too.

=97Sam
--_000_DM5PR14MB13088072C2B2970C804FFBE6B8EF0DM5PR14MB1308namp_-- From nobody Wed Nov 4 11:07:14 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 68A893A0F7F; Wed, 4 Nov 2020 11:07:13 -0800 (PST) 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=sj9KyeW9; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=KGs+GBXv 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 y1bli3bn5Pjv; Wed, 4 Nov 2020 11:07:12 -0800 (PST) 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 34DA83A0F74; Wed, 4 Nov 2020 11:07:12 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 7E8DD5C018A; Wed, 4 Nov 2020 14:07:11 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Wed, 04 Nov 2020 14:07:11 -0500 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=J7 VRGZLALjTWCwF5l/d4QlIfFFroI/b6iwJPoq7IJvs=; b=sj9KyeW9a6wGFBOws4 yilqnITjMyQJTYEmbA6mYSKJ+zKq+T3Ne0Z5xd9iKpjfTAyY3Kfv/mzyh41wda+B YQREUUph0ekyjJK5DAZxqCogAhxhoMeJR8hSTaT3QMeosNS3N3hrnGT+ndQEX3uM 1p/LNGFMANvSMjMGGIMcvjcnkZpZk2qW5JVjFi79hL1UI+o7mwxWiOB1eQegIEIK V7TDZqDC/2JXqXwtmABeLjFeu8uTlLvQUUYJw/wHSGz0BWtkf068Z1dDdR6eqoaZ yATOP1C0QsKtAXO/08FiIIHkx2aC6o0dPP61Lq4yOmqjoPHznZffvFCDG2L7Hpuy rsIQ== 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=J7VRGZLALjTWCwF5l/d4QlIfFFroI/b6iwJPoq7IJ vs=; b=KGs+GBXvDYBllgOJnS7e9Wxu3OSuQSgakJE/ISh3Er9zp9xGMNZUvJgeO /5pQLcgCK2QPllVugPwWFNrzKhzEspNqUsjizP2TDlM3VFY5ytCFPBA+pKQ+thoa PoTL8vcdKJ776HDJV2exF7pDPZQrP0EKt16TMw3IQOCkmf/QzG8/0u3sf5PcDdUe LrxIhfnAwpL0mlANF2r31IGz2xHLk5GmwrPMV7l2Y2ZdAzQpDoHLugX89rTYRjJk kBhAXdMukRtH0GFUZmMWdIKgoAnrZPd27tevOlZPYVFQ+qoymSqMoq6GHo+ioJ5m lo2R0dNipUQY8aMEFUjaPvtpHY/nQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddthedguddvvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfu rghmucghhhhithgvugdfuceoshgrmhesshgrmhifhhhithgvugdrtghomheqnecuggftrf grthhtvghrnhepvdffuedvudfhfedvieehueekfffhkeejvefggfegtdelhffhhfeiveek udevhfejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epshgrmhesshgrmhifhhhithgvugdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 4D9271460063; Wed, 4 Nov 2020 14:07:09 -0500 (EST) 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: References: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net> <099cf65d-5a57-4e64-93cd-8504aa3bb97d@www.fastmail.com> Date: Wed, 04 Nov 2020 14:06:49 -0500 From: "Sam Whited" To: "Ludovic BOCQUET" , "Alexey Melnikov" , "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: Wed, 04 Nov 2020 19:07:13 -0000 On Wed, Nov 4, 2020, at 13:03, Ludovic BOCQUET wrote: > thanks to Sam for finally listening to me. My apologies if I misunderstood, I thought you were advocating for: * SCRAM-SHA-256-PLUS * SCRAM-SHA-256 * SCRAM-SHA-1-PLUS * SCRAM-SHA-1 Which is not what we're going with for now. I did like the idea of separating the -PLUS mechanisms out into two levels though to indicate that even if SHA-1 is just as secure right now, it is likely in the process of being deprecated as Alexey suggested. > Do not forget to add in the next version of "draft-ietf-kitten-passwor= d- > storage" Internet-Draft: > * SCRAM-SHA3-512-PLUS =E2=80=A6 As discussed, I do not currently plan on doing this. Let's wait and see how those I-Ds develop first. =E2=80=94Sam From nobody Wed Nov 4 11:58:19 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 C2AC93A0639 for ; Wed, 4 Nov 2020 11:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.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, 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 (1024-bit key) header.d=bluepopcorn.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 7OTw3asmg5v8 for ; Wed, 4 Nov 2020 11:58:16 -0800 (PST) Received: from v2.bluepopcorn.net (v2.bluepopcorn.net [IPv6:2607:f2f8:a994::2]) (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 5ECFF3A09C1 for ; Wed, 4 Nov 2020 11:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=bluepopcorn.net; s=supersize; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Sender :Reply-To: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=Xq2igc0yFRGu1vtsRgQuK4X/ZRs48ggoINruXCNAoQw=; b=vDbNI8iFaLCKCURbfwXSbVsqTr Agt5EqoR8qDHAi6dl8F84xItFE88U4Y3bFlikLAQECi0Dc+N6kNDuLK8cUKz7XlBzI7MnTJOFfltC hmfYevWJAK8/Jdv9p7Ev1GQgUKhtbgY7XRNP2drkb1JFKpaik2ZVdBkN2hlNqU0TiVVk=; Received: from [2601:647:4400:1261:3033:b19d:c882:5b0c] (helo=[10.10.20.144]) by v2.bluepopcorn.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kaOv7-0003i3-Mu; Wed, 04 Nov 2020 11:58:15 -0800 From: "Jim Fenton" To: kitten@ietf.org Date: Wed, 04 Nov 2020 11:58:13 -0800 X-Mailer: MailMate (1.13.2r5673) Message-ID: <0F43B360-13CB-4473-8BB2-ABEF1BBB6000@bluepopcorn.net> In-Reply-To: <1765727465.185643.1604451270638@email.ionos.com> References: <50594cb1-1827-814f-1dfa-28a8d9449ce7@isode.com> <1765727465.185643.1604451270638@email.ionos.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [kitten] Comments 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: Wed, 04 Nov 2020 19:58:18 -0000 T24gMyBOb3YgMjAyMCwgYXQgMTY6NTQsIHN0ZXZlQHRvYnR1LmNvbSB3cm90ZToKCj4+IE9uIDEx LzAzLzIwMjAgODo1NiBBTSBBbGV4ZXkgTWVsbmlrb3YgPGFsZXhleS5tZWxuaWtvdkBpc29kZS5j b20+IAo+PiB3cm90ZToKPj4KPj4+IDUuMy7CoCBQQktERjIKPj4+Cj4+PiDCoMKgIFBCS0RGMiBb UkZDODAxOF0gaXMgdXNlZCBieSB0aGUgU0NSQU0gW1JGQzU4MDJdIGZhbWlseSBvZiBTQVNMCj4+ PiDCoMKgIG1lY2hhbmlzbXMuCj4+Pgo+Pj4gKz09PT09PT09PT09PT09PT09PT09PT09PT09PT09 Kz09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0rCj4+PiDCoMKgwqAgfMKgwqDCoMKg wqDCoMKgwqDCoCBQYXJhbWV0ZXLCoMKgwqDCoMKgwqDCoMKgwqAgfCAKPj4+IFZhbHVlwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8Cj4+PiArPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT0rPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSsKPj4+IMKgwqDCoCB8IE1pbmlt dW0gaXRlcmF0aW9uIGNvdW50IChjKSB8IAo+Pj4gMTAsMDAwwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCB8Cj4+Cj4+IFNvcnJ5LCBJIG1pZ2h0IGhh dmUgbWlzc2VkIHRoaXMgZGlzY3Vzc2lvbiwgYnV0IEkgYW0gY3VyaW91cyB0byBrbm93Cj4+IHdo ZXJlIHRoaXMgbnVtYmVyIGNhbWUgZnJvbS4gKEFuZCBhIG5vdGUgdG8gbXlzZWxmOiBJIHNob3Vs ZCB1cGRhdGUKPj4gU0NSQU0tU0hBLTUxMiBkcmFmdCB0byBtYXRjaCkuCj4KPiBOSVNUIGN1cnJl bnRseSBzYXlzIGF0IGxlYXN0IDEwLDAwMCBhbmQgZXZlcnlvbmUgY29waWVkIGl0IGZyb20gdGhl bS4gCj4gSXQgd2FzIGNoYW5nZWQgZnJvbSAxLDAwMCBpbiAyMDAwIHRvIDEwLDAwMCBpbiAyMDE2 IAo+IChodHRwczovL3dlYi5hcmNoaXZlLm9yZy93ZWIvMjAxNjA2MjQwMzMwMjQvaHR0cHM6Ly9w YWdlcy5uaXN0Lmdvdi84MDAtNjMtMy9zcDgwMC02M2IuaHRtbCNtZW1vcml6ZWQtc2VjcmV0LXZl cmlmaWVycykuCgpJdCB3b3VsZCBiZSBiZXR0ZXIgdG8gZmluZCBhIHdheSBub3QgdG8gc3BlY2lm eSB0aGUgd29yayBmYWN0b3JzIGF0IGFsbCwgCnNpbmNlIHRoZXkgY2hhbmdlIGFzIHByb2Nlc3Nv cnMgZ2V0IGZhc3RlciBhbmQgUkZDcyBhcmUgbmV2ZXIgcmV2aXNlZC4gCk9uIHRoZSBvdGhlciBo YW5kLCBOSVNUIFNwZWNpYWwgUHVibGljYXRpb24gODAwLTYzIGlzIHJldmlzZWQgZnJvbSB0aW1l IAp0byB0aW1lLCBhbmQgaXMgY3VycmVudGx5IGluIHRoZSBlYXJseSBzdGFnZXMgb2YgaXRzIG5l eHQgcmV2aXNpb24uIApJdOKAmXMgdG9vIGVhcmx5IHRvIGtub3cgd2hldGhlciB0aGF0IGl0ZXJh dGlvbiBjb3VudCB3aWxsIGJlIGluY3JlYXNlZC4KCi1KaW0K From nobody Wed Nov 4 12:48:19 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 ACA913A0E5B; Wed, 4 Nov 2020 12:48:16 -0800 (PST) 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=Ta/9o9ZR; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=HZMjlotd 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 nbFD5f6GqkDV; Wed, 4 Nov 2020 12:48:15 -0800 (PST) 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 395613A0DEF; Wed, 4 Nov 2020 12:48:15 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 6FC1F5C010F; Wed, 4 Nov 2020 15:48:14 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Wed, 04 Nov 2020 15:48:14 -0500 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; s=fm1; bh=W6vBbSxrcXYhQwL5R0G/kD5cVGsA +BggqypBje1iq5U=; b=Ta/9o9ZRC5nYZxECXrzTD3U5pz4RVKjqttqnqAGIn5nT 7GVpo77Jjv90pbZUJ/sQxWnYA6bHkONd23cQ1T2p16IpCgw06xMJUVvGT7021E9p 815/qdWFIkHDh0mfzDJHg2SNCjbgDgD+YxCPh19Qt0RfC0+41L/js7yHstHLNqbc 26eUSrsgMhN7+LXtInAajdmSAOHMWYiz96oLxI7Mxq/Ieb9WcGRzXFeZDtJPTS4R VY0i1eCpvlHRbk8zH8EfE2AW/qQGULrZGNxf24We0HpFiI4eXu+gE788RWCTs0b5 T+i19MOuqyOv4rG0Cv2ZZM8ECRPaH6TGXJx7ePQC0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=W6vBbS xrcXYhQwL5R0G/kD5cVGsA+BggqypBje1iq5U=; b=HZMjlotdYcUFKY+mnhBcfI pAkSHJ5kX/6ISiIlfpdyJAxlVj0u8pNchijkNcQyIEs7wDYEBSVAFmx1o9bTz9tb 7BtII6wcjKz3FgJrZl5zpEL1HosPDkN1qxDk+rkI2ZN6v5oaap7VC8MD1qQE3sgM 37AY7VN+x9llD6RVrwOj6gKYI/dae7M1tItcB/mNpnvbl0AcYolTOQP9p4Oi89ak Jk+DJnRbg9Z4F/zIyrxHn2RxSXUh6HBj4DkSXRFFhbvmebdF5mVRUAx5YGSYjzag R9FiC8Thc+W79fd9mgEcpasVinHv//SKZ6n5OrJr4ltcLxEVZWxmjbKlUeznsOKg == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedruddthedgudegfecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtsehttdertderredtnecuhfhrohhmpedfufgr mhcuhghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrg htthgvrhhnpedtledvvddvffejueeitdeuffetkeeugfekgeeuvdehheeuvdelgedtieff gfelffenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 7121D1460062; Wed, 4 Nov 2020 15:48:13 -0500 (EST) 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: References: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net> <099cf65d-5a57-4e64-93cd-8504aa3bb97d@www.fastmail.com> Date: Wed, 04 Nov 2020 15:47:53 -0500 From: "Sam Whited" To: "Ludovic BOCQUET" , "Alexey Melnikov" , "Robbie Harwood" , "Jim Fenton" , "KITTEN Working Group" Cc: "draft-ietf-kitten-password-storage@ietf.org" 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: Wed, 04 Nov 2020 20:48:17 -0000 Following up on this after our conversation out-of-band since I apparently misunderstood this sentence: On Wed, Nov 4, 2020, at 13:03, Ludovic BOCQUET wrote: > Note: The final "draft-ietf-kitten-password-storage" must be validated > like a RFC after the next two I-Ds, it is really important. I appreciate your confidence and desire to see this published as an RFC, but I don't think we can set such an aggressive timeline on it. I'll be the first to complain about working with the IETFs obtuse process (someone was kind enough to sit me down and walk me through the whole thing on video chat and I still have no idea how any of it works or what my role as an author is, the tools are impossible to use, the format is impossible to write, etc.), but picking an arbitrary number of drafts before advancing a document with a lot of subtle bits that need expert review doesn't seem like a good idea to me. Sorry, I'd love to see it advance too, but I'm not sure it's ready quite yet. We have plenty of time to see what happens with the other SCRAM I-D first. If one document or the other looks like it's ready to advance, we can reevaluate this position before doing so. Don't worry, if the new SCRAM mechanisms look like they're going to work out, we'll get them in there! Although I haven't heard many other opinions; if waiting on linking the other SCRAM I-Ds seems too conservative I'd love to be told I'm wrong by more seasoned IETF folks. Thanks, Sam From nobody Wed Nov 4 13:40:27 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 BD0AA3A0FB6 for ; Wed, 4 Nov 2020 13:40:25 -0800 (PST) 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_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 ry_MJ3h5TKQn for ; Wed, 4 Nov 2020 13:40:24 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 ED6C13A0B86 for ; Wed, 4 Nov 2020 13:40:23 -0800 (PST) Received: from oxusgaltgw06.schlund.de ([10.72.72.52]) by mrelay.perfora.net (mreueus004 [74.208.5.2]) with ESMTPSA (Nemesis) id 1MTisb-1kmL8g1suD-00U4HP; Wed, 04 Nov 2020 22:40:19 +0100 Date: Wed, 4 Nov 2020 15:40:18 -0600 (CST) From: steve@tobtu.com To: Jim Fenton , kitten@ietf.org Message-ID: <1468490635.21204.1604526018119@email.ionos.com> In-Reply-To: <0F43B360-13CB-4473-8BB2-ABEF1BBB6000@bluepopcorn.net> References: <50594cb1-1827-814f-1dfa-28a8d9449ce7@isode.com> <1765727465.185643.1604451270638@email.ionos.com> <0F43B360-13CB-4473-8BB2-ABEF1BBB6000@bluepopcorn.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Priority: 3 Importance: Normal X-Mailer: Open-Xchange Mailer v7.10.3-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:50M8M+KCtQK7Fl2ysa2wMwOCCdlCI8VQyvpBB9pxdLSML/iyHJ4 vxOQu+R95pNgFCMFDsti3PdiXI/KE/FbR7BTPYltvQeX8TjNcs8Pq46LzH750Ri8TsPMa0A ci9N6cHHsdKtYGo/X4NUdlysPFUq1cVsB+tNeK9O7oYfPxH4QKVs/Z3ipyJVHsuarM/FTAp EoTgLY9ua2cWnty2sEhlg== X-UI-Out-Filterresults: notjunk:1;V03:K0:c4XkW4LTGIc=:zomgWVadeHl+4bijuTUFuL n/v7s3kjnLBcxiKtJAoFC9rt2ehqPYm7JGXYL9Xi9fQqwcU0lExULTbCa8ysc3tlyHVhuVvTj INOAevxSiYQPJR/USulgwsV1TG7JeN199q3vk/o0xUXu5qUx3Vq8T3qSi99mcfyiWgfo2equV 9sxJ81joSKsEF4KYKjZ3IKnOW9A8ZmjbwEwI+R0P4i6UITtuqNbrc4VyJde2prF4wrVQOkiBM qb7Y/RejAbxQNewhwb9mrUCewPKeI/+RApEvTM/sSlU8ux98AfNeE/PZU4FAvUaEEFd+G+LVU PmBfEUWgcsz3MevJdp32kbcZDFGGUQCWvstmdnp89t/yLDX5UISb29QFmfWFbkbdgT05vTMcw +JRxMxYXqyCdKv5K/9VarlZm/7RENQmdgT1KwMp3wi6VWco90WyvNiAqqB1ou Archived-At: Subject: Re: [kitten] Comments 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: Wed, 04 Nov 2020 21:40:26 -0000 > On 11/04/2020 1:58 PM Jim Fenton wrote: >=20 > =20 > On 3 Nov 2020, at 16:54, steve@tobtu.com wrote: >=20 > >> On 11/03/2020 8:56 AM Alexey Melnikov =20 > >> wrote: > >> > >>> 5.3.=C2=A0 PBKDF2 > >>> > >>> =C2=A0=C2=A0 PBKDF2 [RFC8018] is used by the SCRAM [RFC5802] family o= f SASL > >>> =C2=A0=C2=A0 mechanisms. > >>> > >>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > >>> =C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0 Parameter=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=20 > >>> Value=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 | > >>> +=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D+=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D+ > >>> =C2=A0=C2=A0=C2=A0 | Minimum iteration count (c) |=20 > >>> 10,000=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0 | > >> > >> Sorry, I might have missed this discussion, but I am curious to know > >> where this number came from. (And a note to myself: I should update > >> SCRAM-SHA-512 draft to match). > > > > NIST currently says at least 10,000 and everyone copied it from them.= =20 > > It was changed from 1,000 in 2000 to 10,000 in 2016=20 > > (https://web.archive.org/web/20160624033024/https://pages.nist.gov/800-= 63-3/sp800-63b.html#memorized-secret-verifiers). >=20 > It would be better to find a way not to specify the work factors at all,= =20 > since they change as processors get faster and RFCs are never revised.=20 There is, see "[kitten] Password KDF settings on draft-ietf-kitten-password= -storage-01". Basically you limit the attacker's speed to at most 10 kH/s/G= PU. GPU is a current high end GPU running whatever software runs the fastes= t. That's currently RTX 3080 and Hashcat. > On the other hand, NIST Special Publication 800-63 is revised from time= =20 > to time, and is currently in the early stages of its next revision.=20 > It=E2=80=99s too early to know whether that iteration count will be incre= ased. Note that when CUDA (2007) and OpenCL (2009) came out it 10x the speed of p= assword cracking. So ignoring any speed ups in computing since 2000 we shou= ld be at 10,000 iterations just because GPUs exist. Long story short, minim= ums for <10 kH/s on an RTX 3080: PBKDF2-HMAC-SHA1: 720,000 PBKDF2-HMAC-SHA256: 310,000 PBKDF2-HMAC-SHA512: 120,000 P.S. Here's a brief history of which GPU is the one you should benchmark ag= ainst and when it came out: R9 290X: October 24, 2013 * Somewhere around here Nvidia's GPUs became better than AMD's * GTX 980: September 18, 2014 GTX 980 Ti: June 1, 2015 GTX 1080: May 27, 2016 GTX 1080 Ti: March 5, 2017 RTX 2080: September 20, 2018 RTX 2080 Super: July 23, 2019 RTX 3080: September 17, 2020 I think there was a year where the new card was worse than the old card due= to thermal throttling. I think it was the successor of the R9 290X in June= 2015, R9 Fury X. Maybe in 2014 it was still the R9 290X. From nobody Thu Nov 5 03:50:10 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 5A1193A1785; Thu, 5 Nov 2020 03:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.346 X-Spam-Level: X-Spam-Status: No, score=-2.346 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, NICE_REPLY_A=-0.247, 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 (1024-bit key) header.d=isode.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 SJsuvPJ8zYQN; Thu, 5 Nov 2020 03:50:07 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id 80F303A1774; Thu, 5 Nov 2020 03:50:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1604577006; d=isode.com; s=june2016; i=@isode.com; bh=XsPicT90+L9H6qXnZfsu3s31i8+f32FwJvfbce49HD4=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=fg/H0ukyQIY0PAFChY3G6ATiNyhXPxBUDmn5sWa556cay42q8p2MsD77fP7MYeST0+TEyg 6oKCAilEmmd86NIw0PBF1/dEivMiEGVYlU8mKc9giyspdhuaI+91fpCOjweHvE9QdBvqun KaQWkepBzj2jFsuQlL/zxy5hriKEg1Y=; Received: from [192.168.1.222] (host5-81-100-6.range5-81.btcentralplus.com [5.81.100.6]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 5 Nov 2020 11:50:06 +0000 To: Sam Whited , Ludovic BOCQUET , Robbie Harwood , Jim Fenton , KITTEN Working Group Cc: "draft-ietf-kitten-password-storage@ietf.org" References: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net> <099cf65d-5a57-4e64-93cd-8504aa3bb97d@www.fastmail.com> From: Alexey Melnikov Message-ID: <490efb3f-23d2-a467-27be-45dd664ddb84@isode.com> Date: Thu, 5 Nov 2020 11:49:43 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB 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, 05 Nov 2020 11:50:09 -0000 Hi Sam, On 04/11/2020 20:47, Sam Whited wrote: > Following up on this after our conversation out-of-band since I > apparently misunderstood this sentence: > > On Wed, Nov 4, 2020, at 13:03, Ludovic BOCQUET wrote: >> Note: The final "draft-ietf-kitten-password-storage" must be validated >> like a RFC after the next two I-Ds, it is really important. > I appreciate your confidence and desire to see this published as an RFC, > but I don't think we can set such an aggressive timeline on it. > > I'll be the first to complain about working with the IETFs obtuse > process (someone was kind enough to sit me down and walk me through the > whole thing on video chat and I still have no idea how any of it works > or what my role as an author is, the tools are impossible to use, the > format is impossible to write, etc.), but picking an arbitrary number of > drafts before advancing a document with a lot of subtle bits that need > expert review doesn't seem like a good idea to me. > > Sorry, I'd love to see it advance too, but I'm not sure it's ready > quite yet. We have plenty of time to see what happens with the other > SCRAM I-D first. If one document or the other looks like it's ready to > advance, we can reevaluate this position before doing so. Don't worry, > if the new SCRAM mechanisms look like they're going to work out, we'll > get them in there! I am Ok with you not including SCRAM-SHA-512, etc until these documents are approved for publication or at least adopted by the Kitten WG. As far as the IETF process is concerned, if you include a normative reference to it in your draft now, your document couldn't be published as an RFC until after all normative references are published as RFCs. > Although I haven't heard many other opinions; if waiting on linking the > other SCRAM I-Ds seems too conservative I'd love to be told I'm wrong by > more seasoned IETF folks. > > Thanks, > Sam From nobody Wed Nov 18 09:24:38 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 AED6E3A0CE5 for ; Wed, 18 Nov 2020 09:24:37 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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_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 (1024-bit key) header.d=redhat.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 YNNJvDKfIDXh for ; Wed, 18 Nov 2020 09:24:35 -0800 (PST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905D13A0AF6 for ; Wed, 18 Nov 2020 09:24:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605720274; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=scX9TQ9l186XiE1VTn69cwOby5j0v3bBXx+mYoaHorY=; b=RC1f0VlJpKu/3CXslqYXB22ka3OfCGzbDYD2TQWrPS7vRGmLDpB0f6Aq2TXcyivaTJ5aqV w/6ZVHOIJZ6mOgzJ14CAsyp0xGMrqRSpoEzK3RdNX/5OmajuLU0bR3q+WuKTs+t5KRDkM5 MRmJVp/f7IiLaPb2NCOFoTN3sC47Tug= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-532-TjbYYrzkPhmz8JIUuEmrAQ-1; Wed, 18 Nov 2020 12:24:30 -0500 X-MC-Unique: TjbYYrzkPhmz8JIUuEmrAQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id EA91964159; Wed, 18 Nov 2020 17:24:28 +0000 (UTC) Received: from localhost (unknown [10.10.110.61]) by smtp.corp.redhat.com (Postfix) with ESMTP id A8BB21964A; Wed, 18 Nov 2020 17:24:28 +0000 (UTC) From: Robbie Harwood To: saag@ietf.org Cc: kitten@ietf.org Date: Wed, 18 Nov 2020 12:24:26 -0500 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=rharwood@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [kitten] Kitten WG report 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: Wed, 18 Nov 2020 17:24:38 -0000 --=-=-= Content-Type: text/plain kitten did not meet. Work continues on password-storage https://datatracker.ietf.org/doc/draft-ietf-kitten-password-storage/ We are currently looking for an editor to address AD feedback for sasl-saml-ec: https://datatracker.ietf.org/doc/draft-ietf-kitten-sasl-saml-ec/ tls-chanel-bindings continues to be a priority and we will try to increase focus on it and gss-sanon going forward: https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/ https://datatracker.ietf.org/doc/draft-ietf-kitten-gss-sanon/ Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAl+1WMoACgkQJTL5F2qV pEJbKw/9EMhUKd24tSaiArnHCEy39+DWwILylFKF0tQt4RolWoNzbVTOOt6RcIvI lzJd6ZE5Jy1kdP2sWQ3nVrR0n1nHPcJX7ugr9LErI8ARzt++z4xVTXgLEam5Vg4b yVHWcBDBt8P+hpg+GG9J0eGFnVYzl8IVbPPCJyL9pZTtJXm4vORwjMgKcfd58SKn VsEMUFMYlObFMn+VsGcRIPVa9Wpabe+uU6usmYemCG/1TdjGZTbVxUu0YwcCbo3N DqgXxA9VgQQzX0dPhgdQO7dbQdfmrXQbmjqZOXwtFXHeSeKpsruz8PW8kO//OTuW +lu/OLk7RnB6HoTLIXai6vJU5/RbhCKsyodA6x0ASlHvB1Jm6ZqeI4qeYtNKakya B1O2WQ6wqSbjrqZHCx/0SDQTwyjyItrK/JwWsOf5g19k5kWC5jJnCH4OB5qAwDGn 0b1PiaIonlRlm0OvBbxOg4edlW/uDQULEPqm2Tt2JCFlWBnH0zfNC7mW1sGvjGA2 tEPS7CJZbVtSmCeToflVfUB5NTEANV2KD6oysD/xYJFzjlNRwB3fsbhCnL2zHnLo TytkkqBNRUvs2PBFBQh+xQrA3CN854Gn+uW34qA8MpRf2sx9MkFTxJcHEYaOrknh DdYTRRvp5CvncRkzsQEDfwffKf5RtLXSxBHcw7a85LEfYAOioOY= =NCGj -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 18 11:49:20 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 80F683A0B23 for ; Wed, 18 Nov 2020 11:49:18 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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_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 (1024-bit key) header.d=redhat.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 6oemArkKivWa for ; Wed, 18 Nov 2020 11:49:16 -0800 (PST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93CD73A0B1C for ; Wed, 18 Nov 2020 11:49:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605728955; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type; bh=OgOWrX8CB5ZopsqUh8+67ERcAxVk1MOSLWV4VK0IyKc=; b=i3PhxNJICuA7aI5m1E8+WMJMvN7y7xTdz+ummKhc4EWABzWZ1vMcUxNoeGrt6If7IQeAd7 zys3tGNd3c9tExU82QsAtRWdSoxt9tSXzW3HbuuQBB5tUF8mlS0oyTuW0tgq349GNT8s1s tNA5+tlJs1hLkYrlcnfx4CKoZL43n8I= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-5-zho744a6PguMpk7QAmNPMQ-1; Wed, 18 Nov 2020 14:49:08 -0500 X-MC-Unique: zho744a6PguMpk7QAmNPMQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 71CF11015C84 for ; Wed, 18 Nov 2020 19:49:07 +0000 (UTC) Received: from localhost (unknown [10.10.110.61]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3369E19728 for ; Wed, 18 Nov 2020 19:49:06 +0000 (UTC) From: Robbie Harwood To: kitten@ietf.org Date: Wed, 18 Nov 2020 14:49:02 -0500 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=rharwood@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [kitten] Comments on draft-tls-channel-bindings-for-tls13 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: Wed, 18 Nov 2020 19:49:19 -0000 --=-=-= Content-Type: text/plain (This is a review of https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/ version -00.) First: thanks for putting this together. I have a couple comments, but nothing about the document seems immediately wrongheaded to me. In "1. Introduction": > After problems were found with the channel binding types defined in > [RFC5929] they were not defined for TLS 1.3 (see [RFC8446] section > 7.5). This document doesn't seem to address what the problems with the previous channel binding types were. It also doesn't appear in the referenced section (i.e., RFC 8446 section 7.5 doesn't seem to have this information; moreover, that section doesn't reference RFC 5929). RFC 8446 section C.5 does call out cbs as a protection mechanism, but merely notes that they're not implemented for 1.3, so it's probably not a case of wrong section. I think it would be good to explain what the problems were by way of background in the introduction. In "2. The 'tls-exporter' Channel Binding Type": > IANA will register the 'tls-exporter' channel binding type to match the > description below. This feels redundant with the formal IANA considerations section later in the document. I think it would be more helpful to orient it toward explaining the cb type as pertains to RFC 5705 and RFC 8446. > When TLS renegotiation is enabled channel binding using the "tls-exporter" > type is not define and MUST NOT be supported. Hmm, this text is a bit awkward right now. I suggest something like: When TLS renegotiation is enabled, implementations MUST NOT support channel binding using the "tls-exporter" type as it is not defined. In "3. Security Considerations": > While it is possible to use this channel binding mechanism with TLS versions > below 1.3 Curious - is there a practical reason to want this CB type with TLS <= 1.2? Please also see the idnits here: https://www6.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-kitten-tls-channel-bindings-for-tls13-00.txt For completeness, they are: > ** The abstract seems to contain references ([RFC5056], [RFC8446]), > which it shouldn't. Please replace those with straight textual > mentions of the documents in question. > > == The 'Updates: ' line in the draft header should list only the > _numbers_ of the RFCs which will be updated by this document (if > approved); it should not include the word 'RFC' in the list. > > -- The document date (December 2020) is 27 days in the future. Is > this intentional? Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAl+1eq4ACgkQJTL5F2qV pEJl4xAAqQKu3U3ZHUKIMR9nEVPHOsfiQqBhCBVpUzfDccyhWNHNW02mWFRDmg6Y XqE10hPFYZKETpjTzT1PC5u3NilZo7TqLdS0U7OL/Z06vUDioTTYY8HlQi/yVG2E uZdS6OllCNu08sYPXmAy8od8hDceBAphWrNQSf8PfY6dH/xoawTYV2Yz7RIyOvyf ZnS9cEIfvAgA9kBqgU7klyRWjjPYu79uPQzl7WRMNvZgM7AJJBGgOuWhrnK5RO7N 5DIddnWiTIH3JWalnYvX43clQJ/nTa9jY43MYyj53u98GoobOYXUr3zudsoo9h1w iXUKw0XfTh9FQoQRkQkRgpdznSlXq32hBHOXo5XJR6xYx7eVaIWKQuRBRwuYFKQW dZrL0J/6HlCODs0BOU6CC6LAL/dMihiZbWR+NM65yd/e38uonoHH4BmybhN5MZp8 DwNqkuiJ9Yz924BITkoDc5RV1cYOoxGX98D3dXb0eoxmqtiQf4YAagbjdvXyPNal WoLJJSsn+jVQyXk4bjRYdOm+3mClX4j0B7VX0fv8x3AWAhx9J26+U0+EH+o07D8q IQeJw2ePtud/MGGLg/gXBiYQeZp2xTUOKdy7DIY+lNAA15f2MRX/hpHOgWMsRiK0 FnfdFjka/Mv75vAejK+t5Azg6ZxYj4aq9pqKLAltVyHR3LeJ5oE= =AsgC -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 18 18:41:56 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 390253A0A20 for ; Wed, 18 Nov 2020 18:41:55 -0800 (PST) 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=T6OaMq5i; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=SfTT5TxC 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 d8p--4_ckcRv for ; Wed, 18 Nov 2020 18:41:54 -0800 (PST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2EDD3A0A13 for ; Wed, 18 Nov 2020 18:41:53 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id EE7F55C0079 for ; Wed, 18 Nov 2020 21:41:52 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Wed, 18 Nov 2020 21:41:52 -0500 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=UcTJU AMK37eoP7NwrpzDGTcet/plDhVWysn7Z6N//BE=; b=T6OaMq5iiaASBoz01UbEG AlOjcSibkAff6c7TkE58MB+FQlE8FalLhrXVTQ1WPDAoEL4MEP+EQf5aAYTXktHn s5b/OQvCOTVVjGwBxPvitOYnQAUDMknYQHArMGqG2LC4NR1eZrkZ3Zr1wMxj9j6b UK0B0/R+C9ArGNBMx0smpnr7LrtHQfRsOnYGZ8qA56lw8m2bwySdjsEFFtDUvMos G2ECcaJrP1o33UQWDbxK+Pd+OC6RnIY0Sa5Qylk2jqbrI66/ib7JFSNZYkbJ3Ldh 8pLjS76fNSI5l+PLtZTX48yH7x1nq4nD9e1dPRinyeRvNfj8dBP/JMTAWv/VUOM0 A== 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=UcTJUAMK37eoP7NwrpzDGTcet/plDhVWysn7Z6N// BE=; b=SfTT5TxCibAfKK/9IHlrHUR0YKaNWvYHRE3B0/Q1rJ9LMo2QotLXOuKmK i+eA06wLFdvUvcMBEdrWDi/sigl/Ehls8egMSUnOKef0r3bXD23ixo8hOrF1ONt0 gjylNUeENodItokqWLCREiFfyasoZx0axDJFj1tK8T74/rXQ1Cq2t7iWIHFUjoQn IeVsxwr2bcy8MFRYYTJQpbTmIgo1GZw6ALjXv+zNpaVBbsVu7NbPmh/gflkOhI7H alwimutHylaYcx0+aTcUDLCrjIhrnSggo1IH8Av6HhPCR946SM3xgA+j41HfOOZL 8Hg7oJEWW/jDgQtpGUPMRFcqFLi3g== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefiedggeelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufgr mhcuhghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrg htthgvrhhnpedvffeuvdduhfefvdeiheeukeffhfekjeevgffggedtlefhhffhieevkedu vefhjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B0BA51460063; Wed, 18 Nov 2020 21:41:52 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 18 Nov 2020 21:41:32 -0500 From: "Sam Whited" To: "KITTEN Working Group" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] Comments on draft-tls-channel-bindings-for-tls13 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, 19 Nov 2020 02:41:55 -0000 Responses inline: On Wed, Nov 18, 2020, at 14:49, Robbie Harwood wrote: > This document doesn't seem to address what the problems with the > previous channel binding types were. I'll add some text here. The TL;DR is that without the extended master secret fix from RFC7627 tls-unique is not actually unique. I also recall= someone suggesting that the unique data really wasn't long enough, which= seems likely, but I don't have a citation for that off the top of my head so I'll stick to mentioning the triple handshake vulnerability and the extended master secret extension and leave it at that. > It also doesn't appear in the referenced section (i.e., RFC 8446 > section 7.5 doesn't seem to have this information; moreover, that > section doesn't reference RFC 5929). > > RFC 8446 section C.5 does call out cbs as a protection mechanism, but > merely notes that they're not implemented for 1.3, so it's probably > not a case of wrong section. That was indeed supposed to be a reference to C.5. That's the only reference I'm aware of for why the two CB mechanisms from 5929 aren't defined in 1.3. This is a very confusing off-the-cuff reference in the TLS 1.3 spec, but it's what I'm basing the entire need for a new CB mechanism on. > In "2. The 'tls-exporter' Channel Binding Type": =E2=80=A6 This feels > redundant with the formal IANA considerations section later in the > document. I think it would be more helpful to orient it toward > explaining the cb type as pertains to RFC 5705 and RFC 8446. I did it this way because RFC5929 did it this way, but I agree it's awkward. I'll rewrite this to be descriptive and give a bit of background on EKM and TLS 1.3 instead. > Hmm, this text is a bit awkward right now. I suggest something like: > > When TLS renegotiation is enabled, implementations MUST NOT > support channel binding using the "tls-exporter" type as it is not= > defined. Sounds good to me; thanks. > Curious - is there a practical reason to want this CB type with TLS <=3D= > 1.2? Not that I can think of. I suppose it would be nice to have a single channel binding type that works regardless of the TLS version being used, but it seems simpler to just let TLS 1.2 die and not worry about it since channel binding isn't widely supported right now anyways. > Please also see the idnits here: Will do, thanks. I'll have a new version up soon. =E2=80=94Sam --=20 Sam Whited From nobody Wed Nov 18 18:47:08 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 EC5703A0A2B; Wed, 18 Nov 2020 18:47:02 -0800 (PST) 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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: kitten@ietf.org Message-ID: <160575402285.29157.16458359440559089744@ietfa.amsl.com> Date: Wed, 18 Nov 2020 18:47:02 -0800 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-tls-channel-bindings-for-tls13-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: Thu, 19 Nov 2020 02:47:03 -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 : Channel Bindings for TLS 1.3 Author : Sam Whited Filename : draft-ietf-kitten-tls-channel-bindings-for-tls13-01.txt Pages : 5 Date : 2020-11-18 Abstract: This document defines a channel binding type, tls-exporter, that is compatible with TLS 1.3 in accordance with RFC 5056, On Channel Binding. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-kitten-tls-channel-bindings-for-tls13-01.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-tls-channel-bindings-for-tls13-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 Nov 19 04:44:59 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 B12453A0D6F for ; Thu, 19 Nov 2020 04:44:57 -0800 (PST) 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=DjrXIqvA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gHv7jfZy 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 BQzcnd-rpsrt for ; Thu, 19 Nov 2020 04:44:56 -0800 (PST) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2974E3A0D81 for ; Thu, 19 Nov 2020 04:44:56 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 558EAEC6 for ; Thu, 19 Nov 2020 07:44:55 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Thu, 19 Nov 2020 07:44:55 -0500 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=SMPhwwpzwvyW7Dzj8EzxinAl2ldIaPj /5V8T7ZFTJzc=; b=DjrXIqvA9O7uoKoWkOh+kB2Z40DQQ7PTpYBEj0aSQiLg2Js zV1Z7DTqGSwuYWCG5UIOcdDDkmKioGYwBU+kafwwyP21AlpHOD8llxtzM8rhg6Qh BigsbjZKA2odKArLDFO7Do8ONxuiN/Etdg+xgp03Sx08Vxz2zIdWKAuPTsbQRoUe yxzxzq+5uVywPF3iYbqW4rxIMwe0wV4iC9bqfU1TuT/YVH0cm6vKVFCTBRYAf6TE bkmAHXfp8/m57jQEUP+whKj12Bq1D3DWPN5utLoscJ/P0ZVOEg4QDEcfsfaKAzcK /plbHjqnpY+fmfi2UlxHNDDO6q6AH6IxEBZw7cg== 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=SMPhww pzwvyW7Dzj8EzxinAl2ldIaPj/5V8T7ZFTJzc=; b=gHv7jfZynVmaROtLEaVP7z A6CFdDFCnwJHFehJNY//oszPCLLc8rmcTkz8l3DlL2alIWCsX0c9bt9kRFP57A7n 2PPr/JRHBurYKNd+8xV9cgL1v7cc25g3iGQxacyB9dJI/DU6myzdhFehTd0nNK6K mxvpNE9du6xGHxiXHIR/Y5B6zSpb66poccvi+Bfq6ca2GJKDrsEzt7OnfD8iKC6m wzHbmo7Gpf0K8j37Q4YTjO+/1B/lhAc0sANuXXEmIGcEfG6zCTE0D9NUBpbnRsJU xhBaiToIE7MDVbLnZMSm7hNP1Fya3iD05gN07N7V70JlnqDwUO74obsrA0GPLPvw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefjedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdfurghm ucghhhhithgvugdfuceoshgrmhesshgrmhifhhhithgvugdrtghomheqnecuggftrfgrth htvghrnhepffetheevvddvueeiuedujeevtddukeevvdekhfduvdejhefggfdttdefgfdt gfeinecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpedtne curfgrrhgrmhepmhgrihhlfhhrohhmpehsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 94C411460062; Thu, 19 Nov 2020 07:44:54 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <26918967-e530-452f-bbda-b325d4d29b52@www.fastmail.com> In-Reply-To: <160575402285.29157.16458359440559089744@ietfa.amsl.com> References: <160575402285.29157.16458359440559089744@ietfa.amsl.com> Date: Thu, 19 Nov 2020 07:44:34 -0500 From: "Sam Whited" To: "KITTEN Working Group" Content-Type: text/plain Archived-At: Subject: Re: [kitten] =?utf-8?q?I-D_Action=3A_draft-ietf-kitten-tls-channel-b?= =?utf-8?q?indings-for-tls13-01=2Etxt?= 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, 19 Nov 2020 12:44:58 -0000 I noticed before submitting this one that I'd added an extra "tls" before the name of the draft somehow (ie. tls-channel-bindings-for-tls not channel-bindings-for-tls), but it won't let me change the filename without resetting the version number. Does it matter, or is there something I should do to fix this? Thanks, Sam On Wed, Nov 18, 2020, at 21:47, internet-drafts@ietf.org wrote: > > 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 : Channel Bindings for TLS 1.3 Author > : Sam Whited Filename : draft-ietf-kitten-tls-channel-bindings-for-tls13- > 01.txt Pages : 5 Date : 2020-11-18 > > Abstract: This document defines a channel binding type, tls- > exporter, that is compatible with TLS 1.3 in accordance with RFC > 5056, On Channel Binding. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-kitten-tls-channel-bindings-for-tls13-01.html > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-tls-channel-bindings-for-tls13-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/ > > > _______________________________________________ > Kitten mailing list Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten > -- Sam Whited From nobody Thu Nov 19 09:36:51 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 6F6C33A0E44 for ; Thu, 19 Nov 2020 09:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, MSGID_FROM_MTA_HEADER=0.001, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H2=-0.001, 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=btconnect.onmicrosoft.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 kwPx8MJIJ-TT for ; Thu, 19 Nov 2020 09:36:48 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140094.outbound.protection.outlook.com [40.107.14.94]) (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 673C93A0E3F for ; Thu, 19 Nov 2020 09:36:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CtZmwcPRL9yRVkSH8nYkN4meFal5HwKGsnwSbympF+X7fkpf9X9Evp0GVhOrOcYoQnIUrhoRInI9pmYlLwXP4SRJ+RsRxgrUIRXjn+0gfESZ4aG6tBmAFIfhTnucch5I/luuvKmJwJbq1t6br61QZoskB8ZVeAYYPrG6PGDJmvsHaiKxqh466sL5ay4o7rmO1fnUsyn1wNa1lOUOaQS+sLgJmZ1YM5IBisVoXuKMfAN7M0MoEk0nQ90A8dZa3qSwMyZLyHXoDqoRW380sh9tOAY73zVAT0KIgpvu9X6ukpYP9CSntUt9mSUjwbWelq3tlKxOXXCvFNJZ1MbLA7XEmA== 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=DjTVUUGxlO20IVaAuRZEx6v66dM7CLeu3td6vedEvP0=; b=DCfV/DvioiEuA0ZHCPFuW5ruSe2JmgpuqAtdZlsm6mLocyGaXml/zlWUKFa79MQDIPdVZhVRTMfrAAOdqUqKkQf1mpbcP3/gtqPGPxEo8ReBmqhiC/4joZJeGCinTyRQ6AADgJcQ6mG5x7py7CIYOKjzFdKZecvH//VIGeF4C0JDDv2C8AUJB7gnrwaYdur5vUtSq0JNljntJP2NoIJ2D0IybADBVr0VKcrMfy1ltzuDenhl4fkFE/zBNt5+Rv530VsTCl2oCDhEBhJgXdSjQJFy8LMOwf9c1XuHA1vUBTI5CpPLwnQpxQitLc3+O8bCID781BJmrr9njus6CINDjg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=btconnect.com; dmarc=pass action=none header.from=btconnect.com; dkim=pass header.d=btconnect.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector2-btconnect-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DjTVUUGxlO20IVaAuRZEx6v66dM7CLeu3td6vedEvP0=; b=AhVo6jD2E3hZSM1vjQPamChsJdPnrnLmlE0r+5Rrzh07PD1oWYorfTPyop5lr9JA1QnGlL70SaHLqLbw43x5KSZhrk1Ki70KQwoBdkqeqQs2d4NZkHN3lkaGpInPw+R6gRWwXnpeqDjS0tunl4FAfarOrdPJ9vVvuu+LXqZrswE= Authentication-Results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=btconnect.com; Received: from VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) by VI1PR07MB4670.eurprd07.prod.outlook.com (2603:10a6:803:72::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3564.14; Thu, 19 Nov 2020 17:36:46 +0000 Received: from VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae]) by VI1PR07MB6704.eurprd07.prod.outlook.com ([fe80::6407:6ea2:f517:eeae%8]) with mapi id 15.20.3589.016; Thu, 19 Nov 2020 17:36:45 +0000 To: Sam Whited , KITTEN Working Group References: <160575402285.29157.16458359440559089744@ietfa.amsl.com> <26918967-e530-452f-bbda-b325d4d29b52@www.fastmail.com> From: tom petch Message-ID: <5FB6AD2A.8010201@btconnect.com> Date: Thu, 19 Nov 2020 17:36:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <26918967-e530-452f-bbda-b325d4d29b52@www.fastmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [86.146.121.140] X-ClientProxiedBy: LO2P265CA0229.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:b::25) To VI1PR07MB6704.eurprd07.prod.outlook.com (2603:10a6:800:18b::8) MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 Received: from [192.168.1.65] (86.146.121.140) by LO2P265CA0229.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:b::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.3589.20 via Frontend Transport; Thu, 19 Nov 2020 17:36:45 +0000 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 0a5e6000-bff4-451d-634c-08d88cb1afa8 X-MS-TrafficTypeDiagnostic: VI1PR07MB4670: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: vFvwP8keu8EFq4IPmCGpNZ7+lLyNdgGvS6UTwQ//+nNzoVacOARsw/FvIx48eBSAs+N9b346XeqA7Ov9REegxLrgiXEHfZnedowZEt3BlUZLZ6WBQdFFCxYT140pjQaV6u/xEjrVgD4QAuwM0mRt6pQ0T1IWSbWFLV4TRdXAXIMxw6O7oVWSB1q3vc4TJsFiFiO4nMM7pKhk4g1hjUObY8E+L6a/AVePyohI4ck09XgXfuEPFhGixkhD1co7/74L7eMc1iJwWJBIhsHnseKG2spq9VOghPAp6Oq9gIYW+g69ZzGWQFIIHaCSpDN4+Ma5ANl1TpWoCSvB3znR2PTxp4wpNxsGQO0KlTO7lqF3shQ1qRSpjwwWV8RNDN4iTyuamO8URKOVdFw/TCIaXzejEg== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:VI1PR07MB6704.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(396003)(136003)(346002)(376002)(366004)(478600001)(16526019)(53546011)(2906002)(316002)(966005)(110136005)(16576012)(33656002)(5660300002)(2616005)(8936002)(6666004)(86362001)(83380400001)(186003)(52116002)(4001150100001)(8676002)(6486002)(26005)(36756003)(87266011)(956004)(66556008)(66574015)(66946007)(66476007); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData: s16KaP4brhzyo3mM0Kq0D3D0PVX1sKkcIS6OlhfrN98AEdZ8oFl0bBhxASRijhhGwB4x2C93dn8tc8JUQIsr1oclmROpI/rQGBzORCrwdJiK05yii+ww7NLrRneIzl321hT9o9Sag+aYFTWqfEJ6yQFPMgEalkHJaUmvEOQqgAuoBHzq7Fq63Lw6SioFFbVgM0JMfMHmlNqLvaqPjyI9lJ+fHDrVs6xB/hn+AuJNlCaOWRqyAUCioKcjtnJpWjEP8tiH1sURvHpgMAX/X4Jk9rN4Cww7UQRw7fAS5eyynpAZMT1VxkV8j0RpD08Sev5S0n/1KiZtvHAgObrVJ0QxH2HlkNrvdtuZkZ6h3r9p/kZzDFJL6pbZhDJ/HTABQJq5xAiKByAEQe9CzDKdmH75pitd1V7e6ONe7ulJfRWVJvjiwVd+w0/m30khqsYCJCzWu7didI+1n3Amevwb9Jqe7vsBVUHW7uIAvtgTDHvtAFzeZmW7gdSTLaCjVKn4EgcTd2rw5XyH692DmyueRLlX2+xCBM9eqCZa9cr4eczHPGwSG/Nt4OWEUrjVuOrL6BTqhX/UdQ1jwey3DSt/e5CRBRx4Q9iWseGy8jQ3jVjxITKEl77dyLaLBKEn88hErTstWzQMCrOoE+n3hlgF4JEF9w== X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a5e6000-bff4-451d-634c-08d88cb1afa8 X-MS-Exchange-CrossTenant-AuthSource: VI1PR07MB6704.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Nov 2020 17:36:45.8686 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: SiAWppdNPIl710hJS1JRq7/+huuhg92xfGFFORP61ayP5nHBQ+RPT5j1MzJUnZ6Lji1ubdx2V5ivE3pd3PVDig== X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB4670 Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-tls-channel-bindings-for-tls13-01.txt 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, 19 Nov 2020 17:36:50 -0000 On 19/11/2020 12:44, Sam Whited wrote: > I noticed before submitting this one that I'd added an extra "tls" > before the name of the draft somehow (ie. tls-channel-bindings-for-tls > not channel-bindings-for-tls), but it won't let me change the filename > without resetting the version number. Does it matter, or is there > something I should do to fix this? Leave well alone! I noticed it and thought how quaint so it is a identifier that will stay in my mind long after this is an RFC:-) The WG chairs can allow the change and can set up a link in the datatracker so that the I-D can be backtracked through name changes but that is a hassle, you have to know that you need to do it and even ADs at AD review can lose sight of what has happened. The I-D name is just a handle, an identifier, which is the reference to use up until the RFC appears, after which it is the RFC number which counts. I think that many people creater overcomplex names trying to encode every aspect of an I-D into a name but you have not done that; channel bindings, tls13, just what I need to know. Tom Petch > Thanks, > Sam > > On Wed, Nov 18, 2020, at 21:47, internet-drafts@ietf.org wrote: >> >> 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 : Channel Bindings for TLS 1.3 Author >> : Sam Whited Filename : draft-ietf-kitten-tls-channel-bindings-for-tls13- >> 01.txt Pages : 5 Date : 2020-11-18 >> >> Abstract: This document defines a channel binding type, tls- >> exporter, that is compatible with TLS 1.3 in accordance with RFC >> 5056, On Channel Binding. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-kitten-tls-channel-bindings-for-tls13/ >> >> There is also an HTML version available at: >> https://www.ietf.org/archive/id/draft-ietf-kitten-tls-channel-bindings-for-tls13-01.html >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-tls-channel-bindings-for-tls13-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/ >> >> >> _______________________________________________ >> Kitten mailing list Kitten@ietf.org >> https://www.ietf.org/mailman/listinfo/kitten >> > From nobody Thu Nov 19 09:38:27 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 4807B3A0CCB for ; Thu, 19 Nov 2020 09:38:25 -0800 (PST) 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, NICE_REPLY_A=-0.001, 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 (1024-bit key) header.d=isode.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 7c0i14wnsA1J for ; Thu, 19 Nov 2020 09:38:24 -0800 (PST) Received: from statler.isode.com (Statler.isode.com [62.232.206.189]) by ietfa.amsl.com (Postfix) with ESMTP id AC0813A0E3F for ; Thu, 19 Nov 2020 09:38:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605807490; d=isode.com; s=june2016; i=@isode.com; bh=WH7/GhtoJMRJdwj/xclfLtPgtnjyOE7/QvitMZrnDlw=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=ZGfIXO1fY7s0ukqHNVOaUQ6LYpu3KL3bsZCbjw8vn962c6kP2WXVbLBHcsl1iR4NVTepTU Iju42mcC3lBPPfJpFxqqCrtCUEJ26rkUbAT84IWzn2cfzF5rc1LiP67mOjOGMptmFwEKbZ lIDiNQh37y6ws8WQnfmV4raAWEqAmDc=; Received: from [172.27.254.224] (connect.isode.net [172.20.0.72]) by statler.isode.com (submission channel) via TCP with ESMTPSA id ; Thu, 19 Nov 2020 17:38:10 +0000 To: tom petch , Sam Whited , KITTEN Working Group References: <160575402285.29157.16458359440559089744@ietfa.amsl.com> <26918967-e530-452f-bbda-b325d4d29b52@www.fastmail.com> <5FB6AD2A.8010201@btconnect.com> From: Alexey Melnikov Message-ID: Date: Thu, 19 Nov 2020 17:37:47 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.2 In-Reply-To: <5FB6AD2A.8010201@btconnect.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-transfer-encoding: quoted-printable Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-tls-channel-bindings-for-tls13-01.txt 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, 19 Nov 2020 17:38:25 -0000 On 19/11/2020 17:36, tom petch wrote: > On 19/11/2020 12:44, Sam Whited wrote: >> I noticed before submitting this one that I'd added an extra "tls" >> before the name of the draft somehow (ie. tls-channel-bindings-for-tls >> not channel-bindings-for-tls), but it won't let me change the filename >> without resetting the version number. Does it matter, or is there >> something I should do to fix this? > > Leave well alone! > > I noticed it and thought how quaint so it is a identifier that will=20 > stay in my mind long after this is an RFC:-) > > The WG chairs can allow the change and can set up a link in the=20 > datatracker so that the I-D can be backtracked through name changes=20 > but that is a hassle, you have to know that you need to do it and even=20 > ADs at AD review can lose sight of what has happened. > > The I-D name is just a handle, an identifier, which is the reference=C2=A0= =20 > to use up until the RFC appears, after which it is the RFC number=20 > which counts. > > I think that many people creater overcomplex names trying to encode=20 > every aspect of an I-D into a name but you have not done that; channel=20 > bindings, tls13, just what I need to know. +1 From nobody Thu Nov 19 09:40:29 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 EDEAF3A0E78 for ; Thu, 19 Nov 2020 09:40:27 -0800 (PST) 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=CUWeAHRJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Z0S+W1sU 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 PszXtBT51DHa for ; Thu, 19 Nov 2020 09:40:27 -0800 (PST) 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 035CD3A0E62 for ; Thu, 19 Nov 2020 09:40:26 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 3C73FAB3; Thu, 19 Nov 2020 12:40:26 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Thu, 19 Nov 2020 12:40:26 -0500 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=jGh5L drPlna0AK51eTo6iAOwjUck/L6GCecI/wb/lV4=; b=CUWeAHRJNaYeknApcq8sp 3lXxQIjkKPEMVPk2yNDLII39yPOltNUZ4RzgzISB3Duwvgpzw2bW4tAMwM1Vkqhz XlRX8PSTFHDj5DSOo5AmbD0KyDQ6th2WZb9VF9R8FjirhL71xjw+2+z2X4CdChgp /aBwz3ql5VrpvQMIZz6UN4kgopgVXnYVPhd5UzMwTY0U9h5jmdznwqD7swxQ73m7 b4wZ32/4RMVrXMQCuYkyCfQGHcX/b2ObncjhOnRSroK7MLtoFp8Kr/rGsfPvPzbl +shSM3+UO3RKubIyjgF6ZyzCmz9iaz2HJcPIfKNteT2Pj3SCQc1jZmtNk8DXfP9D 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=jGh5LdrPlna0AK51eTo6iAOwjUck/L6GCecI/wb/l V4=; b=Z0S+W1sU4/16S9cERfDz+2/3Oefmym4+wJZZXT3T1Y6fXVglYzhBaTSQQ 1DtllY5tjvtRVQWWs8i2Gm4frEV9HhGJ8B6oWIhNykErmcf4Y65iBpQVf4bivVfV AFS1bEMgnsZ3luyl3loib2Vj6HytLcV3fEiFT2VJtV1gnch/pch7WTwz+GR8FY2A e97WhOzi/BN3yrWSH0iq4t/cdKmHMYd+1ygjtCUMYXxBnH6aBC7Ab22c2g4iSO31 cuI6Sk1nEztU8/j3nkdhCmUTsYBGBexN2NS5o4rm5RIxzTXG6DeMHjLHy5Zl9goY v6uP5tH9GyDpfgn5NsWTZ78R0gf0A== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudefjedguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfu rghmucghhhhithgvugdfuceoshgrmhesshgrmhifhhhithgvugdrtghomheqnecuggftrf grthhtvghrnhepvdffuedvudfhfedvieehueekfffhkeejvefggfegtdelhffhhfeiveek udevhfejnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epshgrmhesshgrmhifhhhithgvugdrtghomh X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 5216F1460062; Thu, 19 Nov 2020 12:40:25 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <9f954cfe-2c7d-4c8f-b474-3286bd33e0ae@www.fastmail.com> In-Reply-To: <5FB6AD2A.8010201@btconnect.com> References: <160575402285.29157.16458359440559089744@ietfa.amsl.com> <26918967-e530-452f-bbda-b325d4d29b52@www.fastmail.com> <5FB6AD2A.8010201@btconnect.com> Date: Thu, 19 Nov 2020 12:40:04 -0500 From: "Sam Whited" To: "tom petch" , "KITTEN Working Group" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] =?utf-8?q?I-D_Action=3A_draft-ietf-kitten-tls-channel-b?= =?utf-8?q?indings-for-tls13-01=2Etxt?= 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, 19 Nov 2020 17:40:28 -0000 Sounds good to me; thanks! =E2=80=94Sam On Thu, Nov 19, 2020, at 12:36, tom petch wrote: > Leave well alone! From nobody Fri Nov 20 09:42:43 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 D1F7D3A0C97 for ; Fri, 20 Nov 2020 09:42:40 -0800 (PST) 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, DKIMWL_WL_HIGH=-0.001, 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_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 (1024-bit key) header.d=redhat.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 WRV9lLWodNw7 for ; Fri, 20 Nov 2020 09:42:39 -0800 (PST) Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D57B3A0C93 for ; Fri, 20 Nov 2020 09:42:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1605894158; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Eh9hHiC1pdxZPrnhBZEY7UTWwmcI3lQ9OUEdPCCl/UE=; b=SCbPgGVA8dGj9SRZ70cjwCuBGe7WuumhHtlM1rOGAyReUXZXxXgagy4Hv3LA9h7vdLR3Ka U219whN3uDQERuuNjxjGN8VTK644MHLXXxmArAEt2AsfoXX/jM3gKoOsch3PxMY3ge/oi7 L4gwMTq1LCnwKnIGJAOXRGAnEIww3nc= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-479-ruWav1fmMkOcL7_W0DdBQQ-1; Fri, 20 Nov 2020 12:42:35 -0500 X-MC-Unique: ruWav1fmMkOcL7_W0DdBQQ-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 137848030A2; Fri, 20 Nov 2020 17:42:33 +0000 (UTC) Received: from localhost (unknown [10.10.110.47]) by smtp.corp.redhat.com (Postfix) with ESMTP id F207E5C1D5; Fri, 20 Nov 2020 17:42:31 +0000 (UTC) From: Robbie Harwood To: Sam Whited , KITTEN Working Group In-Reply-To: <26918967-e530-452f-bbda-b325d4d29b52@www.fastmail.com> References: <160575402285.29157.16458359440559089744@ietfa.amsl.com> <26918967-e530-452f-bbda-b325d4d29b52@www.fastmail.com> Date: Fri, 20 Nov 2020 12:42:28 -0500 Message-ID: MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 Authentication-Results: relay.mimecast.com; auth=pass smtp.auth=CUSA124A263 smtp.mailfrom=rharwood@redhat.com X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-tls-channel-bindings-for-tls13-01.txt 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, 20 Nov 2020 17:42:41 -0000 --=-=-= Content-Type: text/plain "Sam Whited" writes: > I noticed before submitting this one that I'd added an extra "tls" > before the name of the draft somehow (ie. tls-channel-bindings-for-tls > not channel-bindings-for-tls), but it won't let me change the filename > without resetting the version number. Does it matter, or is there > something I should do to fix this? It could be fixed if you really wanted, but as others have stated, it's fine. This new version addresses my concerns. I encourage others to take a look and review this document even if it's just to indicate that you think it's ready - the document is not especially long. Thanks, --Robbie --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJIBAEBCgAyFiEEA5qc6hnelQjDaHWqJTL5F2qVpEIFAl+4AAQUHHJoYXJ3b29k QHJlZGhhdC5jb20ACgkQJTL5F2qVpEIAMA/+Lw6IRcFfKJ1DDPSg5gRmuAxq2Tpz LYzMhTFd1aW17SOfemsNum9LmjYHdTxkEN1yIdETZIW4rVFiqfuoqcNjGjZ0hcbq QcrJkMLEjlHRxgsrCD3P+aGz/1udQTQ+NNREpbVZu/yBoP29gbmuccJfCT8mLRVh +Pj4Kn+PQJ40XkstIgcDNJ+0TulXAjbONG/SrrofYTD5SdIVJ3f581AJzolonWFP EkCOH7VANrB5xdO3GROfTgBMKxq/uZLpCec6J9uA99hj5KFUsPv7nWZcyBo6RU/Z ABocJQ420VMY58762aOLjulO+1OcZk0LLbeyQyfkBj5DvZuhQwvMnV0wdvqi7kD7 dezn6eQWYdrJPJ5JNHyTHcxuIN4nLgDkYCUVyqLZFvfy3HnY39BStPjOfVDzV/1Y Y4dGqVVCjJnokGqWm7FIGjgqYOnyhIRK3tyWvQSesJnOtbdsXE+pEvzzLuNQ+SW9 YoIX4dFJdymtiRd9wGQie0xhgkqB4ZdcAuZH4GbEa1j3j3ygAoeb3G5hNb2CJdNZ KJ2OFTJNL3czurJffoXIies+DF8T7J5EBZQ60c5APWyfImdUYb5DiJQSLOr6Iuln 853M2FLS8UpNTGRzE/QUeoXMCboybHwNpXBbx/CnJR0liHVOrfQOFuOZZk2kxLWC TEWfYHi8HjNQOPo= =v/gs -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Nov 20 09:46:26 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 E87293A0C24 for ; Fri, 20 Nov 2020 09:46:25 -0800 (PST) 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, NICE_REPLY_A=-0.001, 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 (1024-bit key) header.d=isode.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 GUdZDiCoysUz for ; Fri, 20 Nov 2020 09:46:21 -0800 (PST) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 4D6813A0BA3 for ; Fri, 20 Nov 2020 09:46:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1605894380; d=isode.com; s=june2016; i=@isode.com; bh=dXy0LYfl0IEfPIBtHDZoIpSc5hrC+C/UUIwDUH0WzdI=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=VJL6KyJoJEnyoEXsvhI28K5VihyBnFIzY5Cp6D92xaNXxYFGGwhVoeN8e1/A12ZAfUrsSq ZvZAHpBPD0I7N41CIidZuMOev5IRcbci9GvJV9PJJ7IkMT/pisaWa6pMZRrHY21YwqGs25 OsFK4HJVMV78MU5n+qaWKxbtgjLmgxk=; Received: from [192.168.0.5] ((unknown) [176.252.130.164]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 20 Nov 2020 17:46:19 +0000 X-SMTP-Protocol-Errors: NORDNS To: Robbie Harwood , Sam Whited References: <160575402285.29157.16458359440559089744@ietfa.amsl.com> <26918967-e530-452f-bbda-b325d4d29b52@www.fastmail.com> Cc: KITTEN Working Group From: Alexey Melnikov Message-ID: <4cc62a81-73cc-f168-f27a-5d8831bf1a56@isode.com> Date: Fri, 20 Nov 2020 17:46:18 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-tls-channel-bindings-for-tls13-01.txt 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, 20 Nov 2020 17:46:26 -0000 On 20/11/2020 17:42, Robbie Harwood wrote: > "Sam Whited" writes: > >> I noticed before submitting this one that I'd added an extra "tls" >> before the name of the draft somehow (ie. tls-channel-bindings-for-tls >> not channel-bindings-for-tls), but it won't let me change the filename >> without resetting the version number. Does it matter, or is there >> something I should do to fix this? > It could be fixed if you really wanted, but as others have stated, it's > fine. > > This new version addresses my concerns. I encourage others to take a > look and review this document even if it's just to indicate that you > think it's ready - the document is not especially long. -01 looks better to me. From nobody Sun Nov 22 04:04:54 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 A21BB3A14AF; Sun, 22 Nov 2020 04:04:52 -0800 (PST) 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 3Syemj9r00BL; Sun, 22 Nov 2020 04:04:50 -0800 (PST) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12olkn2036.outbound.protection.outlook.com [40.92.23.36]) (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 780F03A14AD; Sun, 22 Nov 2020 04:04:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P8Sug/ZZmn+Yi6xodyjHbKrf0G+tIjS4W9t5YzGrQMuqiFV0XXYb3qSHeDhourx2XZnyFfB7Wq+LQpyhSMFG9o4SWUbq6ZO/lXD03oPRlQRZNXVclznjrcUmKGYvJKGdVRGTmeBAXs8uAcoEdW+R40IcirnUEZLsyTOMtmiEDjmTeeRtTf4QZK7v9dOhKmBmJX/ZuxpFXz0x+ZYT90P2+DHTAtViOSQgviP0CI3BAaHnx0TGkAnkCHsmkWl/KxQiGy8tG5gAdboOzMtJsXO2sNXrJpDIuokYcCG8NcgyLnJKG5WiWES+Cv9F4TYh8A8aPAKJFsNtCCjxQseknfAwFA== 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=0jKxfA6ZeQyhTzJQUwrRw1D7Sh/1QDr1cqVKrOI+HyE=; b=kVGvxSuHudzziGc5V4frnBRm5QpKcb8L1KyDKy8+ZcrkZP58QaRi70ryJL8DWA5rh15wZA+M7Jc4NH7eFbVqY8TlU1l3gNnd5u9fIWE0OJfVBGmgfIAOLWRHrStC32mb1JIN9UnmNiIAq2IQYlWBilsW3OtNWQ48IXgB8jUmvCFKLqORvmsTgVW0717V9oeqMawcxnvOWXDVsGd4eYG22pJJxZh4d7QMqYNoLdWOtUp7EYyftjLCkNnwtHQHLZZHBue47jk4H6u7iMSDPVoSQkGkLd80KhVOOAhXO0F9oH3BBB5IPjxn1bqMIUIy4CmjRSv5wByCq2f74Wo+lOc18g== 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=0jKxfA6ZeQyhTzJQUwrRw1D7Sh/1QDr1cqVKrOI+HyE=; b=SU922rDAyziQ/fB2lyDpIMEx517k4kMn4/9qbI5+SkNZJM8lbqkTGBh5f/8gN8vjwpDsxyAtuqrdhydOIkfah16NN3lq57x1E8zz4vys7J2UbcMQQ3u2a7vSmzAg7kqszTFzpXNxGFPIvCj2sXrvBoUy/WCf7gabqDhJDSXb59K3/zH+74ZbVUszOe91aEdm6i7ROGFDU5GLKONFc459j7J/GawvDdBXIAajp2bJKdTYIKgxlckhxKp9lWfN+AvuTR4YthMEnh5uf7CAsda7aD7ELRMZ8ZwvG1wCOwcmH1KqVZqFFKY7oBtjgrfNb765ecN70uKW0j7gkzJLFsWPrg== Received: from MW2NAM12FT013.eop-nam12.prod.protection.outlook.com (2a01:111:e400:fc65::4e) by MW2NAM12HT053.eop-nam12.prod.protection.outlook.com (2a01:111:e400:fc65::205) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.12; Sun, 22 Nov 2020 12:04:48 +0000 Received: from DM5PR14MB1308.namprd14.prod.outlook.com (2a01:111:e400:fc65::43) by MW2NAM12FT013.mail.protection.outlook.com (2a01:111:e400:fc65::80) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.11 via Frontend Transport; Sun, 22 Nov 2020 12:04:48 +0000 Received: from DM5PR14MB1308.namprd14.prod.outlook.com ([fe80::fc62:447d:49e4:71d8]) by DM5PR14MB1308.namprd14.prod.outlook.com ([fe80::fc62:447d:49e4:71d8%8]) with mapi id 15.20.3589.021; Sun, 22 Nov 2020 12:04:48 +0000 From: Ludovic BOCQUET To: Sam Whited , Alexey Melnikov , Robbie Harwood , Jim Fenton , KITTEN Working Group CC: "draft-ietf-kitten-password-storage@ietf.org" Thread-Topic: [kitten] Comments on draft-ietf-kitten-password-storage-00 Thread-Index: AQHWgx8GB467h9kG20m5bHwptIPHSal0/TqAgDqFl7SAACFxgIAHMG2AgAF7oQCAACWCkIAAW3iAgAAao/A= Importance: high X-Priority: 1 Date: Sun, 22 Nov 2020 12:04:48 +0000 Message-ID: References: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net> <099cf65d-5a57-4e64-93cd-8504aa3bb97d@www.fastmail.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:5DF698F50D2BD8D5FB5BA3E44F951CD97E7F84FFB760D5BA9144CF14FEFEE929; UpperCasedChecksum:186032E4AD10D0DF1713C8B9CB2E8015EFB986497E6797822E70C5B0E83A1746; SizeAsReceived:7603; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [MU/Sbnme2if8TESt9Fbf5Wam9jjNlJNs] x-ms-publictraffictype: Email x-incomingheadercount: 47 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 213131dc-ec0f-487c-3025-08d88edecf8a x-ms-traffictypediagnostic: MW2NAM12HT053: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: biANGR4KZeBtrOKDuRe5ZJkKHbBnjCtNw36qgRnvH+sakUei0kQJukEZq/dWiRqS11mt3iLeKFaVu6oBZKak6bKurUUneZl0G9/8bBk0ZJ0FLDrK5NuqxFbfKN1tQZmLousCoJyBWBKzlXGgbJS5Zg9fB+WG6F9mCMKFrdtEvNH1Pnk1U6oZ0bm7oqjx7vfhNYbMzj+EhzJDIGy6iqIaq9SvTpNCx+DLv4qMBDNc1GIR/S/6+APbvZc2e4+GwahN x-ms-exchange-antispam-messagedata: q6nIarXCjzjodmlDd+xAuoHYJ0PK6w+hEAn7a6O+1KOUb5GwDcw0ujE0nGA+Gs4+ipGH8Z+nx5NgngCzp2zoQyn9h0xC0Ed0dv/RwS8zoy0sCA2mbP75b1ZO6xz9dsvDsyTDx68KwwYEganmpumBvA== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM5PR14MB1308CB22AD3043E3BAE644CCB8EF0DM5PR14MB1308namp_" MIME-Version: 1.0 X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: MW2NAM12FT013.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 213131dc-ec0f-487c-3025-08d88edecf8a X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2020 12:04:48.7639 (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: MW2NAM12HT053 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: Sun, 22 Nov 2020 12:04:53 -0000 --_000_DM5PR14MB1308CB22AD3043E3BAE644CCB8EF0DM5PR14MB1308namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello all, After my previous comments, maybe it is not clear to all in this list, sorr= y. Sam and others, I have requested you to have in this "draft-ietf-kitten-pas= sword-storage" I-D: * SCRAM-SHA3-512-PLUS * SCRAM-SHA-512-PLUS * SCRAM-SHA-256-PLUS * SCRAM-SHA-1-PLUS * SCRAM-SHA3-512 * SCRAM-SHA-512 * SCRAM-SHA-256 * SCRAM-SHA-1 And added in "References": * https://tools.ietf.org/html/draft-melnikov-scram-sha3-512 * https://tools.ietf.org/html/draft-melnikov-scram-sha-512 Currently we can see only and with a bad order: * EXTERNAL * SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS * SCRAM-SHA-1, SCRAM-SHA-256 * PLAIN * DIGEST-MD5, CRAM-MD5 The bad order of SCRAM is always here in "-01": "1" before "256" and on one= line. And Alexey Melnikov has confirmed here: * https://mailarchive.ietf.org/arch/msg/kitten/8GglIHO_8kgZtk83D-8XOsZx= uxE/ But Alexey Melnikov has said about SCRAM-SHA-512(-PLUS) and SCRAM-SHA3-512(= -PLUS): "I am Ok with you not including SCRAM-SHA-512, etc until these documents ar= e approved for publication or at least adopted by the Kitten WG. As far as the IETF process is concerned, if you include a normative referen= ce to it in your draft now, your document couldn't be published as an RFC u= ntil after all normative references are published as RFCs." * https://mailarchive.ietf.org/arch/msg/kitten/fqeNdi5-n8_x3zw4NIy7Yi8a= yLo/ Please read my comments after. It is to be ready and I have specified to wait that the 2 I-Ds become 2 RFC= s and after "draft-ietf-kitten-password-storage" I-D can be updated with RF= C links and after this I-D can become an RFC. I would not to see a next I-D to update again. I have never said finalize today or tomorrow. And other parts can be improved. And I think, that it is possible to add a reference to "draft-ietf-kitten-t= ls-channel-bindings-for-tls13" I-D into "draft-ietf-kitten-password-storage= " I-D too. * https://tools.ietf.org/html/draft-ietf-kitten-tls-channel-bindings-fo= r-tls13 In order, steps: 1 - "draft-ietf-kitten-password-storage" I-D can have "draft-ietf-kitten-tl= s-channel-bindings-for-tls13" I-D link 2 - "draft-ietf-kitten-password-storage" I-D can have "draft-melnikov-scram= -sha-512" I-D link 3 - "draft-ietf-kitten-password-storage" I-D can have "draft-melnikov-scram= -sha3-512" I-D link 4 - "draft-ietf-kitten-tls-channel-bindings-for-tls13" I-D become an RFC 5 - "draft-melnikov-scram-sha-512" I-D become an RFC 6 - "draft-melnikov-scram-sha3-512" I-D become an RFC 7 - "draft-ietf-kitten-password-storage" I-D is updated with new links and = your I-D can become an RFC The goal is to do not create a new RFC some days after with forgotten parts= . Note: - "draft-ietf-kitten-tls-channel-bindings-for-tls13" I-D updates or obsolet= es RFC5929 (but it is not specified in header) - "draft-ietf-kitten-password-storage" I-D updates RFC8600 (but it is not s= pecified in header) If we look previous RFCs (there are a lot), we can see in some examples: - In RFC5801: https://tools.ietf.org/html/rfc5801, a link to RFC5802 (relea= sed at the same time: RFC5801/RFC5802/RFC5803) - In RFC5802: https://tools.ietf.org/html/rfc5802, a link to RFC5803 (relea= sed at the same time: RFC5801/RFC5802/RFC5803) - In RFC6120: https://tools.ietf.org/html/rfc6120, a link to RFC6121 and RF= C6122 (released at the same time: RFC6120/RFC6121/RFC6122) - In RFC8446: https://tools.ietf.org/html/rfc8446, a link to draft-ietf-tl= s-tls13-vectors-06 - In RFC7590: https://tools.ietf.org/html/rfc7590, a link to draft-ietf-dan= e-srv-14 + draft-ietf-xmpp-posh-04 + draft-ietf-xmpp-dna-10 1 - We can see it is possible to release several RFCs at the same time, it = is a great organization and a great synchronization. 2 - We can see that it is possible to have draft in a new RFC. We can see that Alexey Melnikov has added my request, there is a draft-ietf= -kitten-tls-channel-bindings-for-tls13 reference in: * https://tools.ietf.org/html/draft-melnikov-scram-sha-512-01 * https://tools.ietf.org/html/draft-melnikov-scram-sha3-512-01 Do not forget that: 1 - CRAM-MD5 to Historic: - https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00 // 20 = November 2008 - https://tools.ietf.org/html/draft-zeilenga-luis140219-crammd5-to-historic= -00 // June 29, 2017 2 - RFC6331: Moving DIGEST-MD5 to Historic: - https://tools.ietf.org/html/rfc6331 // July 2011 Maybe it is time to take them off completely from the list even if they are= after PLAIN. Thanks for reading me. Regards, BOCQUET Ludovic ________________________________ From: Sam Whited Sent: Wednesday, November 4, 2020 8:47 PM To: Ludovic BOCQUET ; Alexey Melnikov ; Robbie Harwood ; Jim Fenton ; KITTEN Working Group Cc: draft-ietf-kitten-password-storage@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00 Following up on this after our conversation out-of-band since I apparently misunderstood this sentence: On Wed, Nov 4, 2020, at 13:03, Ludovic BOCQUET wrote: > Note: The final "draft-ietf-kitten-password-storage" must be validated > like a RFC after the next two I-Ds, it is really important. I appreciate your confidence and desire to see this published as an RFC, but I don't think we can set such an aggressive timeline on it. I'll be the first to complain about working with the IETFs obtuse process (someone was kind enough to sit me down and walk me through the whole thing on video chat and I still have no idea how any of it works or what my role as an author is, the tools are impossible to use, the format is impossible to write, etc.), but picking an arbitrary number of drafts before advancing a document with a lot of subtle bits that need expert review doesn't seem like a good idea to me. Sorry, I'd love to see it advance too, but I'm not sure it's ready quite yet. We have plenty of time to see what happens with the other SCRAM I-D first. If one document or the other looks like it's ready to advance, we can reevaluate this position before doing so. Don't worry, if the new SCRAM mechanisms look like they're going to work out, we'll get them in there! Although I haven't heard many other opinions; if waiting on linking the other SCRAM I-Ds seems too conservative I'd love to be told I'm wrong by more seasoned IETF folks. Thanks, Sam --_000_DM5PR14MB1308CB22AD3043E3BAE644CCB8EF0DM5PR14MB1308namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello all,

After my previous comments, maybe it is not clear to all in this list, sorry.=

Sam and others, I have requested you to have= in this "draft-ietf-kitten-password-storage" I-D:
  • SCRAM-SHA3-512-PLUS
  • SCR= AM-SHA-512-PLUS
  • SCRA= M-SHA-256-PLUS
  • SCRAM-SHA-1-PLUS
  • SCRAM-SHA-512
  • SCRA= M-SHA-256
  • SCRAM-SHA-1
  • EXTERNAL
  • SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS
  • SCRAM-SHA-1, SCRAM-SHA-256
  • PLAIN
  • DIGEST-MD5, CRAM-MD5
The bad ord= er of SCRAM is always here in "-01": "1" before "2= 56" and on one line.

But Alexey Melnikov has said about SCRAM-SHA-512(-PLUS) and SCRAM-S= HA3-512(-PLUS):
"I am Ok with you not including SCRAM-SHA-512, etc unt= il these documents are approved for publication or at least adopted by the = Kitten WG.
As far as the IETF process is concerned, if you include a normative re= ference to it in your draft now, your document couldn't be published as an = RFC until after all normative references are published as RFCs."

It is to be ready and I have specified to= wait that the 2 I-Ds become 2 RFCs and after "draft-ietf-kitten-password-storage" I-D can be updated with RFC links and after this I-D can become an RFC.
I would not to see a next I-D = to update again.

I have never said finalize toda= y or tomorrow.
And other parts can be improve= d.

And I think, that it is possible to add a re= ference to "draft-ietf-kitten-tls-channel-bindings-for-tls13" I-D= into "draft-= ietf-kitten-password-storage" I-D too.

In order, steps:
1 - "draft-ietf-kitten-password-storage= " I-D can have "draft-ietf-kitten-tls-channel-bindings-for-tls13&= quot; I-D link
2 - "draft-ietf-kitten-password-storage&= quot; I-D can have "draft-melnikov-scram-sha-512" I-D link
3 - "draft-ietf-kitten-password-storage&= quot; I-D can have "draft-melnikov-scram-sha3-512" I-D link
4 - "draft-ietf-kitten-tls-channel-bindi= ngs-for-tls13" I-D become an RFC
5 - "draft-melnikov-scram-sha-512" = I-D become an RFC
6 - "draft-melnikov-scram-sha3-512"= I-D become an RFC
7 - "draft-ietf-kitten-password-storage= " I-D is updated with new links and your I-D can become an RFC<= br>
The goal is to do not create a new RFC some = days after with forgotten parts.

Note:
- "draft-ietf-kitten-tls-channel-bindin= gs-for-tls13" I-D updates or obsoletes RFC5929 (but it is not specifie= d in header)
- "draft-ietf-kitten-password-storage&q= uot; I-D updates RFC8600 (but it is not specified in header)

If we look previous RFCs (there are a lot), we can see in some examples:=
- In RFC5801: https://tools.ietf.org/ht= ml/rfc5801, a link to RFC5802 (rele= ased at = ;the same time: RFC5801/RFC= 5802/RFC5803) - In RFC5802: https://tools.ietf.org/html/rfc5= 802, a link to RFC5803 (released at=  the same time: RFC5801/RFC5802/RFC5803)
- In RFC6120: https://tools.ietf.org/html/rfc6120, a link to RFC6121 and RFC6122 (rel= eased at the same time: RFC6120/RFC6121/RFC6122)
- In RFC8446: https://tools.ietf.org/html/rfc8446, a link to  draft-ietf-tl= s-tls13-vectors-06
- In RFC7590: https://tools.ietf.org/ht= ml/rfc7590, a link to draft-ietf-dane-sr= v-14 + draft-ietf-xmpp-posh-04 + draft-ietf-xmpp-dna-10

1 - We can see it is possible to release several RFCs at the same time, it = is a great organization and a great synchronization.
2 - We can see that it is possible to have dr= aft in a new RFC.

We can see that Alexey Melnikov has added my request, there is a draft= -ietf-kitten-tls-channel-bindings-for-tls13 reference in:

Do not forget that:
1 - CRAM-MD5 to Historic:
- https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00 /= / 20 November 2008
- https://tools.ietf.org/html/draft-zeilenga-luis140219-crammd5-to-his= toric-00 // June 29, 2017

2 - RFC6331: Moving DIGEST-MD5 to Historic:
- https://tools.ietf.org/html/rfc6331 // July 2011

Maybe it is time to take them off completely from the list even if the= y are after PLAIN.

Thanks for reading me.

Regards,

BOCQUET Ludovic

From: Sam Whited <sam@= samwhited.com>
Sent: Wednesday, November 4, 2020 8:47 PM
To: Ludovic BOCQUET <lbxmpp@live.com>; Alexey Melnikov <ale= xey.melnikov@isode.com>; Robbie Harwood <rharwood@redhat.com>; Jim= Fenton <fenton@bluepopcorn.net>; KITTEN Working Group <kitten@iet= f.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
 
Following up on this after our conversation out-of= -band since I
apparently misunderstood this sentence:

On Wed, Nov 4, 2020, at 13:03, Ludovic BOCQUET wrote:
> Note: The final "draft-ietf-kitten-password-storage" must be= validated
> like a RFC after the next two I-Ds, it is really important.

I appreciate your confidence and desire to see this published as an RFC, but I don't think we can set such an aggressive timeline on it.

I'll be the first to complain about working with the IETFs obtuse
process (someone was kind enough to sit me down and walk me through the
whole thing on video chat and I still have no idea how any of it works
or what my role as an author is, the tools are impossible to use, the
format is impossible to write, etc.), but picking an arbitrary number of drafts before advancing a document with a lot of subtle bits that need
expert review doesn't seem like a good idea to me.

Sorry, I'd love to see it advance too, but I'm not sure it's ready
quite yet. We have plenty of time to see what happens with the other
SCRAM I-D first. If one document or the other looks like it's ready to
advance, we can reevaluate this position before doing so. Don't worry,
if the new SCRAM mechanisms look like they're going to work out, we'll
get them in there!

Although I haven't heard many other opinions; if waiting on linking the
other SCRAM I-Ds seems too conservative I'd love to be told I'm wrong by more seasoned IETF folks.

Thanks,
Sam
--_000_DM5PR14MB1308CB22AD3043E3BAE644CCB8EF0DM5PR14MB1308namp_-- From nobody Sun Nov 22 12:36:45 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 DCA793A0CEA; Sun, 22 Nov 2020 12:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.22 X-Spam-Level: X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=Rco30FS1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=bc16CqSL 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 ypotWkn-6YX8; Sun, 22 Nov 2020 12:36:41 -0800 (PST) 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 354543A0CE8; Sun, 22 Nov 2020 12:36:41 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 728815C0078; Sun, 22 Nov 2020 15:36:40 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Sun, 22 Nov 2020 15:36:40 -0500 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=Ji 2pdjewR4sA7t3Ck1fa9KgFivbjoAiEVW/qIjRj9tg=; b=Rco30FS1NdZr6yT6FU 8Opc/cCXSsykq3nGvY0XR/y5elhg3PMmMINCB8jaG3bkIR0lhhdD8NIAdokHcb3P 8kiYpnv2XOGUumSMpKqvxIml33oNftd4seoI72vLOt9m9TLGMYABj7W9KkIQhscn 44PCMFy17NIlHB+GIZBcxjTw8vwf145CwWMvY5FtcTSLXRWcKcYFZJZ6apGmvfHR y0mSvOD1D4kpQ4Irz5BbyIIpUqLUcT4J7IDhMip9EDDnuzUakjoXME6xnQ4SImlJ 5FTV/oBTfUcMul1ShkO0V37uEAveFyJzSpUkPnakEwVdiJibhZUvRE06aEclaInl cjYg== 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=Ji2pdjewR4sA7t3Ck1fa9KgFivbjoAiEVW/qIjRj9 tg=; b=bc16CqSL19/z5fFfjRZSMQ9flbhbJqkbbOHQRbzRhbad/iMlZZwGJAdcz t7wRHAm/rjrH5W6Tpnmsit0n3pTD1eVkFC79aTL7k2TJBPBZ4HF/hXTpE8ch9e+z /MSBoMgB95d58jptP0vaHHK0CRTChEyUlZ7yZEXEl9LWo75MDPgNl+7Gdh59K5xV BAkVcR3ZEuzlR1XEwjENzV2uASMll54t0aZ/6QpSjreXqP7KOnOZJpShfnwIaBWI 0JtKiRD7Qy6YDoJGf3l6++xEI6jk2BmgYTY1peQf9aQD24HLbvECrzcV/1s2hxEh xQ9Sj+4OW4cCb7wwEaEXy/G/FlDcQ== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudeggedgudegvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefofgggkfgjfhffhffvufgtgfesthhqredtreerjeenucfhrhhomhepfdfu rghmucghhhhithgvugdfuceoshgrmhesshgrmhifhhhithgvugdrtghomheqnecuggftrf grthhtvghrnhepfeduudekkeeuteeuleefgeeuvdeuvdffhedvveeiffeghefhjefftdev veeuvdffnecuffhomhgrihhnpehivghtfhdrohhrghenucevlhhushhtvghrufhiiigvpe dtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 6B3EA1460063; Sun, 22 Nov 2020 15:36:39 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <8d757904-4f41-4981-90fe-e94b6039d00b@www.fastmail.com> In-Reply-To: References: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net> <099cf65d-5a57-4e64-93cd-8504aa3bb97d@www.fastmail.com> Date: Sun, 22 Nov 2020 20:36:10 +0000 From: "Sam Whited" To: "Ludovic BOCQUET" , "Alexey Melnikov" , "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: Sun, 22 Nov 2020 20:36:43 -0000 On Sun, Nov 22, 2020, at 12:04, Ludovic BOCQUET wrote: > After my previous comments, maybe it is not clear to all in this > list, sorry. I apologize for the confusion, but I am still not sure what you are advocating for in this email. It appeared that you want the order that Alexey suggested, which I already said I would update in the next draft.= It also appears that you're asking again for me to add references to the= various new SCRAM mechanisms, but as I have already told you I plan on waiting a bit. There is no harm in waiting for more feedback on them before referencing them in this I-D. > Please read my comments after. I am not sure what comments you are referring to. > I have never said finalize today or tomorrow. And other parts can be > improved. I apologize, I thought when you said "The final 'draft-ietf-kitten-passw= ord- storage' must be validated like a RFC after the next two I-Ds, it is really important" you meant that we should move password-storage to RFC after two more drafts and this is what I was pushing back on. I am sorry= if I misunderstood. > - "draft-ietf-kitten-tls-channel-bindings-for-tls13" I-D updates or > obsoletes RFC5929 (but it is not specified in header) I'm not sure if this is true or not. Maybe it just updates them since they are still valid for TLS 1.2? I could go either way. I will make a note that this needs updating in a future revision. Thanks. > - "draft-ietf-kitten-password-storage" I-D updates RFC8600 (but it is > not specified in header) I don't think this one is true unless we're going to count this as updating every single protocol that uses SCRAM. > Do not forget that: 1 - CRAM-MD5 to Historic: > - https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00 > // 20 November 2008 > - https://tools.ietf.org/html/draft-zeilenga-luis140219-crammd5-to-his= toric-00 > // June 29, 2017 I don't think we need to reference every obsolete hashing mechanism, I just mentioned that old MD5 mechanisms aren't a good idea in the example= of how to order mechanisms. > Maybe it is time to take them off completely from the list even if > they are after PLAIN. They are off the list, the only place they are mentioned is in an example of how to order mechanisms. If this is causing confusion maybe they shouldn't be mentioned there either though. I'll consider it for the next draft. Thank you for your feedback. I'm sorry if I missed anything, it was a very long email and included feedback on multiple I-Ds. In future it might be best to provide feedback for different I-Ds in different threads. Hopefully I responded to all the important bits. =E2=80=94Sam From nobody Sun Nov 22 12:50:16 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 802453A0D44; Sun, 22 Nov 2020 12:50:08 -0800 (PST) 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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: kitten@ietf.org Message-ID: <160607820836.27682.10183618144255112930@ietfa.amsl.com> Date: Sun, 22 Nov 2020 12:50:08 -0800 Archived-At: Subject: [kitten] I-D Action: draft-ietf-kitten-password-storage-02.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: Sun, 22 Nov 2020 20:50:09 -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-02.txt Pages : 13 Date : 2020-11-22 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-02.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-kitten-password-storage-02 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 Sun Nov 22 20:46:59 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 A62453A1324 for ; Sun, 22 Nov 2020 20:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H2=-0.001, SPF_NONE=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 UlAWXmwWYIM3 for ; Sun, 22 Nov 2020 20:46:56 -0800 (PST) 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 63E603A1317 for ; Sun, 22 Nov 2020 20:46:56 -0800 (PST) Received: from oxuslxaltgw13.schlund.de ([10.72.76.69]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0MOxnN-1kcuc50zTT-006M7B for ; Mon, 23 Nov 2020 05:46:54 +0100 Date: Sun, 22 Nov 2020 22:46:53 -0600 (CST) From: steve@tobtu.com To: "kitten@ietf.org" Message-ID: <383104680.145048.1606106813679@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-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:uIGHPJZY8KzaC1wVopWYzMssRL6bSBZX2s+KXrQM6w9j5BkHpLu ZVwVoWoGV1j1ay7gNKjWNOH2qwbJCjmw24kmc/NeIw3cgJLET/pqhBE2SRpEXjcuaE0xOoj FZ8qamJAaBX+ZZ2bqpzaaU3W1YED4/qn0E91x9az/QvFWFEUMLwckG27XstfwtpVS0qowOg QuHD3Dhkz/H8ezLK0gN5w== X-UI-Out-Filterresults: notjunk:1;V03:K0:eHnLjZfGA30=:pacu7nxDaMMlpR2Tnxhy6J Zc75UfqraQ8++m7m4wPgC0k5kbQWZn6UfnrAUqwueefGB/OZALjZZUHj1hqVkovIKUA4rhWIb 40jDhcN2rwf+klgP2Kd1gka7z6z5ef5LuAcBtKsgTO7h9HUaqRFxLtt01y8A/STN34kcaAGHX GSWU8IvAjmmJxKGJPBQdrYDcW8oq75UUL9dfvzWQ+rmzKUEi/kY9hpwk8zgWzDaQbhGXJCRU/ vRSp3tqWSYBSDyGlMD9eqrFs7mdUrsL/u37KQ8ytwG6tC9e2d8QY8luV7aVgYqEAXmVXuwuyz 6fVcglYdgM8pfIXEZuDYTRypjEbol41EtwPpojALXhmcLfOqIb/2ETzhg1YoaXlMQa8ocZFEo rw8ZZcJ/e43W7jwZixIbXV3UsBrI46bjGpSvEL0yI5CbPTbgibX2Db+UW2z31 Archived-At: Subject: [kitten] Comments on draft-ietf-kitten-password-storage-02 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: Mon, 23 Nov 2020 04:46:58 -0000 scrypt's "output length (dkLen)" of "hLen (length of the chosen hash)" is the same wording as PBKDF2, but you can't choose a hash. Also this doesn't matter because scrypt uses PBKDF2 with 1 iteration so it doesn't suffer from the PBKDF2 footgun. The password hashing output length should be 128 to 256 bits. More doesn't matter and less can start getting dangerous. Also same applies to Argon2. From nobody Sun Nov 22 22:54:36 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 4D77F3A1503; Sun, 22 Nov 2020 22:54:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.428 X-Spam-Level: X-Spam-Status: No, score=0.428 tagged_above=-999 required=5 tests=[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.626, HK_RANDOM_FROM=0.001, 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 1kTIG9qE3W_0; Sun, 22 Nov 2020 22:54:31 -0800 (PST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11olkn2072.outbound.protection.outlook.com [40.92.20.72]) (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 F10983A150F; Sun, 22 Nov 2020 22:54:30 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=dyM2btRwxmw7wQZumZywmcldyK4SWOSB9FYFQvPLh9et4O2FZSKszUM2Taa3BQx8cUigUyHGj3l2fc+cUpCUMv2UfZ3u6yTKcwd7D7j1wBsH8LG2rJOvDoyBFy3SRvT8WQ/+sccXqvOJXewwhwJcvRYMitJ+rQa+pY9+elFxrMK7OlG4dTW+JCjOvzLBtLgzIqeEc0Whs8ixy8Q36HDXunYoq1cIiviqXGxLVtRGknfHC7OuCTP3TI5CKt0Bmfofc15m8BrsCW2m/18ijba0AoK2DgTl6U1zEzNtlCscYwMLkRSujENszNDnwHYxmMz06hQUWFLWMPKrEfNLv7Ay4g== 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=BMbb/MLagtN916SqxoJotG2NwjZkyMz0o+ljzYNvWng=; b=fArWGYVsBlctMeJl2ocIvg19JnGryc6EYet35r/CRe4Dt/kDaMC5Nd2o4sd2ANFxx/CEy8YN9yPjp8PZ9RQniXSSRDvLqkfNRWolKDY8l9Ig8OuJrP2Y4HRbBbbHKUMKzi0DH0RQoA9be5l3Cb0ujW4acx2j+SnVLceVzTTWep1gCKI9ttVB5umo3qctzrIAQZPNBhzTQYJnTUoJdlzmJyLdNZpdff8xGRRD2zYLICPoVoYLOGet+ybixNKWZQ91DP8gba9pSWygqVltuU+/xWk29TPsJPNhHL37NH/JLHIuPRp7uaO/xUA+h3wzrbGLw8ocgoUB+znHZHBX2iFqcA== 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=BMbb/MLagtN916SqxoJotG2NwjZkyMz0o+ljzYNvWng=; b=Q1DvGC3bZ2lZcr2h3bwAmQ+AHwd8tHW9RjsV727x1I8171OMOotcXPjHS0zNaxKiMS5oPlj7xaYE67fiDC4LTjsTIFa/UY8WUFOBt4k1FAGRYzHE2cPc0JW0ubGW0+5JogZ5JPuXicX2rfdh1o64CaRkF+KDty9EF0FRzdz7+jW+sEeZA+bQjevGg8JGmN38DJUacUsz50FyliCqLfls5xPr0Dc1shSqDpTkzrfVtnGalXumNNlxT6VgqhekEkqgGRm5OGJK09zO71j53pzRs2RhJipwLqffQfHiQLWdCYxh7pjrtCPYDwP1WIPzG5cq4psamWdLqOONEz5NhAOluA== Received: from BN8NAM11FT045.eop-nam11.prod.protection.outlook.com (2a01:111:e400:fc4b::50) by BN8NAM11HT076.eop-nam11.prod.protection.outlook.com (2a01:111:e400:fc4b::198) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Mon, 23 Nov 2020 06:54:29 +0000 Received: from DM5PR14MB1308.namprd14.prod.outlook.com (2a01:111:e400:fc4b::52) by BN8NAM11FT045.mail.protection.outlook.com (2a01:111:e400:fc4b::303) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22 via Frontend Transport; Mon, 23 Nov 2020 06:54:29 +0000 Received: from DM5PR14MB1308.namprd14.prod.outlook.com ([fe80::fc62:447d:49e4:71d8]) by DM5PR14MB1308.namprd14.prod.outlook.com ([fe80::fc62:447d:49e4:71d8%8]) with mapi id 15.20.3589.021; Mon, 23 Nov 2020 06:54:29 +0000 From: Ludovic BOCQUET To: Sam Whited , Alexey Melnikov , Robbie Harwood , Jim Fenton , KITTEN Working Group CC: "draft-ietf-kitten-password-storage@ietf.org" Thread-Topic: [kitten] Comments on draft-ietf-kitten-password-storage-00 Thread-Index: AQHWgx8GB467h9kG20m5bHwptIPHSal0/TqAgDqFl7SAACFxgIAHMG2AgAF7oQCAACWCkIAAW3iAgAAao/CAHCwNAIAAbdnM Importance: high X-Priority: 1 Date: Mon, 23 Nov 2020 06:54:29 +0000 Message-ID: References: <6dde1303-3d0c-6811-c201-00edbe5ab84e@bluepopcorn.net> <099cf65d-5a57-4e64-93cd-8504aa3bb97d@www.fastmail.com> , <8d757904-4f41-4981-90fe-e94b6039d00b@www.fastmail.com> In-Reply-To: <8d757904-4f41-4981-90fe-e94b6039d00b@www.fastmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:6A8E57C824F3314CCF7E55E3A21B8F449C84D6534C8FC6ECF5D1008192F8AD7D; UpperCasedChecksum:3417D1C239F4F3258480D27D1B8AFC3EE65CC67DD78D36F325785EDE4FDD383E; SizeAsReceived:7747; Count:47 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [z2KS3n84OrTh08Px8IFBiizDMCjVMEsQ] x-ms-publictraffictype: Email x-incomingheadercount: 47 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 6badd356-b3dc-445d-9c6a-08d88f7c9fd2 x-ms-traffictypediagnostic: BN8NAM11HT076: x-ms-exchange-minimumurldomainage: xmpp.org#6496 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: oGVgbt8cfBPHMif3HZBHfYQF800Dj7gUIMsmQQKv0BUHmRqym57sETuNZCyPGDFsqbMr0IVSDw6zxSUPZHYEuCNMSMArfHsskRG4vUuQ5bEhzV1nDFTIuP06WuQwvWi2ksuGKf9EsI+2NKnGXbZe4KIkI5+Cn1JWCXBTG3dXPL8ciUE5C4f8dJoInXKBuLOZRIuw9M25GOIG7oc/55j2anY2HGYjHz2EFlTy/OSo78LdKx5xF1EZ8kcNJDydHnkd x-ms-exchange-antispam-messagedata: 0RMqX0q7QF5ebJLG1HyzE9zKFbEW7RQuF+bVYpWo1q1OA7GubswyS8JVCxPzJS/MRa2jHmPMxKEG3/iU1gDDjTLZcW8GRmwb26DewKz3CAOXsSd/ulFFGWcStvM7GF/6oPi7b6a6Y/KldS3fqY8Egw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_DM5PR14MB1308189BBED84E53622F6EB8B8FC0DM5PR14MB1308namp_" MIME-Version: 1.0 X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-AuthSource: BN8NAM11FT045.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 6badd356-b3dc-445d-9c6a-08d88f7c9fd2 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Nov 2020 06:54:29.1202 (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: BN8NAM11HT076 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: Mon, 23 Nov 2020 06:54:33 -0000 --_000_DM5PR14MB1308189BBED84E53622F6EB8B8FC0DM5PR14MB1308namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable ________________________________ From: Sam Whited Sent: Sunday, November 22, 2020 8:36 PM To: Ludovic BOCQUET ; Alexey Melnikov ; Robbie Harwood ; Jim Fenton ; KITTEN Working Group Cc: draft-ietf-kitten-password-storage@ietf.org Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-00 On Sun, Nov 22, 2020, at 12:04, Ludovic BOCQUET wrote: > After my previous comments, maybe it is not clear to all in this > list, sorry. I apologize for the confusion, but I am still not sure what you are advocating for in this email. It appeared that you want the order that Alexey suggested, which I already said I would update in the next draft. -> Thanks for -02 draft :) - https://tools.ietf.org/html/draft-ietf-kitten-password-storage-02 It also appears that you're asking again for me to add references to the various new SCRAM mechanisms, but as I have already told you I plan on waiting a bit. There is no harm in waiting for more feedback on them before referencing them in this I-D. -> I hope that you will not forget to add before the final draft :) > Please read my comments after. I am not sure what comments you are referring to. -> I have explained why it is better to have a perfect "Best practices for = password hashing and storage" RFC instead of 2 RFCs (this future and a next= one to update "Best practices for password hashing and storage" with a "Be= st practices for password hashing and storage v2"). > I have never said finalize today or tomorrow. And other parts can be > improved. I apologize, I thought when you said "The final 'draft-ietf-kitten-password= - storage' must be validated like a RFC after the next two I-Ds, it is really important" you meant that we should move password-storage to RFC after two more drafts and this is what I was pushing back on. I am sorry if I misunderstood. -> If you need to have only RFC reference links instead draft or prepare to= release at the same time (see examples that I have done), but it is possib= le to have an RFC with draft reference links (see examples that I have done= ). > - "draft-ietf-kitten-tls-channel-bindings-for-tls13" I-D updates or > obsoletes RFC5929 (but it is not specified in header) I'm not sure if this is true or not. Maybe it just updates them since they are still valid for TLS 1.2? I could go either way. I will make a note that this needs updating in a future revision. Thanks. -> Thanks :) TLS 1.3 obsoletes TLS 1.2 and it is not for this that TLS 1.2 is already no= t used, there is a transition period... - https://tools.ietf.org/html/rfc8446 Obsoletes: 5077, 5246, 6961 Updates: 5705, 6066 > - "draft-ietf-kitten-password-storage" I-D updates RFC8600 (but it is > not specified in header) I don't think this one is true unless we're going to count this as updating every single protocol that uses SCRAM. -> It is SCRAM-SHA-512(-PLUS) and SCRAM-SHA3-512(-PLUS) which must inform t= he update of other previous SCRAM. But the order in the RFC8600 is not good: - https://tools.ietf.org/html/rfc8600 - "When using the SASL SCRAM mechanism, the SCRAM-SHA-256-PLUS variant SHOU= LD be preferred over the SCRAM-SHA-256 variant, and SHA-256 variants [RFC76= 77] SHOULD be preferred over SHA-1 variants [RFC5802])". Results: SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-= 1. I have informed you when you have done: https://tools.ietf.org/html/draft-w= hited-kitten-password-storage-00. Recall: The order was bad since the first draft: - https://tools.ietf.org/html/draft-whited-kitten-password-storage-00 "- SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS - SCRAM-SHA-1, SCRAM-SHA-256" Results: SCRAM-SHA-1-PLUS > SCRAM-SHA-256-PLUS > SCRAM-SHA-1 > SCRAM-SHA-25= 6. Now, we have updated the good order in "draft-ietf-kitten-password-storage"= : - https://tools.ietf.org/html/draft-ietf-kitten-password-storage-02 "- SCRAM-SHA-256-PLUS - SCRAM-SHA-1-PLUS - SCRAM-SHA-256 - SCRAM-SHA-1" Results: SCRAM-SHA-256-PLUS > SCRAM-SHA-1-PLUS > SCRAM-SHA-256 > SCRAM-SHA-= 1. This current draft updates the RFC8600. Do not forget that there is the XEP-0438 too: - https://xmpp.org/extensions/xep-0438.html > Do not forget that: 1 - CRAM-MD5 to Historic: > - https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00 > // 20 November 2008 > - https://tools.ietf.org/html/draft-zeilenga-luis140219-crammd5-to-histor= ic-00 > // June 29, 2017 I don't think we need to reference every obsolete hashing mechanism, I just mentioned that old MD5 mechanisms aren't a good idea in the example of how to order mechanisms. -> See below > Maybe it is time to take them off completely from the list even if > they are after PLAIN. They are off the list, the only place they are mentioned is in an example of how to order mechanisms. If this is causing confusion maybe they shouldn't be mentioned there either though. I'll consider it for the next draft. -> Thanks! :) If removed or not, better to have references to inform people that it is ne= eded to downgrade (like you have done, before PLAIN) or remove the implemen= tation to have a more secure system. I really think that references to RFC6331 and old CRAM-MD5 drafts (not RFCs= badly) are needed. Thank you for your feedback. I'm sorry if I missed anything, it was a very long email and included feedback on multiple I-Ds. In future it might be best to provide feedback for different I-Ds in different threads. Hopefully I responded to all the important bits. =97Sam Thanks for the answers, the changes made and those still to be made. Regards, BOCQUET Ludovic --_000_DM5PR14MB1308189BBED84E53622F6EB8B8FC0DM5PR14MB1308namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable


From: Sam Whited <sam@= samwhited.com>
Sent: Sunday, November 22, 2020 8:36 PM
To: Ludovic BOCQUET <lbxmpp@live.com>; Alexey Melnikov <ale= xey.melnikov@isode.com>; Robbie Harwood <rharwood@redhat.com>; Jim= Fenton <fenton@bluepopcorn.net>; KITTEN Working Group <kitten@iet= f.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
 


On Sun, Nov 22, 2020, at 12:04, Ludovic BOCQUET wrote:
> After my previous comments, maybe it is not clear to all in this
> list, sorry.

I apologize for the confusion, but I am still not sure what you are
advocating for in this email. It appeared that you want the order that
Alexey suggested, which I already said I would update in the next draft.
-> Thanks for -02 draft :)



It also appears that you're asking again for me to add references to the various new SCRAM mechanisms, but as I have already told you I plan on
waiting a bit. There is no harm in waiting for more feedback on them
before referencing them in this I-D.

-> I hope that you will not forget to add before the final draft :)



> Please read my comments after.

I am not sure what comments you are referring to.

-> I have explained why it is better to have a perfect "Best practi= ces for password hashing and storage" RFC instead of 2 RFCs (this futu= re and a next one to update "Best practices for password hashing and s= torage" with a "Best practices for password hashing and storage v2").



> I have never said finalize today or tomorrow. And other parts can be > improved.

I apologize, I thought when you said "The final 'draft-ietf-kitten-pas= sword-
storage' must be validated like a RFC after the next two I-Ds, it is
really important" you meant that we should move password-storage to RF= C
after two more drafts and this is what I was pushing back on. I am sorry if I misunderstood.

-> If you need to have only RFC reference links instead draft or prepare= to release at the same time (see examples that= I have done), but it is possible to have an RFC with draft reference links (see examples that I have done).=



> - "draft-ietf-kitten-tls-channel-bindings-for-tls13" I-D upd= ates or
>   obsoletes RFC5929 (but it is not specified in header)

I'm not sure if this is true or not. Maybe it just updates them since
they are still valid for TLS 1.2? I could go either way. I will make a
note that this needs updating in a future revision. Thanks.

-> Thanks :)
TLS 1.3 obsoletes TLS 1.2 and it is not for this that TLS = 1.2 is already not used, there is a transition period...
- https://tools.ietf.org/html/rfc8446
Obsoletes: 5077, 5246, 6961
Updates: 5705, 6066



> - "draft-ietf-kitten-password-storage" I-D updates RFC8600 (= but it is
>   not specified in header)

I don't think this one is true unless we're going to count this as
updating every single protocol that uses SCRAM.

-> It is SCRAM-SHA-512(-PLUS) and SCRAM= -SHA3-512(-PLUS) which must inform the update of other previous SCRAM.

But the order in the RFC8600 is not good:
- https://tools.ietf.org/html/rfc8600
- "When using the SASL SCRAM mechanism, the S= CRAM-SHA-256-PLUS variant SHOULD be preferred over the SCRAM-SHA-256 varian= t, and SHA-256 variants [RFC7677] SHOULD be preferred over SHA-1 variants [= RFC5802])".
Results: SCRAM-SHA-256-PLUS > SCRAM-SHA-256 > SCRAM-SHA-1-PLUS > SCRAM-SHA-1.

I have informed you when you have done: = https://tools.ietf.org/html/draft-whited-kitten-password-storage-00.

Recall: The order was bad since the first draft:<= /span>
- https://tools.ietf.org/html/draft-whited-kitten-password-storage-0= 0
"- SCRAM-SHA-1-PLUS, SCRAM-SHA-256-PLUS
- SCRAM-SHA-1, SCRAM-SHA= -256"
Results: SCRAM-SHA-1-PLUS > SCRAM-SHA-256-PLUS = > SCRAM-SHA-1 > SCRAM-SHA-256.

Now, we have updated the good order in "draft-ietf-kitten-password-sto= rage":
- https://tools.ietf.org/html/draft-ietf-kitte= n-password-storage-02
"- SCRAM-SHA-256-PLUS
- SCRAM-SHA-1-PLUS
- SCRAM-SHA-256
- SCRAM-SHA-1"
Results: SCRAM-SHA-256-= PLUS > SCRAM-SH= A-1-PLUS > SCRAM-SHA-256 > = SCRAM-SHA-1.

This current draft updates the RFC8600.

Do not forget that there is the XEP-0438 too:
- https://xmpp.o= rg/extensions/xep-0438.html



> Do not forget that: 1 - CRAM-MD5 to Historic:
> - https://tools.ietf.org/html/draft-ietf-sasl-crammd5-to-historic-00
>   // 20 November 2008
> - https://tools.ietf.org/html/draft-zeilenga-luis140219-crammd5-to-historic-0= 0
>   // June 29, 2017

I don't think we need to reference every obsolete hashing mechanism, I
just mentioned that old MD5 mechanisms aren't a good idea in the example of how to order mechanisms.

-> See below



> Maybe it is time to take them off completely from the list even if
> they are after PLAIN.

They are off the list, the only place they are mentioned is in an
example of how to order mechanisms. If this is causing confusion maybe
they shouldn't be mentioned there either though. I'll consider it for
the next draft.

-> Thanks! :)
If= removed or not, better to have references to inform people that it is need= ed to downgrade (like you have done, before PLAIN) or remove the implementation to have a more secure system.
I really think that reference= s to RFC6331 and old CRAM-MD5 drafts (not RFCs badly) are needed.



Thank you for your feedback. I'm sorry if I missed anything, it was a
very long email and included feedback on multiple I-Ds. In future it
might be best to provide feedback for different I-Ds in different
threads. Hopefully I responded to all the important bits.

=97Sam


Thanks for the answers, the changes made and those still to be made.

Regards,

BOCQUET Ludovic
--_000_DM5PR14MB1308189BBED84E53622F6EB8B8FC0DM5PR14MB1308namp_-- From nobody Mon Nov 23 04:28:17 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 079CE3A09EC for ; Mon, 23 Nov 2020 04:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.22 X-Spam-Level: X-Spam-Status: No, score=-0.22 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=pqJKgWOB; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=hRK5NxlF 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 jl4mzpLRPx8p for ; Mon, 23 Nov 2020 04:28:14 -0800 (PST) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C88D3A09EA for ; Mon, 23 Nov 2020 04:28:14 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 7303F10C0 for ; Mon, 23 Nov 2020 07:28:13 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Mon, 23 Nov 2020 07:28:13 -0500 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=K4rAL krcGo+A/PEGYkXyAYk1hRRvTX/gZd94LzZHHz8=; b=pqJKgWOByNFAN5u2H97Pr jD8fb5NvN/X/O12FRk8KpDxhIh1SnzOX6iGOuuHmFASpvHxeotKV41Neujg2YKjP /u4ldgNmAjnc9nrjyfGkxgNS1aGNhoCn8gEfkjH1cC2HYrKliAf85TQcXiXwvuJu Y7AJZS4p2Idg5BoyvbMEPNYuocklyNh5b0sb6d2qsNDkZdk+QLIeeGtVkTgLaTtW 3qm+T5gaEhumILjjEO4JRqpwvQphhukOs9frZ8YkTwLZMwR6EqmyxZyyODtPwZ7A 4dl+F8Jy9cUkAsIDU6kBcROBuP1K/YRYqRKLfTGmTJ7r9pmMY2+csN9F/GYLeoow w== 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=K4rALkrcGo+A/PEGYkXyAYk1hRRvTX/gZd94LzZHH z8=; b=hRK5NxlFYwgS1NnHgr1sV2kXHLH2ajJSG+zeUpDiOT2iWeoZLlONfF4pd O7ndYTAnq469pjsmCo9Sgqd6XNci0AaB+g84Kn0sSFyHn2fwHQyFlblEep9egkrp sqB4WTd7ru0XimRVpLZOR/ePVlIgi6ukNHL4RMHg9tIomgc6u+01KIiX69LPHrWE qBVoJwv/hL31ie0ZwqQ0ZF7TJBgkvP7bqncSqt9hHbguLE22eX162P2Xhx29cxEa eRwknGmgzJLVXRV3sO/uC4sktt8gwK3S6dVxVQxjDZCgHvkJ0kgxugs27R8pvgns fHitKoJAgI4OYK3jy3tbw+e6T+9Mw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudegiedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufgr mhcuhghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrg htthgvrhhnpedvffeuvdduhfefvdeiheeukeffhfekjeevgffggedtlefhhffhieevkedu vefhjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id B463A1460062; Mon, 23 Nov 2020 07:28:12 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: In-Reply-To: <383104680.145048.1606106813679@email.ionos.com> References: <383104680.145048.1606106813679@email.ionos.com> Date: Mon, 23 Nov 2020 12:27:52 +0000 From: "Sam Whited" To: "KITTEN Working Group" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-02 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: Mon, 23 Nov 2020 12:28:16 -0000 On Mon, Nov 23, 2020, at 04:46, steve@tobtu.com wrote: > scrypt's "output length (dkLen)" of "hLen (length of the chosen hash)"= > is the same wording as PBKDF2, but you can't choose a hash. Fixed in the next draft, thank you. > Also same applies to Argon2. This doesn't appear to be the case for argon2 where I don't list a length (if I recall correctly the output length isn't one of the argon2 inputs). Is there specific language you think needs to be changed for the argon2 recommendations? Thanks. =E2=80=94Sam From nobody Mon Nov 23 15:22:51 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 A8B853A0F44 for ; Mon, 23 Nov 2020 15:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.018 X-Spam-Level: X-Spam-Status: No, score=-0.018 tagged_above=-999 required=5 tests=[RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 n48i5UefHzAR for ; Mon, 23 Nov 2020 15:22:48 -0800 (PST) Received: from mout.perfora.net (mout.perfora.net [74.208.4.197]) (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 4BC463A0F41 for ; Mon, 23 Nov 2020 15:22:48 -0800 (PST) Received: from oxuslxaltgw05.schlund.de ([10.72.76.61]) by mrelay.perfora.net (mreueus003 [74.208.5.2]) with ESMTPSA (Nemesis) id 0M7qgY-1kLQbW0l0K-00vQmJ for ; Tue, 24 Nov 2020 00:22:46 +0100 Date: Mon, 23 Nov 2020 17:22:45 -0600 (CST) From: steve@tobtu.com To: "kitten@ietf.org" Message-ID: <853962335.300533.1606173765880@email.ionos.com> In-Reply-To: References: <383104680.145048.1606106813679@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-Rev26 X-Originating-Client: open-xchange-appsuite X-Provags-ID: V03:K1:jg2twkyifecvJOut0FIoVPaPbSwYLg5aZWwPA51w8+OkU8lXN2L u33kgahNoo8X7UCtSnWAOHz5gzviKNbitaw9TC52XPCppx/erHNiSPZJ02moGrC2oUczwTQ Os1Uk2imMa1Cv5Fy7zdEwVOK+4Z7HRU0N0mADhg/RF09MQ98lvvu3J/hIGtt0IoQ1ZH6NfW IkDMLygXeYLWEr24mUNMA== X-UI-Out-Filterresults: notjunk:1;V03:K0:SolaForxDqY=:t4vmX0VmMOVwQdR+iGioe3 6/pvZouk5j+O2Oo3Vunr3mC7Vqwtlza/YYbWIgv6NEeLYYZ+3o9m965jFky+moVuUTJXNtcW/ xZZmwvkPzX8BFIAi7MGyUEhUzPqIBRqi1flQA/HEOnED4zBK+Kc/NE1VTTB+fFRAlqQ3W+cVC 7ZctAW3mFjpi1novhi5/3uMmYuJU9+pbhjgqwzLWc5gdDKGmg5pXuKLzkV54yt69clAOSJ50A U2ZXnaRg9fFkFYD1nshMFWPT9RTx724630I84pekzl+mH4vZYyxhdVh+SCV6CoWFtJ1Sg6DbM gi/aTiPdV2omat5Ba635nvaZthoMoFqkmZ0BGWQr4yO65THhFmJpfuER4tSnz3Y6rAHhDmTCr s22dYNOCDonNPJqTqEL5UqZqedHwIEGeqZhAGA9e4ghoq2XorNm8K6wW5oQvy Archived-At: Subject: Re: [kitten] Comments on draft-ietf-kitten-password-storage-02 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: Mon, 23 Nov 2020 23:22:50 -0000 > On 11/23/2020 6:27 AM Sam Whited wrote: > > On Mon, Nov 23, 2020, at 04:46, steve@tobtu.com wrote: > > Also same applies to Argon2. > > This doesn't appear to be the case for argon2 where I don't list a > length (if I recall correctly the output length isn't one of the argon2 > inputs). Is there specific language you think needs to be changed for > the argon2 recommendations? Thanks. > Argon2 is a KDF which has a variable output length like scrypt. Most password hash implementations pick this for you. From the official Github page (note "-l 24" is for length): $ echo -n "password" | ./argon2 somesalt -t 2 -m 16 -p 4 -l 24 Type: Argon2i Iterations: 2 Memory: 65536 KiB Parallelism: 4 Hash: 45d7ac72e76f242b20b77b9bf9bf9d5915894e669a24e6c6 Encoded: $argon2i$v=19$m=65536,t=2,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTmaaJObG Note PHP has chosen a 128 bit salt and a 256 bit hash: $argon2i$v=19$m=65536,t=4,p=1$WFpjTC9IWVJNOXZTYkhaZw$FhfiGVLiI9k7gOt1K9AKOJz8V9Wutz5CMqkvbiksOOo Also note that PHP can verify this hash "$argon2i$v=19$m=65536,t=2,p=4$c29tZXNhbHQ$RdescudvJCsgt3ub+b+dWRWJTmaaJObG". Even though it's of a different length. ---- For Argon2 and scrypt, it should say something like "if you can pick an output length then choose at least 128 bits and at most 256 bits." Or state it in bytes or just say pick between 128, 192, and 256 bits. Oh technically this also applies to PBKDF2 but with the added part not to output more than hLen. Hmm I guess just pick one as it doesn't really matter. Yeah I suggest for Argon2 and scrypt to say "default or 24 bytes" and PBKDF2 "min(hLen, 24 bytes)". You can change 24 to whatever I won't bike shed you on that. I like 24 bytes as it's multiple of 3 which is nice with base 64 encoding. Which is kind of a dumb reason but I will back any number bytes 16 to 32. From nobody Wed Nov 25 18:21:52 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 067F53A098A for ; Wed, 25 Nov 2020 18:21:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 4NBZXde51Xd8 for ; Wed, 25 Nov 2020 18:21:42 -0800 (PST) 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 5D7A13A09A8 for ; Wed, 25 Nov 2020 18:21:40 -0800 (PST) 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 0AQ2LYIq014245 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 25 Nov 2020 21:21:39 -0500 Date: Wed, 25 Nov 2020 18:21:34 -0800 From: Benjamin Kaduk To: Sam Whited Cc: KITTEN Working Group Message-ID: <20201126022134.GS39170@kduck.mit.edu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [kitten] Comments on draft-tls-channel-bindings-for-tls13 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, 26 Nov 2020 02:21:51 -0000 On Wed, Nov 18, 2020 at 09:41:32PM -0500, Sam Whited wrote: > Responses inline: > > On Wed, Nov 18, 2020, at 14:49, Robbie Harwood wrote: > > This document doesn't seem to address what the problems with the > > previous channel binding types were. > > I'll add some text here. The TL;DR is that without the extended master > secret fix from RFC7627 tls-unique is not actually unique. I also recall > someone suggesting that the unique data really wasn't long enough, which > seems likely, but I don't have a citation for that off the top of my > head so I'll stick to mentioning the triple handshake vulnerability and > the extended master secret extension and leave it at that. > > > > It also doesn't appear in the referenced section (i.e., RFC 8446 > > section 7.5 doesn't seem to have this information; moreover, that > > section doesn't reference RFC 5929). > > > > RFC 8446 section C.5 does call out cbs as a protection mechanism, but > > merely notes that they're not implemented for 1.3, so it's probably > > not a case of wrong section. > > That was indeed supposed to be a reference to C.5. That's the only > reference I'm aware of for why the two CB mechanisms from 5929 aren't > defined in 1.3. This is a very confusing off-the-cuff reference in the > TLS 1.3 spec, but it's what I'm basing the entire need for a new CB > mechanism on. I would have to go trawl through the archives to be sure, but in TLS 1.3 the first Finished is sent by the server, and does not cover the client Certificate. So the RFC 5929 tls-unique is not fit for purpose for purposes of client authentication. (And the exporter interface has better cryptographic hygeine in general, though that's not exactly a compellling argument to disallow its usage entirely.) > > > In "2. The 'tls-exporter' Channel Binding Type": … This feels > > redundant with the formal IANA considerations section later in the > > document. I think it would be more helpful to orient it toward > > explaining the cb type as pertains to RFC 5705 and RFC 8446. > > I did it this way because RFC5929 did it this way, but I agree it's > awkward. I'll rewrite this to be descriptive and give a bit of > background on EKM and TLS 1.3 instead. > > > > Hmm, this text is a bit awkward right now. I suggest something like: > > > > When TLS renegotiation is enabled, implementations MUST NOT > > support channel binding using the "tls-exporter" type as it is not > > defined. > > Sounds good to me; thanks. It may (or may not) be worth a reminder that any renegotiation is pre-TLS-1.3. > > > Curious - is there a practical reason to want this CB type with TLS <= > > 1.2? > > Not that I can think of. I suppose it would be nice to have a single > channel binding type that works regardless of the TLS version being > used, but it seems simpler to just let TLS 1.2 die and not worry about > it since channel binding isn't widely supported right now anyways. Indeed, and I've been attempting to promote this unified usage. (Though the main case I can remember doing so, draft-ietf-nfsv4-rpc-tls, has since gone 1.3-only, so it doesn't matter there anymore.) Thanks, Ben > > > Please also see the idnits here: > > Will do, thanks. > > I'll have a new version up soon. > > —Sam > > -- > Sam Whited > > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten From nobody Thu Nov 26 05:44:21 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 5E36E3A10F6 for ; Thu, 26 Nov 2020 05:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 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.01, RCVD_IN_MSPIKE_WL=-0.01, 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=YBtZxHhM; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=f3sLKkdy 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 o1rT_9_J2OVu for ; Thu, 26 Nov 2020 05:44:18 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A2043A10F5 for ; Thu, 26 Nov 2020 05:44:17 -0800 (PST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 5528E5C0124; Thu, 26 Nov 2020 08:44:16 -0500 (EST) Received: from imap34 ([10.202.2.84]) by compute4.internal (MEProxy); Thu, 26 Nov 2020 08:44:16 -0500 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=gc fMv6OP/e0VV3pvn7Um9kPTCL1n/Dmh2cuQJZecrJw=; b=YBtZxHhM4tynRNPeaa vOMugNBTxBTa+w8Z2j0MmQ/pGGt3Crn66PK0A5vP7u46QqMmdSXtiimamrv/hgYt ffYu1VECVLKVeVcaKdC38NQpJY/WByNNsDatG26aMDz307keQ5vRGnwJbR7WEgsG 6uEsXZze/Jtxppemm32skjZNq1n8TPANrH+258ZeYrxPSQz/3YLRqBlWr/Y4lzl+ 2+6Z+dOD2gdtY4UvZ4ssMwMdX4Z+IAf7BuUvewt3zVG467aI7xaHGtB226+auQ+9 OP3SxNvgG8VJcM5x98dBN7SR5W2K4iK8JOQEKEwLd5bz13krF2IFbb4gMPuoRWKf 9FNg== 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=gcfMv6OP/e0VV3pvn7Um9kPTCL1n/Dmh2cuQJZecr Jw=; b=f3sLKkdyzo4T3O/tzZBVNjQNKWmLuvgHRaWSxqr+6Mq0LOdTtMP9T7Mvy DECCbnAttL13QkAfFLAOSTWDJnEdEO/AhRgiZMjEl3PD/5EGoNngEOe2X2mAsLZ+ wgyqX4OcEU5D7ptsH1t8n1r2AiGauQ9CYtKNbYSxAPrXuGgN3P7f19G8yFwXKFrd ATJKuOGRWT7LD/lWsFMIKEoiSx+U1FQYG358YGu1hX1FHPCCTXbqIjIqYnDxaWO3 Sco1jMI3eO8se8xaQenOhlREPxxVSBPql8dX0RhoXcsHASWUamcyiFY+zgst7p38 VFxh2SjzDDmzO7oCpdEbl7R2iIUkw== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedujedrudehvddgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgfgsehtqhertderreejnecuhfhrohhmpedfufgr mhcuhghhihhtvggufdcuoehsrghmsehsrghmfihhihhtvggurdgtohhmqeenucggtffrrg htthgvrhhnpedvffeuvdduhfefvdeiheeukeffhfekjeevgffggedtlefhhffhieevkedu vefhjeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hsrghmsehsrghmfihhihhtvggurdgtohhm X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 07C451460062; Thu, 26 Nov 2020 08:44:15 -0500 (EST) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-622-g4a97c0b-fm-20201115.001-g4a97c0b3 Mime-Version: 1.0 Message-Id: <48c1644c-27e0-4940-baf1-1e7d20e597f6@www.fastmail.com> In-Reply-To: <20201126022134.GS39170@kduck.mit.edu> References: <20201126022134.GS39170@kduck.mit.edu> Date: Thu, 26 Nov 2020 13:43:55 +0000 From: "Sam Whited" To: "Benjamin Kaduk" Cc: "KITTEN Working Group" Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [kitten] Comments on draft-tls-channel-bindings-for-tls13 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, 26 Nov 2020 13:44:19 -0000 Responses inline: On Thu, Nov 26, 2020, at 02:21, Benjamin Kaduk wrote: > I would have to go trawl through the archives to be sure, but in TLS > 1.3 the first Finished is sent by the server, and does not cover the > client Certificate. So the RFC 5929 tls-unique is not fit =E2=80=A6 Not to mention that in some situations it may not even exist (ie. when 0-RTT is enabled). If you find a citation for this I'm game to expand this section a bit to cover why it wasn't great for TLS 1.3 specifically. > It may (or may not) be worth a reminder that any renegotiation is > pre-TLS-1.3. Probably a good idea; I'll ear-mark that for the next version. I don't have it in front of me, but I vaguely remember mentioning that it wasn't defined when renegotiation was in use, but since we don't define it for TLS 1.2 anyways that's probably redundant. I'll try to clear that up anyways. > Indeed, and I've been attempting to promote this unified usage. If you can think of a way to do it safely I'm not against defining this for TLS 1.2, I just don't think I personally have the expertise to do so= since the key exchange mechanisms may or may not be safe for channel binding and it feels bad to have a CB mechanisms that has to have a big allow list of ciphers and lots of warnings like "Don't do this if you're= using RSA key exchange, it won't actually be a valid binding", etc. =E2=80=94Sam From nobody Sun Nov 29 10:05:01 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 7243D3A0AC1 for ; Sun, 29 Nov 2020 10:04:59 -0800 (PST) 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, FREEMAIL_FROM=0.001, 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 CxedfMfjwTvz for ; Sun, 29 Nov 2020 10:04:58 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 C297D3A0ABD for ; Sun, 29 Nov 2020 10:04:57 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id j10so13291948lja.5 for ; Sun, 29 Nov 2020 10:04:57 -0800 (PST) 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=+Lj3sw3JJ9J/DZD3Hcpajn3fCECdjE3nkT1csVUfX6k=; b=MLWsKXoGgZIJAcO3NqGkFW4pZ4Vi9VYzULtJb0PcrtfhIXGNP8mF4N2cl7F6xc9bGx DBSHXZcFW90+4NiukPWj0q7wOCZ9oim/vJDtJ+rRgOxHX8kKPentEQVubKwivPVWg58i AAaJ/kb1X2Uozvun/wCR9cpdHVR/KX57J/TMFLPWwvGQrxnFvNx9lcaC8dzaSTG2/yLY 02etofTzCBWspyMpBqqy9Jj5SSJRrETXZFAPBiVpSVzdFU/4Mxk3oaNNgdZXiDzmPvb/ g1mUFfNswF3hfKOe8jHxSPgt/i5Bvx1YeIPgePbTa2c3U+lSI4fQ01ylK03oIsXEM4JR uKPA== 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=+Lj3sw3JJ9J/DZD3Hcpajn3fCECdjE3nkT1csVUfX6k=; b=SJx2ZQnO5qNDU4iuWo6lJgmkSIIpsh0RP5gSAn841bdmJfdZVv73IvBB9/LdWC8hfq hj5fLwXSmXBWXt2LrWlSP5blJApJkvC4DPsj6sCuga200RggPr62SPV7mqUR7e+ohnDm yQboLWRJomlAKiYbD0Ow2v30zRvehOPgSmOKnRcxYuu59hvcstfwRrO0CY/+V3oftkAw qK/emjVcsN5U8L6UYOyIFwacQZMQ0pl5Wtx88htFDJ2GMW9VNx+e9mfUAwDtlLlNq3we 9Tpq4WixZo5CnKAgStwNvjuiOwSFYzmOJG1G8qQulmeq6gHCdL+vVGAaBwSDaogRQE8P 1P0A== X-Gm-Message-State: AOAM533k69mWzNulazVUVJCTY5gRB1nZf8ClBIsuopac+j0B9WiH74Ni LllqzqnubW2PUUcSZRKNGJxTOuZYvuKxVdMCsbE= X-Google-Smtp-Source: ABdhPJwAHSK4dF/ZHtk4EiVvM2RJEACGf3GQSXm1Cx5uENrysrlNUfjcq+AW2ISWFQTPEHoZQxghpk9AjCLTpGhMaO4= X-Received: by 2002:a2e:9990:: with SMTP id w16mr4915579lji.111.1606673095762; Sun, 29 Nov 2020 10:04:55 -0800 (PST) MIME-Version: 1.0 References: <160575402285.29157.16458359440559089744@ietfa.amsl.com> <26918967-e530-452f-bbda-b325d4d29b52@www.fastmail.com> In-Reply-To: From: Watson Ladd Date: Sun, 29 Nov 2020 10:04:44 -0800 Message-ID: To: Robbie Harwood Cc: Sam Whited , KITTEN Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [kitten] I-D Action: draft-ietf-kitten-tls-channel-bindings-for-tls13-01.txt 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, 29 Nov 2020 18:05:00 -0000 -01 looks fine to me. On Fri, Nov 20, 2020 at 9:42 AM Robbie Harwood wrote: > > "Sam Whited" writes: > > > I noticed before submitting this one that I'd added an extra "tls" > > before the name of the draft somehow (ie. tls-channel-bindings-for-tls > > not channel-bindings-for-tls), but it won't let me change the filename > > without resetting the version number. Does it matter, or is there > > something I should do to fix this? > > It could be fixed if you really wanted, but as others have stated, it's > fine. > > This new version addresses my concerns. I encourage others to take a > look and review this document even if it's just to indicate that you > think it's ready - the document is not especially long. > > Thanks, > --Robbie > _______________________________________________ > Kitten mailing list > Kitten@ietf.org > https://www.ietf.org/mailman/listinfo/kitten -- Astra mortemque praestare gradatim