Re: [Crypto-panel] Request for review: draft-irtf-cfrg-randomness-improvements

"Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com> Mon, 09 March 2020 15:32 UTC

Return-Path: <sfluhrer@cisco.com>
X-Original-To: crypto-panel@ietfa.amsl.com
Delivered-To: crypto-panel@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F392A3A129A for <crypto-panel@ietfa.amsl.com>; Mon, 9 Mar 2020 08:32:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=mKSeR2mN; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tqqhKy5E
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 w1Yg5P0TnYO5 for <crypto-panel@ietfa.amsl.com>; Mon, 9 Mar 2020 08:32:15 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 866D83A12C7 for <crypto-panel@irtf.org>; Mon, 9 Mar 2020 08:32:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5396; q=dns/txt; s=iport; t=1583767935; x=1584977535; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=G1yHKv5sLSm9AiMYwXqOQklnhh15UDY8zv3cCx/1iyA=; b=mKSeR2mNYVhqyF3RAXnGPzpbbi24EQtqZjbvZg2KWJax0ptmyjYmafUo bNH9jMcMfs38fOU7dRXwq+xVHL7RLjTpjTV9c5NFA9fkTtxww3EeKk30Q Ng5rKAZB4XdbJFbMULHYmOGPci7qXDk7ITmquNho3ruyl3B+Hx05DOs+P c=;
IronPort-PHdr: 9a23:FwpYcRXqbsSmMgBqGHX6M8ZUoenV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdE7KdehAk8GIiAAEz/IuTtankhEsBfVEVo5VmwMFNeH4D1YFiB6nA=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CMAACaYGZe/4oNJK1mGQEBAQEBAQEBAQEBAQEBAQEBEQEBAQEBAQEBAQEBgXuBVCknBWxYIAQLKgqHUQOKa4JfiWOOMoFCgRADVAkBAQEMAQEYCwoCBAEBg35FAoIOJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVjAQEBAQMBARAoBgEBLAsBCwQCAQgRBAEBAR4QIQYLHQgCBAENBQgagwWCSgMuAQ6dIgKBOYhigieCfwEBBYFDQYMDDQuCDAMGgTiKaYFDGoFBP4ERR4JNPmsZAYEWSQEBAgEBgSc8g0GCLK9kRAqCPIdSil6EUps1RI4yiHyCMZAkAgQCBAUCDgEBBYFpIoFYcBU7gmxQGA2OHQsYgQQBAoJJhRSFQXSBKYxVAYEPAQE
X-IronPort-AV: E=Sophos;i="5.70,533,1574121600"; d="scan'208";a="730779792"
Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Mar 2020 15:32:14 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 029FWErl030674 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Mar 2020 15:32:14 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Mar 2020 10:32:14 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 9 Mar 2020 11:32:12 -0400
Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 9 Mar 2020 10:32:12 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=T0EBP5TQLqrftoJrG1lawQOL+4mRQRcaESw8pZTTwTnSrxxlx19Z3x13hSokGawFJS9lKv6rZzueAqmXTKXCe4r2dqDRkXk0V33ndaycwHx5oDRpnVIilCuYYs+S/f5Cw8mHjeeeRvxndM8nhkh6vZMo9FAyzl/41sCCSln50bapR0FUJiUwd2euAsekNpIQFBGrmxWCN/IsLDh50VzNLU9vHo6UeepWwqAzmzhGuFaxBw3pN3lavnp5CE0XJwvjICUerYs0CEicMz2HLTkHgF9pUqKDwChpV9n35XSrql5fndRtRFH+sjv4jwgGeTwkl/pKPctBW/+FmWVQiBrrrg==
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=6BiJHQ44eJsloihdkDLCR9k/H+l6xvDQWWHxWL30xmY=; b=l5BED6HoXo0g/dGN8jo7JiiUwbAnZkHCw8Idxq07zQCg4C1jA5qjwRgFsp4GXguBki77Or5cOqfL4v6wVygrBVE11bCL74VZSwE6R+pRqeB2IMsR4rp/GrBqUDvSPdSJ6Ct1prlgagUJYJKM0oPl6DkeLFsnEcZYvH5Si+LmMG43+bfRtlXNFj1nyU9lFBXlHfD8C2OHuSqQStF3wuzmKMqw6nTvq2zxJcY5Ax0UvthPLJdUqUUncsWTpIjol68IgJZDHx2ZtRfWMbTpOhA0+XZXqIzAMCrqDGqvPr9MwwHYn47Jyr+7hlHkOSGEuK9D/zm+EgeckEr02zvPa9SExw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=6BiJHQ44eJsloihdkDLCR9k/H+l6xvDQWWHxWL30xmY=; b=tqqhKy5Ebpji2QT+EzhKSvvGBO9UpKsKMVdPF7+u2Sm277gde06lbzubQfeO236BQDFEHUPjYfDZwyXaMwef9YkT1MWI/XIsZIOl9PR8PpPSTcScl/TR3XV/ypKr9TWQ9yWQ8+U51XH5aNJrIl0FGRuJXpN8IfBvEgf2DHJ9YyU=
Received: from MN2PR11MB3936.namprd11.prod.outlook.com (2603:10b6:208:13f::15) by MN2PR11MB4350.namprd11.prod.outlook.com (2603:10b6:208:191::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2793.16; Mon, 9 Mar 2020 15:32:11 +0000
Received: from MN2PR11MB3936.namprd11.prod.outlook.com ([fe80::71a0:2f72:8146:9d8]) by MN2PR11MB3936.namprd11.prod.outlook.com ([fe80::71a0:2f72:8146:9d8%6]) with mapi id 15.20.2793.013; Mon, 9 Mar 2020 15:32:11 +0000
From: "Scott Fluhrer (sfluhrer)" <sfluhrer@cisco.com>
To: "Scott Fluhrer (sfluhrer)" <sfluhrer=40cisco.com@dmarc.ietf.org>, Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>, Alexey Melnikov <alexey.melnikov@isode.com>
CC: "crypto-panel@irtf.org" <crypto-panel@irtf.org>
Thread-Topic: [Crypto-panel] Request for review: draft-irtf-cfrg-randomness-improvements
Thread-Index: AQHV897hwNWf+5+y5021R4+rBpxHuag7/gqAgAACruCABGTRUA==
Date: Mon, 09 Mar 2020 15:32:11 +0000
Message-ID: <MN2PR11MB39363F0E8F6FA26950EBB926C1FE0@MN2PR11MB3936.namprd11.prod.outlook.com>
References: <8290ee48-83f6-863c-c163-868251ea220b@isode.com> <8F8F5EC1-1F03-4FA0-82BB-780CF91B59B4@gmail.com> <MN2PR11MB393645204695482526854809C1E30@MN2PR11MB3936.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB393645204695482526854809C1E30@MN2PR11MB3936.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=sfluhrer@cisco.com;
x-originating-ip: [173.38.117.81]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 7c023cd0-60b2-438c-529a-08d7c43f0981
x-ms-traffictypediagnostic: MN2PR11MB4350:
x-microsoft-antispam-prvs: <MN2PR11MB4350BB9ACFD3BFB780DEBB6DC1FE0@MN2PR11MB4350.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0337AFFE9A
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(396003)(136003)(376002)(346002)(366004)(39860400002)(189003)(199004)(66446008)(4326008)(76116006)(478600001)(2906002)(71200400001)(64756008)(66556008)(66476007)(66946007)(52536014)(5660300002)(81166006)(8676002)(81156014)(8936002)(186003)(26005)(316002)(33656002)(110136005)(86362001)(7696005)(9686003)(53546011)(966005)(6506007)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4350; H:MN2PR11MB3936.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: bqaoVF+DmCQtAplQOD4NCtTPPoLOFJxxmo91DNmmKR6SqEKYePpq9Ba4Mf2Qh57CrmKJQ4vvWjqY+/ctyI7yIhMtA0KRxv+tIPdlOWutmxZOrMe06l0a2lhmRmFVdMWFPCbCSN974EHtqB8OfufxvF8uG91eXIWRFup4Ci4rjY9XU6YIVYlHJC4K8tf79w3bA9jC213czh6ov/50lPVdGl7WE6x6RDSJjSBRQTM1ixPrY+alpn7x9YVAWKa6F357bZFxqmutpip0OW8+SOXMbqayB1PVS9DXX2H8QTkWPdBOSm5PFvDKUg59QfTaESI9y/aNl+gDMgDOzGIts/saWZ1MFylS8wn2mgzR0RVo/SZcohE+2tj6q1zBlIZgOw/IKWY9Eimq2EU/BWOgGnr0+r3gBmrRBmf3BjLwIObszfDyfElUPBEqplZBIE06MDhfE4qrqxKKDw2aQbpKmsrP1rJqiT29z1oVXHKb5LOzQKDBXB05fOChimLEdfwyWmLV25+o53jykhYtqh+RbA0NTA==
x-ms-exchange-antispam-messagedata: BiGIryIq0LgdnEXkuA5V4UEqGjuWJ17SoAxMqKNoLoMoq8VdJdgugr0LOB8Sw8UE50sFtiC/URXdtE+M4GnZAxtWYGtoVQ3o09OtMlbaTQk8xxi1HReIeWQmneQy5l68iFUiTOptdiV50mQaRmRqyA==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 7c023cd0-60b2-438c-529a-08d7c43f0981
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2020 15:32:11.6759 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TuFeNcVan0BqDVAUcLg6oBT303B6pF72bv+vUdItsKws6WP5+w7N1RSaPu8zu6k1/HrCf6skkcIra8qeMPyRzg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4350
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: alln-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/crypto-panel/z83HNQ5iHE1__gTSPKA1aXGoQPs>
Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-randomness-improvements
X-BeenThere: crypto-panel@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <crypto-panel.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/crypto-panel/>
List-Post: <mailto:crypto-panel@irtf.org>
List-Help: <mailto:crypto-panel-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/crypto-panel>, <mailto:crypto-panel-request@irtf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2020 15:32:24 -0000

This draft looks quite good, congratulations to the authors.  However, because this review wouldn't feel complete unless I have some complaints, here are some nits:

Who is this draft targeted towards?  I believe that, at some point, we'll need an RFC detailed enough that we could give it to an implementor and be reasonably confident that he'll implement something secure.  Currently, this isn't that - it leaves far too many options open for an implementor (who may be somewhat ignorant of cryptography) to make bad choices.
Things that should be specified (and we could allow a range of selections)
	- What is Extract.  The draft gives as an example HKDF-Extract; with what hash function?
	- What is L (the size of output of the Extract function)?
	- What is H?
	- What is Expand (HKDF-Expand?)
Also, we might want to expand on the guidance relating to the generation of tag2 - I would suggest that we should mandate (or, at least, strongly suggest) that it consist of a timestamp (if a real time clock is available) and a counter (which is incremented on every invocation).  One issue with the current recommendation (needs to be unique for each combination of G(L), tag1 and sk values) is that might be difficult to ensure on a platform with no real time clock (and while this is not an ideal scenario, it will happen, and we shouldn't tell the user "you have to do this" when it may be infeasible.


The draft states that:
      We require that L >= n - L' for each value of tag2.

Why is this requirement here?  It would appear to me that, because tag2 is a potentially public string, its length is not specifically relevant to the security (as long as it is long enough that it never repeats).  One can certainly conceive of badly chosen options (L=1, L' = 32, n no more than 32) that is quite insecure but meets this criteria.
 

The draft states that:
	Sig MUST be a deterministic signature function, e.g., deterministic
	ECDSA [RFC6979], or use an independent (and completely reliable)
	entropy source
	...
	if the
	signatures are probabilistic and use weak entropy, our construction
	does not help and the signatures are still vulnerable due to repeat
	randomness attacks.
Why is this requirement here?  I would disagree with the reasoning; if the computation of Sig involves calls to a potentially weak RNG, it will still generate a valid signature; and (assuming that the private key and the signature scheme is secure), the attacker cannot guess any valid signature to a message.
If the concern is that a signature with a weak RNG might leak the private key (e.g. ECDSA), then I would note that this draft mandates that the signature not be leaked, and that it uses the hash of the signature (and the draft might want to give guidance that it's the hash that needs to be cached, and that the signature should be discarded immediately after the hash has been computed).


The document claims:
	the relatively inexpensive
	computational cost of HKDF dominates when comparing G' to G

I don't believe that is quite as true as the document hopes.  Most good CSRNGs run considerably faster than the HKDF Extract/Expand pair; hence G' is rather more expensive than the underlying G.  One could state that the cost of G' is generally considerably smaller than the protocol that's using G' (e.g. the ECDH operation).


In the tag1 section (in section 4), the document promises that section 5 will give additional advice on how some TLS protocol information could be used in generating a tag1 value.  Section 5 doesn't give any such guidance.


> -----Original Message-----
> From: Crypto-panel <crypto-panel-bounces@irtf.org> On Behalf Of Scott
> Fluhrer (sfluhrer)
> Sent: Friday, March 06, 2020 3:18 PM
> To: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>; Alexey
> Melnikov <alexey.melnikov@isode.com>
> Cc: crypto-panel@irtf.org
> Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-randomness-
> improvements
> 
> I'll go through it as well
> 
> > -----Original Message-----
> > From: Crypto-panel <crypto-panel-bounces@irtf.org> On Behalf Of
> > Karthikeyan Bhargavan
> > Sent: Friday, March 06, 2020 3:08 PM
> > To: Alexey Melnikov <alexey.melnikov@isode.com>
> > Cc: crypto-panel@irtf.org
> > Subject: Re: [Crypto-panel] Request for review:
> > draft-irtf-cfrg-randomness- improvements
> >
> > I can do a review as well.
> >
> > > On 6 Mar 2020, at 18:44, Alexey Melnikov <alexey.melnikov@isode.com>
> > wrote:
> > >
> > > Dear Crypto Panel members,
> > >
> > > I would like to request at least one review for this document:
> > <https://datatracker.ietf.org/doc/draft-irtf-cfrg-randomness-
> > improvements/>
> > >
> > > Thank you,
> > >
> > > Alexey
> > >
> > > _______________________________________________
> > > Crypto-panel mailing list
> > > Crypto-panel@irtf.org
> > > https://www.irtf.org/mailman/listinfo/crypto-panel
> >
> > _______________________________________________
> > Crypto-panel mailing list
> > Crypto-panel@irtf.org
> > https://www.irtf.org/mailman/listinfo/crypto-panel
> 
> _______________________________________________
> Crypto-panel mailing list
> Crypto-panel@irtf.org
> https://www.irtf.org/mailman/listinfo/crypto-panel