Re: [Cfrg] RGLC on draft-irtf-cfrg-randomness-improvements-05

"Martin Thomson" <mt@lowentropy.net> Thu, 04 July 2019 00:56 UTC

Return-Path: <mt@lowentropy.net>
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 2F8CB120179 for <cfrg@ietfa.amsl.com>; Wed, 3 Jul 2019 17:56:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=vTmlslBq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=QAZxb9Fn
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 J1uqlqPakYzv for <cfrg@ietfa.amsl.com>; Wed, 3 Jul 2019 17:56:48 -0700 (PDT)
Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499E01200D7 for <cfrg@irtf.org>; Wed, 3 Jul 2019 17:56:48 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 3D58221443 for <cfrg@irtf.org>; Wed, 3 Jul 2019 20:56:47 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute1.internal (MEProxy); Wed, 03 Jul 2019 20:56:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type; s=fm2; bh=zs/+Jmqyd4i9kplbhZG4P4n8TfZoOsO HFipBfp6ao1A=; b=vTmlslBqbA/eFguZL8kRdr7wjLXrOybWsg0AgYWp6BQvF1m qRm3Mjhp8moQd3K9OPl/K6v+i7+UGdt0x521Tw15oOFf43k5PtJX39SgkJ2p44of 055tMFiVkO8O9ob/Ue72QX8pQuo4sgqAlc5RWnI19aQuZmDSmKbqZeeVsIukQjUH 13F/j7JTkFR4AZhiffcj31LKXCtxgqnFjF0FX+tv4UTViqJednJBv/o8vG6uUhuQ WK0+RZ+FGf1HqKmYGjaeNKbpzSyt2/dUgJgAWfdwYY612nImniCFnglxwg36vFzb cMdND+2ifgCESJt1KovZxGy/SCWxqk35A89S07Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=zs/+Jm qyd4i9kplbhZG4P4n8TfZoOsOHFipBfp6ao1A=; b=QAZxb9FnFs1GYUV/Gzu5lK ZwuDVkApxDxTL9nOJtFTZfpQ86+vo1F7psDPlAcs/C2u9IYp+FdjwZYUjbJTq6ws rWL7o+zAvGq+oSQK1CAWgx4s4JHugPwEALZbV886V+e1IYgNQGclqoqJJGoLkZWM zTD2So5aETJNWkKL3qKbIH0kdD5yoA/iDm+6WxZuKBQmRI3f+Xv7eNeUDxXuaaIf Q6VZblO9J7z7tY18o6q/U0QhE6zDnHarAck9sGDiMjV/8rOCe4v+JL8yq1p7FG3n QUG55MyjdrS6vu7MSBnhAlfsnv5wslfWvIXI7pvl+GlLka0hHIx3jY7bUVIDI6kQ ==
X-ME-Sender: <xms:zk4dXeNCfwNvjj8JycPlehI_JhFGnyUwlouI3s_2Fy74EFqdt6zOjg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduvddrfedugdegudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesthdtre dtreertdenucfhrhhomhepfdforghrthhinhcuvfhhohhmshhonhdfuceomhhtsehlohif vghnthhrohhphidrnhgvtheqnecuffhomhgrihhnpehirhhtfhdrohhrghenucfrrghrrg hmpehmrghilhhfrhhomhepmhhtsehlohifvghnthhrohhphidrnhgvthenucevlhhushht vghrufhiiigvpedt
X-ME-Proxy: <xmx:zk4dXdgDHBJ_LLUvq7wrBR7zFKiZr_n6bqqzYX6ofdRzQS2U6Tgk2Q> <xmx:zk4dXWfBXhAIcp_IMGVYVIJgodbIPkTwN2R1Z2qx92DFm21ObfgI5Q> <xmx:zk4dXYb3R5MiBWFJ3vkwl8Bdr5MXIZY2GIyyhT4Lxvw16muFN7pXdA> <xmx:z04dXU-TTwrs_vDoNyu-qEerYoNNwVbB0UTOr4VoMJKwWCm8kVCLmQ>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 9969AE00A2; Wed, 3 Jul 2019 20:56:46 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.1.6-731-g19d3b16-fmstable-20190627v1
Mime-Version: 1.0
Message-Id: <4fd28f76-0bde-4c91-8ddc-2b3fab0b298e@www.fastmail.com>
In-Reply-To: <3644133e-93c2-e5bf-b39b-04e4423becc5@isode.com>
References: <3644133e-93c2-e5bf-b39b-04e4423becc5@isode.com>
Date: Thu, 04 Jul 2019 10:56:47 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: cfrg@irtf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/nJxuMtS5Of6WFemI1Zm8OFPIaNI>
Subject: Re: [Cfrg] RGLC on draft-irtf-cfrg-randomness-improvements-05
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: Thu, 04 Jul 2019 00:56:51 -0000

