IETF Logo Mail Archive

Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad

Linus Nordberg <linus@sunet.se> Mon, 22 May 2017 17:38 UTC

Return-Path: <linus@sunet.se>
X-Original-To: trans@ietfa.amsl.com
Delivered-To: trans@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFAA512EAEE for <trans@ietfa.amsl.com>; Mon, 22 May 2017 10:38:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.092
X-Spam-Level:
X-Spam-Status: No, score=-4.092 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (bad RSA signature)" header.d=sunet.se
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 OU9rD702ejAB for <trans@ietfa.amsl.com>; Mon, 22 May 2017 10:38:15 -0700 (PDT)
Received: from e-mailfilter02.sunet.se (e-mailfilter02.sunet.se [IPv6:2001:6b0:8:2::202]) (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 51F09126C2F for <trans@ietf.org>; Mon, 22 May 2017 10:38:15 -0700 (PDT)
Received: from smtp1.nordu.net (smtp1.nordu.net [109.105.111.32]) by e-mailfilter02.sunet.se (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v4MHcCfr010961 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 19:38:12 +0200
Received: from flogsta (smtp.adb-centralen.se [IPv6:2001:6b0:8:0:0:0:0:129] (may be forged)) (authenticated bits=0) by smtp1.nordu.net (8.15.2/8.14.7) with ESMTPSA id v4MHc4Ys024373 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 22 May 2017 17:38:10 GMT
VBR-Info: md=sunet.se; mc=all; mv=swamid.se
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=sunet.se; s=default; t=1495474692; bh=gxQlTm8LaN2fCQxAOlnfBdJrKe8intReJFnHc2AOg7g=; h=From:To:Cc:Subject:References:Date:In-Reply-To; b=Wlr7VcJAwg3sSR+7y9b6m0h6ou+WAadl3X9xz7ltxcZhlYvpW0k78myM/M6DU4Rjg AVvI3DqSwri9R5uHskI89fF8qEHfY+DJiUt5ca8nIwrsT1AfqKQA1vj7muNjSzaDUX xgNZdzjd+rWF/PJR1RTYxhUZsFnmFXw6muwzMRyM=
From: Linus Nordberg <linus@sunet.se>
To: Gary Belvin <gdb@google.com>
Cc: Eran Messeri <eranm@google.com>, "trans@ietf.org" <trans@ietf.org>
Organization: Sunet
References: <CAFewVt5z3sq-Occ1VaHeNeBvt1yyCM_3_nssZSu2f_PBEL4SFQ@mail.gmail.com> <CA+cU71kBmKsxyvsmpuF6UAzP+fict3v62gEq_iKY-O2P07ZRLw@mail.gmail.com> <87pofiif6g.fsf@nordberg.se> <CA+cU71kVV_o30p-+dGdLT9Hpg+iiW5KgG-9xJD9iVCEHwhLg6w@mail.gmail.com> <CALzYgEeHpxRSxpQTSPasdahWXdzV8bGMV_R4HM02oscHrm8TWw@mail.gmail.com> <87inl25r8l.fsf@nordberg.se> <CALzYgEdunZXRmGtStGhfJHdHeytk3etYLNtAvFgf3bN2-6EyXQ@mail.gmail.com> <CALzYgEeCVnWG19F79OSwCC+iPArZbGGaBZYrKP2MWWdEDGVHVg@mail.gmail.com> <871srhvunx.fsf@nordberg.se> <CADgN-woFUCU-LiYgZt-i+wnRXzjTmruCXCz=4pruNV4qwj_=og@mail.gmail.com>
Date: Mon, 22 May 2017 19:38:24 +0200
In-Reply-To: <CADgN-woFUCU-LiYgZt-i+wnRXzjTmruCXCz=4pruNV4qwj_=og@mail.gmail.com> (Gary Belvin's message of "Mon, 22 May 2017 15:16:24 +0000")
Message-ID: <87shjwu6zz.fsf@nordberg.se>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Scanned-By: CanIt (www . roaringpenguin . com) on 192.36.171.202
X-Scanned-By: MIMEDefang 2.74
X-p0f-Info: os=unknown unknown, link=Ethernet or modem
X-CanIt-Geo: ip=109.105.111.32; country=SE; latitude=59.3247; longitude=18.0560; http://maps.google.com/maps?q=59.3247,18.0560&z=6
X-CanItPRO-Stream: outbound-nordu-net:outbound (inherits from outbound-nordu-net:default, nordu-net:default, base:default)
X-Canit-Stats-ID: 0aTntCcCM - 5d3335abbd65 - 20170522
X-CanIt-Archive-Cluster: PfMRe/vJWMiXwM2YIH5BVExnUnw
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/IdTxWj0W-QXCjEdvFOWCEjgGwaQ>
Subject: Re: [Trans] The RFC6979 requirement in RFC6962-bis is bad
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 22 May 2017 17:38:18 -0000

Gary Belvin <gdb@google.com> wrote
Mon, 22 May 2017 15:16:24 +0000:

>> return a different stream of bytes for the same ingoing parameters, for SCTs
> and STHs.
> In addition to fixing signature randomization, wouldn't one also need to
> fix the inputs to the signature? Timestamps in particular and any server
> supplied data that wasn't directly tied to the leaves themselves would seem
> to be a problem.

Yes. My understanding is that they are all under control.

For STH's: The log id is fixed. The number of timestamps, the tree size
and the root hash are limited by the STH frequency count. The extensions
field is unused.

For SCT's: The log id is fixed. Timestamps are limited by the visibility
in the log and the cost of storage forever. The extensions field is
unused. None of issuer key hash and (pre-) certificate in the
timestamped entry are server supplied.

Please let us know if we're missing something.

v2.23.0 | Report a Bug | By Email