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

From: Schmidt, Jörn-Marc <[email-masked]>
Date: Tue, 9 Feb 2016 07:36:48 +0000

Hi Stanislav,

Please excuse my late answer.

I think the draft contains the requirement to control the number of attempts implicitly in the "Security of PAKEs" section: Eve needs to interact with a legitimate party and cannot perform offline attacks.
Maybe it would be worth adding a sub-clause in this section that mentions the tradeoff between security (minimal number of wrong tries) and risk of DoS attacks. This way, the statement is clear, but in the running text it would not cause the reader to skip the rest. What do you think?

Best regards,

Jörn

-----Ursprüngliche Nachricht-----
Von: Cfrg [mailto:[email-masked]] Im Auftrag von Stanislav V. Smyshlyaev
Gesendet: Samstag, 30. Januar 2016 13:27
An: Grigory Marshalko
Cc: [email-masked]; Robert Moskowitz
Betreff: Re: [Cfrg] [MASSMAIL]Re: Requirements for PAKE schemes

‎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 the 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

2016-01-30 15:15 GMT+03:00 Grigory Marshalko <[email-masked]>:

	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" <[email-masked] <mailto:[email-masked]%3E> > написал:

			On 29 Jan 2016, at 3:22 PM, Robert Moskowitz <[email-masked]> wrote:

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

					29 янв. 2016 г., в 9:26, Stanislav V. Smyshlyaev <[email-masked]> написал(а):
					 
					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

---

From: "Stanislav V. Smyshlyaev" <[email-masked]>
Date: Tue, 9 Feb 2016 22:31:50 +0300

Hello, Jorn!

Thank you very much for your opinion. I agree with you and think this is a
smart way to go - we'll stress the importance of these issues, but nobody
will be obliged to add unnecessary text if it isn't really needed.

P.S.: We'll write a post to the mailing list about the accordance of our
SESPAKE draft to the requirements in a few days - maybe some new questions
regarding the requirements (and/or our SESPAKE RFC draft) may occur then.

Best regards,
Stanislav

вторник, 9 февраля 2016 г. пользователь Schmidt, Jörn-Marc написал:

> I think the draft contains the requirement to control the number of
> attempts implicitly in the "Security of PAKEs" section: Eve needs to
> interact with a legitimate party and cannot perform offline attacks.
> Maybe it would be worth adding a sub-clause in this section that mentions
> the tradeoff between security (minimal number of wrong tries) and risk of
> DoS attacks. This way, the statement is clear, but in the running text it
> would not cause the reader to skip the rest. What do you think?
>
> Best regards,
>
> Jörn
>
>
>
>
> Von: Cfrg [mailto:[email-masked] <javascript:;>] Im Auftrag von
> Stanislav V. Smyshlyaev
> Cc: [email-masked] <javascript:;>; Robert Moskowitz
> 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 the
> 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".
>
> 2016-01-30 15:15 GMT+03:00 Grigory Marshalko <[email-masked]
> <javascript:;>>:
>
>
>
>         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,
>         30 января 2016 г., 12:50, "Yoav Nir" <[email-masked]
> <javascript:;> <mailto:[email-masked]
> <javascript:;>%3E> > написал:
>
>
>
>
>                         On 29 Jan 2016, at 3:22 PM, Robert Moskowitz <
> [email-masked] <javascript:;>> wrote:
>
>
>                                         29 янв. 2016 г., в 9:26, Stanislav
> V. Smyshlyaev <[email-masked] <javascript:;>> написал(а):
>
>                                         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
>
>
>

-- 
С уважением,
Станислав Смышляев, к.ф.-м.н.,
Начальник отдела защиты информации ООО "КРИПТО-ПРО"