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

John Mattsson <john.mattsson@ericsson.com> Tue, 26 November 2019 12:43 UTC

Return-Path: <john.mattsson@ericsson.com>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 249B21208C2 for <cfrg@ietfa.amsl.com>; Tue, 26 Nov 2019 04:43:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com
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 kaCkSJtDy9up for <cfrg@ietfa.amsl.com>; Tue, 26 Nov 2019 04:43:53 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-eopbgr140057.outbound.protection.outlook.com [40.107.14.57]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20DAC12081B for <cfrg@irtf.org>; Tue, 26 Nov 2019 04:43:52 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IQKGhW7wrlby1gSVXOSLDEKX7L8/VNZ3M1sda0Ar+IgvFI1hRvfjs+xbWrrVKHR9bO+Lrb8EYk4ZOknCfhZlxajxWsG4rxKJDYK4TIsMvp4S8nrOxCde1InVivGMjg4ulrkXVI97a/Op7p4HWqGc7+TxVM850KJMZrirHwhrNF/rKv63jTbZvJTfQ2Nynm2RS5ZQ7ZhIpf5fj4mhdmLK7qLL8X2j4S4PkHmsgzD9AcAUYKCM/DtveZ5RUaiPmJYlzVu9WYk/eMcx3UQNMgnSbtHhMU9s/JfLefM2zCrPwiNnxtwJnbdlvX8hu2JV9brXZBz7Urglbd8WEtV+ZoQO1w==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tgJ9Rdz2KRyfIJKZFSlwRUJ8OE6c3T2tYDrUwDMqiRM=; b=OH2q9QkTu+sWWFtgNKJ9fsy5d6Ac07LeCoA9WbZxL3C/ORw3MNtU9LnEx12vgKhMO2MQk90IQ4yH8x80dleFOPwv5AFNwPCDP1RviNBpqI21oAUc4bjddtuON91WiEMHQNOxMIYdBe/xOGNnZ10XPnp6b/+vrYoQvrXivMcECh+j/41aPKsULWxfJwRlZIQRG759Bqi6cR4btnoeLDCSxHI20BPHJpBgXtDelbg88FMT7qPG5kA2sttpcWTIw+rk4IEz1Gg6w/uaiYEsS7RFu9peGsFtoA4FOsKhySqo5gLp3G+gAaSyz1f4drylAVpBCx8e4p2Hu9OOeGHj1ep9uQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=tgJ9Rdz2KRyfIJKZFSlwRUJ8OE6c3T2tYDrUwDMqiRM=; b=jw4HkuvgdF51XoMaRlo4n8osUIOc4xx0u0q+ytFSf5YLnHwPsgv73VQoLF1cctk9KM9VM6F+Thm30RdMUd8+fWN77UQcG57OZzsL0nTGUmhUS1EfzntZP+9piKbQeB+3rQEpRgEehKNsPrBEGV250snDoQZvNOFkOrwKKjXpcWM=
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com (20.176.165.153) by HE1PR07MB4154.eurprd07.prod.outlook.com (20.176.166.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.10; Tue, 26 Nov 2019 12:43:50 +0000
Received: from HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::21e5:eaae:99ed:41ac]) by HE1PR07MB4169.eurprd07.prod.outlook.com ([fe80::21e5:eaae:99ed:41ac%3]) with mapi id 15.20.2495.014; Tue, 26 Nov 2019 12:43:50 +0000
From: John Mattsson <john.mattsson@ericsson.com>
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>, "Riad S. Wahby" <rsw@jfet.org>
CC: "cfrg@irtf.org" <cfrg@irtf.org>
Thread-Topic: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt
Thread-Index: AQHVkdcWzFRsDTDWKUiQumkHNsH2iKeVR5sAgABFg4CAAfLNAIADD70AgABrWYCAAqBhgA==
Date: Tue, 26 Nov 2019 12:43:50 +0000
Message-ID: <3C55A6A2-080C-4230-AAEC-E2993F8F6167@ericsson.com>
References: <157273808364.6043.6715638492611593951@ietfa.amsl.com> <77AD232C-094D-4FC1-A966-DA56EC44A27F@ericsson.com> <CAMr0u6=7r2wAD_3Yn1hBjJW-y=8FE27jeYQW8wk3wJ-Xh2g2hg@mail.gmail.com> <20191122162758.kzx3vl4ibayykyqu@positron.jfet.org> <CAMr0u6=94uCjUybJ89Nf-qNvyKFPkX_KWM6k5u1kPUZMOCLNRw@mail.gmail.com> <20191124213717.o5gjtyv55lmlcy4s@positron.jfet.org>
In-Reply-To: <20191124213717.o5gjtyv55lmlcy4s@positron.jfet.org>
Accept-Language: en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1f.0.191110
authentication-results: spf=none (sender IP is ) smtp.mailfrom=john.mattsson@ericsson.com;
x-originating-ip: [192.176.1.86]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9266f018-48b5-4035-3543-08d7726e49b5
x-ms-traffictypediagnostic: HE1PR07MB4154:
x-microsoft-antispam-prvs: <HE1PR07MB41544D34A6C402A2857DB03D89450@HE1PR07MB4154.eurprd07.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0233768B38
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(396003)(136003)(376002)(39860400002)(199004)(189003)(51444003)(13464003)(76176011)(186003)(81156014)(8676002)(6512007)(6506007)(81166006)(2616005)(6306002)(53546011)(446003)(26005)(102836004)(14454004)(305945005)(11346002)(8936002)(5660300002)(478600001)(3846002)(6246003)(25786009)(966005)(4326008)(86362001)(229853002)(91956017)(7736002)(44832011)(6486002)(64756008)(58126008)(76116006)(6436002)(6116002)(33656002)(110136005)(316002)(66476007)(66446008)(36756003)(66946007)(66066001)(14444005)(2906002)(71200400001)(71190400001)(256004)(66556008)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB4154; H:HE1PR07MB4169.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bLNKbXfUWx6sTRtBzGn5A2+0KOQOTkKH8hVtJ7rfYcl4IuWp6CD2yc5Hl18X5ORZcGfUshkmdMsU1R3AK9EXxnTAThGENkFdLE+ZT9qnCXgAGSBOc7jcbG3Iv6FPd7nZ40A01FnxCOtqONQkJVp9yO0p8lXKQadXioFPBTW9jtIvSFlUkdnoXbCtpg0XDgJc6WmMjDEnD2Te4XvwbJmT2r376p3yrTJqpyIIfwWhM5b+yjz+3be+xb4Kn4Z6xthOXu0k/tJzP/eEdscnm4jJ1hFWX1+lKkv4y+wLdoNbyMBVr6y5S7f+sVdLUGQmL2fSJTBynhPi+iPvs/uW692TfrwwsTo7pxkA7jSFBNachui3LbUcJd9yhBN8JMbThxXZ/U7gZN1guMYLNSXEnaIggYnxUevyeRp7bE0EcW+uknSqYQCrTi+5mI9lcDgb9jofhzOZ8S/4dhFGIIrZ3S6oVPNBoTLfo78CcKRL78LzVRQ=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <60DF70A902243B429F30218E6493B203@eurprd07.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: ericsson.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 9266f018-48b5-4035-3543-08d7726e49b5
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2019 12:43:50.3916 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: hRWdMbuj7BlB39w44OT4XcF8wVNQR5cUAOhXehFeHN0EARI7MoMvH2yXo+mKAiyS4NcJkbHxJ0CqKiRCWrSCjyB3PBUXPXqAxY9sMTb1IHs=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB4154
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/8V4c68T3eXXWikphWlOwHDCixSI>
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
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: Tue, 26 Nov 2019 12:43:56 -0000

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 <cfrg-bounces@irtf.org>; on behalf of "Riad S. Wahby" <rsw@jfet.org>;
Date: Sunday, 24 November 2019 at 22:37
To: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>;
Cc: "cfrg@irtf.org"; <cfrg@irtf.org>;
Subject: Re: [Cfrg] I-D Action: draft-irtf-cfrg-randomness-improvements-08.txt

    "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>; 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
    Cfrg@irtf.org
    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