Re: [Anima-bootstrap] [Spasm] SHA1 usage in Anima-bootstrap voucher yang

Russ Housley <housley@vigilsec.com> Fri, 03 March 2017 20:43 UTC

Return-Path: <housley@vigilsec.com>
X-Original-To: anima-bootstrap@ietfa.amsl.com
Delivered-To: anima-bootstrap@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F2D71294ED for <anima-bootstrap@ietfa.amsl.com>; Fri, 3 Mar 2017 12:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 W3FcCA6M2z1l for <anima-bootstrap@ietfa.amsl.com>; Fri, 3 Mar 2017 12:43:12 -0800 (PST)
Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DAE1295C3 for <anima-bootstrap@ietf.org>; Fri, 3 Mar 2017 12:43:06 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 2485A30049F for <anima-bootstrap@ietf.org>; Fri, 3 Mar 2017 15:43:06 -0500 (EST)
X-Virus-Scanned: amavisd-new at mail.smeinc.net
Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 0qTpkcLJF8vy for <anima-bootstrap@ietf.org>; Fri, 3 Mar 2017 15:43:04 -0500 (EST)
Received: from new-host-5.home (pool-108-45-101-150.washdc.fios.verizon.net [108.45.101.150]) by mail.smeinc.net (Postfix) with ESMTPSA id 85A8230024A; Fri, 3 Mar 2017 15:43:04 -0500 (EST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Russ Housley <housley@vigilsec.com>
In-Reply-To: <14573.1488419571@obiwan.sandelman.ca>
Date: Fri, 3 Mar 2017 15:43:04 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com>
References: <18454.1488305685@obiwan.sandelman.ca> <14573.1488419571@obiwan.sandelman.ca>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/lS7JTueVHowtUKXliZe5fitndS4>
Cc: SPASM <SPASM@ietf.org>, anima-bootstrap <anima-bootstrap@ietf.org>
Subject: Re: [Anima-bootstrap] [Spasm] SHA1 usage in Anima-bootstrap voucher yang
X-BeenThere: anima-bootstrap@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Mailing list for the bootstrap design team of the ANIMA WG <anima-bootstrap.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima-bootstrap/>
List-Post: <mailto:anima-bootstrap@ietf.org>
List-Help: <mailto:anima-bootstrap-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima-bootstrap>, <mailto:anima-bootstrap-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2017 20:43:14 -0000

> On Mar 1, 2017, at 8:52 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
> 
> 
> In the ANIMA ownership voucher YANG model, the absolute latest which you can
> currently see at:
>   https://github.com/anima-wg/voucher/blob/master/draft-ietf-anima-voucher-01.txt
> 
> we write at line 574:
> 
> leaf subject-hash {
>    type binary;
>    description "The certificate's entire subject field MUST
>              match this value.  This value is calculated as the SHA-1
>              hash over the TBSCertificate's subject structure, as
>              specified by RFC 5280 Section 4.1.2.6, encoded using
>              the ASN.1 distinguished encoding rules (DER), as
>              specified in ITU-T X.690.
> 
>              Note: by using the SHA-1 algorithm, the result can be
>              easily compared to OpenSSL's 'subject_hash'
>              output.";
> }
> 
> The voucher is a signed artifact (PKCS7? JWT? CWT? TBD) which indicates to a
> particular device who the devices owner is. ("Are you my mummy?" for Dr.Who Fans)
> 
> For reasons of key hygiene and longevity, in many cases we do not want to
> point at the public key of the registrar directly, but rather indicate that
> it's DN=Foo, as signed by CA=Bar.   It seems like there ought be a better way
> to do this kind of thing than what we specify above, which is annoyingly SHA1
> linked.
> 
> Can SPASM offer any advice?
> 
> We could list the actual DER itself. Encoded, it might actually not be bigger
> than a SHA256, for instance.  That might have privacy implications though,
> which we'd need to think through.
> 
> Some time ago, I proposed replicating the SIDR artifact (RFC3779), and copy
> and pasted it to make:
>    https://www.ietf.org/archive/id/draft-richardson-anima-idevid-cert-00.txt
> 
> but, we didn't really want to go exactly that way.

Michael:

I’m sure you know that there are three important properties for hash
functions.  The are:

(1) collision resistance: it is computationally infeasible to find two
    different inputs that hash to the same output; that is, it is really
    hard to find a and b such that H(a) = H(b).

(2) preimage resistance: it is computationally infeasible to find any
    input that hashes to a given output; that is, given y, it is really
    hard to find x such that H(x) = y.

(3) second-preimage resistance: it is computationally infeasible to find
    a second input which has the same output as a specified input; that
    is, given x, it is really hard to find y such that H(x) = H(y).

Google has announced a collision for SHA-1.  They found to PDF files
that produce the same SHA-1 hash value.

In the system you describe, it seems that an attacker would need to
find a preimage.  For SHA-1, we do not know of a way to do that yet,
but the 160-bit have value produced by SHA-1 is probably not big enough
to be considered safe in today's computing environment.

It seems very odd to be developing a new standards that is using a hash
function that was deprecated at the end of 2010 by NIST.

My personal recommendation ould be to move from SHA-1 to SHA-256.

Russ