Re: [Cfrg] [MASSMAIL]Re: Requirements for PAKE schemes

Станислав Смышляев <smyshsv@gmail.com> Sat, 30 January 2016 12:19 UTC

Return-Path: <smyshsv@gmail.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB1E1A1A6A for <cfrg@ietfa.amsl.com>; Sat, 30 Jan 2016 04:19:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.306
X-Spam-Level: *
X-Spam-Status: No, score=1.306 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_HTML_ONLY=1.105, SPF_PASS=-0.001] autolearn=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 GjWV8Yk0ds6N for <cfrg@ietfa.amsl.com>; Sat, 30 Jan 2016 04:19:45 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::234]) (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 445231A1A58 for <cfrg@irtf.org>; Sat, 30 Jan 2016 04:19:45 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id s81so61802401lfd.0 for <cfrg@irtf.org>; Sat, 30 Jan 2016 04:19:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:content-transfer-encoding:message-id:date :subject:from:in-reply-to:references:to:cc; bh=k+cBMV98mF/XGKArxdegoGTlbEgxKcrgJ+VKAp+20/s=; b=Sm2MRlYLt88vZ96UlWhZAtJ8I7lFEq9Ere/WasFs01umgjmxntQ+vFc8li9QHdPVYN oi8vCfmkBaI4IfWnRO1nLHV5zzEKvu29s0CXGHA4o4KtQt2EAIh7tBAJ2jAl2hmbDCsq JzDFbnOMb9qo2ITbyXAoGBT2iAcyT0PTm+lx2cJr6ry8v35kxhM0u56ZY867vL0MAbtu /cKHrHaY+ZJYLlLipcuEitaSfe2bekyHePtzDsrsEgTFtXmTpJ9ufTCpfYGjBGtkfyEV 8/xdKViBsz8u/3Ryi9EXwNI65O3IROk8o/7n7+rWOntJmFdZ8O5takNXjIFN6LCww/D2 /ydA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version :content-transfer-encoding:message-id:date:subject:from:in-reply-to :references:to:cc; bh=k+cBMV98mF/XGKArxdegoGTlbEgxKcrgJ+VKAp+20/s=; b=Eg155iNjgY61Xd9hZzQwjkOSHY6bJeE5g+GjvWiUgzZxIVK2XZRRX4Figw+fc4n50M cb6ugdlTxSA+2Km/nBQEOG8kW8MvYlGj4hxy4mY8GkVMIgugX54/XCJnhFcdfcoT+XZl P1c6g8B/yyOHS9ffCFhqXgVOHyI8qU0IR9P9MQYza3zULe0D6pnIwZcjEKC1BY1Bii5C sbkxiRCsGFzYdJOYU+5nBUrGepmBfUKRDn9TpUJpS1gdLjLg32VPMJWqH7IprbT5+5Pu MDQaDHTsrpq61nKHkkpV8GUDLHA9BrcmMsXskgtiHGinnlVZPqxl6tmowHOWWwEAvCy7 VVjQ==
X-Gm-Message-State: AG10YOSgkHlApl5ZFejk/TWj7488Ol06JZ8clk6Xfd12y+/f/G3K2EqotTSeQTJDj6h1tQ==
X-Received: by 10.25.90.83 with SMTP id o80mr5151881lfb.23.1454156383468; Sat, 30 Jan 2016 04:19:43 -0800 (PST)
Received: from [127.0.0.1] ([213.87.156.118]) by smtp.gmail.com with ESMTPSA id zk9sm2717994lbb.3.2016.01.30.04.19.41 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 30 Jan 2016 04:19:42 -0800 (PST)
Content-Type: text/html; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
X-Mailer: BlackBerry Email (10.3.2.2876)
Message-ID: <20160130121940.5910609.87457.1258@gmail.com>
Date: Sat, 30 Jan 2016 15:19:40 +0300
From: Станислав Смышляев <smyshsv@gmail.com>
In-Reply-To: <30BB5B38-9DC3-4DC1-968C-F3A2AC293E6F@gmail.com>
References: <CAMr0u6=76q4n-u1Vpv5vWjSNgi4CtaOJoX0EmvcbXH+9C4w2mg@mail.gmail.com> <78D9D0BF-4ADE-4DDB-88A4-BF03DD6336BA@shiftleft.org> <9c878c6b6b505414f71fa53442e4a33a@mail.tc26.ru> <CAMr0u6nzV_Y87ghnAcmhgkzk4fgdKtC3Kj8NqPyawHrjhGVySg@mail.gmail.com> <CACsn0ckKX7pKZ5qU0y6cR3jyGV8JmL1V8EAUwU6b4ShDYVxmYw@mail.gmail.com> <CAMr0u6kvc1B8MY7Nqs2NLd1tHPU6wiv7ti9QDQ5gvu6iRgw+2g@mail.gmail.com> <930102DC-F5B3-4233-BF6B-1EC631B4ABF5@gmail.com> <56AB6787.1010302@htt-consult.com> <30BB5B38-9DC3-4DC1-968C-F3A2AC293E6F@gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>, Robert Moskowitz <rgm-sec@htt-consult.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/ITqqfC-PwQ04aLOeocWGsvmNHvo>
Cc: cfrg@irtf.org
Subject: Re: [Cfrg] [MASSMAIL]Re: Requirements for PAKE schemes
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Sat, 30 Jan 2016 12:19:47 -0000

‎Hello, Yoav!

Thank you for your opinion; you are absolutely right that no one needs trivial considerations like "number of login attempts MUST be controlled" in each RFC (as much as "users MUST NOT store their passwords on sheets of paper pinned on their monitors", "Dual EC DRBG MUST NOT be used for generating both confidential and public data etc). 

Moreover, including such an obvious recommendation is harmful for security of implementations. If one reads such a phrase, he'll probably stop reading "Security considerations" section and won't read really important info that should be there next: specific recommendations of handling login attempt counters‎ such as "counter value MUST be incremented before sending [i]-th message of the [xyz]PAKE protocol".

General recommendations shouldn't be there, but specific ones must.

Kind regards,
Stanislav
От: Yoav Nir
Отправлено: суббота, 30 января 2016 г., 12:49
Кому: Robert Moskowitz
Копия: Василий Долматов; Stanislav V. Smyshlyaev; cfrg@irtf.org
Тема: Re: [Cfrg] [MASSMAIL]Re: Requirements for PAKE schemes


On 29 Jan 2016, at 3:22 PM, Robert Moskowitz <rgm-sec@htt-consult.com> wrote:



On 01/29/2016 03:04 AM, Василий Долматов wrote:

29 янв. 2016 г., в 9:26, Stanislav V. Smyshlyaev <smyshsv@gmail.com> написал(а):

A major number of cryptography failures follows from incorrect embedding of lower-level protocols to high-level ones – if you prove the security of PAKE under specific assumtions on counter handling and then someone implements it without knowledge of them, you have a practical vulnerability. We do not create protocols for vacuum, we make them for practice and must write security considerations (a specific "Security considerations" section in RFC can be used for discussing these issues, if someone thinks that they are not important enough to be in the main part).
I think that idea of moving these recommendations and notice about importance of correct setting of these counters to the «Security consideration» section is a good one.

I agree.  It is the perfect use of "security considerations" for a security technlogy.  None of the old "this whole document is about security".  The security considerations should contain what the risks/threats to the technology is and point out what is done to address/mitigate them.

I’m not sure about that. These considerations are true for any PAKE. In fact, they’re true for any kind of password scheme. You could even make the case that they’re true for any authentication scheme, because letting the opponent keep guessing is at least creating a DoS on the attacked authentication server. 

We generally write in the Security Considerations section stuff that is relevant for that particular scheme, not for a whole class of schemes. So it may be fine to have a BCP document for “Deploying Password Authentication on the Internet”, but I don’t think we need some boilerplate text that goes into the security considerations of any password-related RFC.

Yoav