Re: [Cfrg] Requirements for PAKE schemes

["Stanislav V. Smyshlyaev" <[e-mail]>]

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 написал:

> 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:[e-mail] <javascript:;>] Im Auftrag von
> Stanislav V. Smyshlyaev
> Gesendet: Samstag, 30. Januar 2016 13:27
> An: Grigory Marshalko
> Cc: [e-mail] <javascript:;>; 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 <[e-mail]
> <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,
>         Technical committee for standardisation "Cryptography and security
> mechanisms" (ТC 26)
>         www.tc26.ru
>
>         30 января 2016 г., 12:50, "Yoav Nir" <[e-mail]
> <javascript:;> <mailto:[e-mail]
> <javascript:;>%3E> > написал:
>
>
>
>
>                         On 29 Jan 2016, at 3:22 PM, Robert Moskowitz <
> [e-mail] <javascript:;>> wrote:
>
>
>                         On 01/29/2016 03:04 AM, Василий Долматов wrote:
>
>
>
>                                         29 янв. 2016 г., в 9:26, Stanislav
> V. Smyshlyaev <[e-mail] <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
>
>
>

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