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

[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