This is good, though I have a number of editorial comments, and a question (the answer to which seems important, but I am happy to be wrong).

The use of "let x be" in the first paragraph of Section 2 isn't necessary.  You don't use 'x' anywhere but in that statement, so it could be rephrased more simply.

   When properly instantiated, the output of a CSPRNG should be indistinguishable from a random string of bits.  However, as previously discussed, this is not always true.  To mitigate this problem, we propose an approach for wrapping CSPRNG output with a construction that mixes secret data into a value that may be lacking randomness.

In Section 2, the rules about release of Sig(..) are repeated:

   Sig(sk, tag1) should only be computed once for the lifetime of the
   randomness wrapper, and MUST NOT be used or exposed beyond its role
   in this computation.  

I believe that this is a "need only" rather than a "should only".  There is no requirement that the signature not be recalculated or replaced over time, only that there is no need to do so.  Use of "should" implies recommendation.  This follows from text that repeats this later: "In systems where signature computations are expensive, Sig(sk, tag1) may be cached."  Maybe only say this once.

  To achieve this, tag1 may have the format that
   is not supported (or explicitly forbidden) by other applications
   using sk.

The "may have the format" statement implies permissiveness in a 2119 sense, but the intent is to communicate a strategy for achieving the hard requirement.  Perhaps this could be reworded to say "If sk could be used for other purposes, then selecting a value for tag1 that is different than the form allowed by those other uses ensures that the signature is not exposed."  Is this statement better moved to Section 3, with only a forward reference here?

   In that case the relative cost of using G'(n) instead
   of G(n) tends to be negligible with respect to cryptographic
   operations in protocols such as TLS.  

You might instead say that the relatively inexpensive computational cost of HKDF dominates when comparing G' to G.

In Section 3, the "it" in this sentence isn't clear: "It is needed to address the problem of CSPRNG state cloning (see [RY2010]). "

The construction of tag2 is confusing.  I would instead say: "A nonce. That is, a value that is unique for each use of the same combination of G(n), tag1, and sk values.  The tag2 value can be implemented using a counter, or a timer, provided that the timer is guaranteed to be different for each invocation of G'(n)."

In Section 4, the recommended construction for tag1 fails to take into account some of the advice from Sections 3 and 7.  Specifically, it does not encode include information about the host.  And it does not explicitly point out that the value is constructed in a way as to be illegal in TLS 1.3 (because TLS 1.3 signature inputs all start with a sequence of 0x20).

And, buried at the bottom, the question:

I'm sure that the analysis covers this, but what are the concrete requirements on the randomness extraction and expansion functions?  You use HKDF as an example, but you don't restrict this to HKDF.  That implies some properties, but as we learned from TLS analysis, there are properties that HKDF provides that we might rely on that are different than a generic KDF function.  For TLS, one property we rely on HKDF providing is collision resistance (which follows from its use of collision-resistant hash functions).  It would appear here that this relies on preimage resistance.  As the intro says H(x, sk) might be sufficient, but that implies that H() provides preimage resistance.  This is never stated, but it seems rather important.

On Wed, Jul 3, 2019, at 23:57, Alexey Melnikov wrote:
> Dear CFRG participants,
> 
> This message is starting 2 weeks RGLC on 
> draft-irtf-cfrg-randomness-improvements-05 ("Randomness Improvements 
> for Security Protocols"), that will end on July 17th 2019. If you've 
> read the document and think that it is ready (or not ready) for 
> publication as an RFC, please send a message in reply to this email or 
> directly to CFRG chairs (Kenny Paterson <kenny.paterson@inf.ethz.ch> 
> and Alexey Melnikov <alexey.melnikov@isode.com> in this case). If you 
> also have detailed comments, these woulbe be very helpful at this point.
> 
> Thank you,
> 
> Alexey, for CFRG chairs.
> 
> 
> 
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>