Re: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt

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

Many thanks, John!

Regarding a new document on different constructions for "improving
randomness", as I've just written to Riad (in the CFRG list) - I'll be
definitely happy to be involved in this, it seems really important (and,
maybe, arranging a discussion at CFRG at IETF 107 will be useful).
Don't mind if I'll get in touch with you off-list (to discuss, what should
be included in such a document) in the beginning of 2020? Would you like to
participate in this?

About the proposed changes in the I-D - I like all three of them.
Nick, Chris?


Best regards,
Stanislav


вт, 26 нояб. 2019 г. в 15:43, John Mattsson <[e-mail]>:

> Thanks for answers Stanislav!
>
> Stanislav V. Smyshlyaev wrote:
>
> >The security analysis can be modified for HMAC instead of Signature
> without
> >significant problems, I suppose. And also several useful alternative
> >constructions can be proposed (based on HMAC or DH as an operation with a
> >key).
>
> I think that would be a very useful thing for CFRG to do in a new draft.
> Even if you only look at TLS servers, they may only have a PSK (RFC 4279 or
> TLS 1.3), and in the future, they may only have a static DH key
> (draft-rescorla-tls-semistatic-dh-02). More good recommendations and
> concrete constructs for randomness is very needed practically. The ideas in
> the draft to
> use a context tag1, a nonce tag2, to split of inside HSM/outside HSM, and
> to prove the security of the construction are great.
>
> How to use randomness is also a topic for discussion (I don’t suggest
> inclusion in this draft). NIST (FIPS 186-5 Draft) is currently planning to
> include deterministic ECDSA but does not recommend it in general due to
> side-channel and fault attacks (https://eprint.iacr.org/2017/975.pdf).
> One of the recommendation in that paper is to calculate k based on the
> message, but with added noise, an approach implemented in several places
> such as https://signal.org/docs/specifications/xeddsa/
>
> >As an example, it can happen if CSPRNG used by some user gets its data
> based on a joint
> >system entropy pool, which can be affected by another user (an adversary).
>
> Ok, that is a good explanation why the attacker could control the CSPRNG
> but not other parameters. I would suggest adding that to the draft.
>
> >Which word would you suggest instead of “dynamically”?.
>
> unique or nonce would be better. Looking at the draft again, I think it
> would make sense to just rename tag2 to "nonce" and tag1 to "context". That
> make things easier to understand and aligns with other RFCs.
>
> >Yes, we’ve had a lot of discussions about whether to include this
> limitation (following
> >from the security assessment, see [SecAnalysis]) into the I-D – just for
> the reasons you
> >are talking about. But since we wanted our construction to be solid and
> well-proven for
> >all recommended cases, we decided not to omit this limitation. And you
> are right about
> >the encoding issue – the thing is that in the security assessment we
> assume that tag2
> >can have 2^L’.
>
> If you keep the limitation, I think you need to add more clarification and
> guidance to the reader.
>
> - The limitation the construction cannot output more than L + L' bytes for
> each nonce tag2 would be good to write in a sentence.
> - Given a fixed L (e.g. 32 in HMAC-SHA-256) and a need to generate N byte
> of randomness. Should the implementer then choose a N - L byte encoding for
> the counter tag2? (Even after reading [SecAnalysis], I do not understand
> why the encoding of tag2 would affect the output length n). Or should the
> implementer choose a small L' and then generate several outputs (with
> different tag2) and concatenate?
> - Is L' fixed or can the implementation choose different encoding lengths
> for each value of tag2 depending on how many output bytes are needed.
> - When using a function with fixed-length output like HMAC-SHA-256 the
> value of L is given. When using a function with variable-length output like
> KMAC128 the value L is set by the user. Any recommendation there, or are
> all values of L equally good?
> - Is L fixed or can the implementation use different L for different
> values of tag1?
>
> /John
>
> -----Original Message-----
> From: Cfrg <[e-mail]> on behalf of "Riad S. Wahby" <
> [e-mail]>
> Date: Sunday, 24 November 2019 at 22:37
> To: "Stanislav V. Smyshlyaev" <[e-mail]>
> Cc: "[e-mail]" <[e-mail]>
> Subject: Re: [Cfrg] I-D Action:
> draft-irtf-cfrg-randomness-improvements-08.txt
>
>     "Stanislav V. Smyshlyaev" <[e-mail]> wrote:
>     > But this makes the scope of the I-D (initially motivated by TLS
> servers)
>     > wider - a "menu of choices" of good solutions instead of one good
> solution.
>     > If we want to do this, then, as it seems to me, the current process
> with an
>     > I-D, which has already passed the RGLC and has moved to Waiting for
>     > Document Shepherd stage, should be stopped and returned to the
> previous
>     > stage of a work item before RGLC.
>
>     In this case, it seems like a separate document for other constructions
>     is definitely more appropriate---no sense introducing serious delay for
>     this document.
>
>     But: would it be possible to clarify, maybe just in the intro, that
> this
>     document is primarily geared toward the HSM case?
>
>     -=rsw
>
>     _______________________________________________
>     Cfrg mailing list
>     [e-mail]
>
> https://protect2.fireeye.com/v1/url?k=d36fcb1e-8fe51eaa-d36f8b85-866a015dd3d5-c0d8356a21bc1bcc&q=1&e=4d7edf27-0f3a-48d3-885e-ec53b1141db0&u=https%3A%2F%2Fwww.irtf.org%2Fmailman%2Flistinfo%2Fcfrg
>
>
>