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

"Stanislav V. Smyshlyaev" <smyshsv@gmail.com> Sun, 24 November 2019 15:13 UTC

Return-Path: <smyshsv@gmail.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 E47671200D5 for <cfrg@ietfa.amsl.com>; Sun, 24 Nov 2019 07:13:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, 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=gmail.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 BbcDPy2goEPi for <cfrg@ietfa.amsl.com>; Sun, 24 Nov 2019 07:13:18 -0800 (PST)
Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 217331200C5 for <cfrg@irtf.org>; Sun, 24 Nov 2019 07:13:18 -0800 (PST)
Received: by mail-lj1-x230.google.com with SMTP id d5so12777816ljl.4 for <cfrg@irtf.org>; Sun, 24 Nov 2019 07:13:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HtUGy+7kfH28F9D6IKNduH2t9oRrzUylUj83ixvQoQM=; b=MqYBE0bR/GXurhUh5osDjqXtCEm2U7/Pjc2ciGhKMhQuTwd8AakkEUTH1KfjphW9ou Hj7StjH/VuN0bc31+IpiA8hbDODnxJ7oe/DXKkHXGCdsaitbOVHIScskm6F/7IMcuZmT cVaZG+AaHoH2QOrQngH+F2e6uv0DibSqNiGCg1a6zCcgrI75q+yNctRyCK6wxndOfO2m BSHbSHGUBOx6vVD4iq9jWpNlOfKVuxMY7xbhraed9tsnxlNuCx1fwvQVjEIW8JjAVnIG m4FfbXwC7x9HHm5zAkHaoo+Z2r+7Pa5qewc3qqKQM1ONfb1mlQqW0XSLyfv4TnHC9JaK Warg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HtUGy+7kfH28F9D6IKNduH2t9oRrzUylUj83ixvQoQM=; b=djCqW6tYIF56Kgj9YLjNYU+yDvW302G9tkk1TDMR8/Oy3+KR/qmQbLqn3JiEVYGiLG DiVGNgm8MVrPqMesnH8qr7WZgADagkOswyLWnFEmKU1Sum5p68X0ZJR7D2AMDHYeMEDc NjPdLlqX4/wVAhoM6sNmmQvyzNV9J4cA9yI1QkTHnRhpOA5JWW8NL8qz2COFay17gx8v bTZSoNgMN9v06ZOKPjIgF7nHyvg6BEQ77paA53C1AKoAXqLEgZtjtgzIZfGvl3X0q5Gb /4ammK9BQsWansYsSc3oua2oLljYAh607OS1hyN9k88L+8o7+wbfaEQG2vduTdP/ztr0 A04g==
X-Gm-Message-State: APjAAAU12etDiobZ3FtloY/T3uQWzFlulN1lK7t1U1GTUL9zeMH9aLOz EiZOCPgqCfp6Cu+SaN7W6ymDAWiaUFYOlYb4jao=
X-Google-Smtp-Source: APXvYqwepi00Gqiqb1G/qMddZZLCRalj8rRAHsYD/UGwXkXC/vwNTNY4J0/pUhg9BaOBbcOqcRyiSS7QMaOMr4t4Lm0=
X-Received: by 2002:a2e:a0ce:: with SMTP id f14mr19566031ljm.241.1574608396034; Sun, 24 Nov 2019 07:13:16 -0800 (PST)
MIME-Version: 1.0
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>
In-Reply-To: <20191122162758.kzx3vl4ibayykyqu@positron.jfet.org>
From: "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Sun, 24 Nov 2019 18:13:04 +0300
Message-ID: <CAMr0u6=94uCjUybJ89Nf-qNvyKFPkX_KWM6k5u1kPUZMOCLNRw@mail.gmail.com>
To: "Riad S. Wahby" <rsw@jfet.org>, Nick Sullivan <nick@cloudflare.com>, Christopher Wood <christopherwood07@gmail.com>, Christopher Wood <caw@heapingbits.net>
Cc: "cfrg@irtf.org" <cfrg@irtf.org>
Content-Type: multipart/alternative; boundary="0000000000001b297105981916d0"
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/5sowSgY-t5nMtfskem92CSjbU2M>
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: Sun, 24 Nov 2019 15:13:20 -0000

Thanks, Riad!

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).
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.

Personally, I really like the task of providing several good constructions
for "improving randomness" using various constructions - but I'm not sure
that it should be done in this document and not in a new one (Nick, Chris,
could you please share your opinion on this?..).

Best regards,
Stanislav



пт, 22 нояб. 2019 г. в 19:28, Riad S. Wahby <rsw@jfet.org>;:

> "Stanislav V. Smyshlyaev" <smyshsv@gmail.com>; wrote:
> > Yes, I believe that it can be a great future direction of work, but this
> > will be another construction, requiring additional security analysis
> etc. I
> > think that the topic of improving randomness will be always a very
> > important one, so a lot of other good ideas and good constructions may
> > arise in the future.
>
> I looked at the security analysis a while ago and although it's not
> fresh in my mind now, at the time I was convinced that the analysis
> applied almost directly to HMAC rather than a signature. Maybe I'm
> crazy, incompetent, or mis-remembering, though! :)
>
> As a more general point: the document's intro hints at this, but
> maybe it should be made more explicit that this protocol is geared
> towards the case where one's key is stored in an HSM. Sure, it works
> in other cases, but the choice to use signatures appears to be directly
> motivated by HSMs---otherwise, why not use a cheaper construction?
>
> -=rsw
>