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

"Grigory Marshalko" <marshalko_gb@tc26.ru> Sat, 30 January 2016 12:15 UTC

Return-Path: <marshalko_gb@tc26.ru>
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 4B26E1A1A3B for <cfrg@ietfa.amsl.com>; Sat, 30 Jan 2016 04:15:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.369
X-Spam-Level: *
X-Spam-Status: No, score=1.369 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, 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 LVkIwIyikrZV for <cfrg@ietfa.amsl.com>; Sat, 30 Jan 2016 04:15:56 -0800 (PST)
Received: from mail.tc26.ru (mail.tc26.ru [188.40.163.82]) by ietfa.amsl.com (Postfix) with ESMTP id 89D3A1A0030 for <cfrg@irtf.org>; Sat, 30 Jan 2016 04:15:56 -0800 (PST)
Received: from mail.tc26.ru (localhost [127.0.0.1]) by mail.tc26.ru (Postfix) with ESMTPSA id 9F111300302; Sat, 30 Jan 2016 15:15:32 +0300 (MSK)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.tc26.ru 9F111300302
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tc26.ru; s=mx; t=1454156154; bh=xBvAUyAkHQkZRtdajARXJ4hno1cwco1bOhr/ebZZ8zw=; h=Date:From:Subject:To:Cc:In-Reply-To:References:From; b=WIUqMNJw07Xxw5NcWK96liOSuOha29CQvgHHwCDElQ202d+5PNv2L5lj7e+7Gymhb XSkgGje8S8kDXIvbrsMHROcNF36WECouysP1muP/Cc0GysE3F8mlM92jdNX09C68zp O0QrKaXFf6kOLqF3OI3rj5j/se6Kz/01FePnJDxE=
Mime-Version: 1.0
Date: Sat, 30 Jan 2016 12:15:32 +0000
Content-Type: multipart/alternative; boundary="--=_RainLoop_480_405594123.1454156132"
Message-ID: <01a1b24557860d5e2afc8349d55d6ca5@mail.tc26.ru>
X-Mailer: RainLoop/1.9.3.365
From: Grigory Marshalko <marshalko_gb@tc26.ru>
To: Yoav Nir <ynir.ietf@gmail.com>, Robert Moskowitz <rgm-sec@htt-consult.com>
In-Reply-To: <30BB5B38-9DC3-4DC1-968C-F3A2AC293E6F@gmail.com>
References: <30BB5B38-9DC3-4DC1-968C-F3A2AC293E6F@gmail.com> <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>
X-KLMS-Rule-ID: 1
X-KLMS-Message-Action: clean
X-KLMS-AntiSpam-Lua-Profiles: 90457 [Jan 30 2016]
X-KLMS-AntiSpam-Version: 5.5.6
X-KLMS-AntiSpam-Envelope-From: marshalko_gb@tc26.ru
X-KLMS-AntiSpam-Rate: 0
X-KLMS-AntiSpam-Status: not_detected
X-KLMS-AntiSpam-Method: none
X-KLMS-AntiSpam-Moebius-Timestamps: 3938831, 3938842, 3938434
X-KLMS-AntiSpam-Info: LuaCore: 407 407 95088b6730bc8abe9b35391686e3291f9b43d2f2, Auth:dkim=none
X-KLMS-AntiSpam-Interceptor-Info: scan successful
X-KLMS-AntiPhishing: Clean, 2016/01/26 12:51:30
X-KLMS-AntiVirus: Kaspersky Security 8.0 for Linux Mail Server, version 8.0.1.721, bases: 2016/01/30 07:35:00 #6896333
X-KLMS-AntiVirus-Status: Clean, skipped
Archived-At: <http://mailarchive.ietf.org/arch/msg/cfrg/LEYhOyuMXw3Uz7wClBZJgyQ3TsE>
Cc: cfrg@irtf.org, "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
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:15:58 -0000

It is very important to have such security considerations be written somewhere, especially if they are common and obvious for security experts. The problem is that for many implementors they are not obvious, and this is always the root of flawed implementations.

Regards,
Grigory Marshalko,
expert,
Technical committee for standardisation "Cryptography and security mechanisms" (ТC 26)
www.tc26.ru

30 января 2016 г., 12:50, "Yoav Nir"  написал:
 
 
On 29 Jan 2016, at 3:22 PM, Robert Moskowitz  wrote: 
 On 01/29/2016 03:04 AM, Василий Долматов wrote: 

29 янв. 2016 г., в 9:26, Stanislav V. Smyshlyaev  написал(а): 

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