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

Sean Turner <sean@sn3rd.com> Fri, 03 March 2017 21:06 UTC

Return-Path: <sean@sn3rd.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 F0A18129505 for <anima-bootstrap@ietfa.amsl.com>; Fri, 3 Mar 2017 13:06:27 -0800 (PST)
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 (1024-bit key) header.d=sn3rd.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 TccebYNqt63V for <anima-bootstrap@ietfa.amsl.com>; Fri, 3 Mar 2017 13:06:26 -0800 (PST)
Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 272311295DC for <anima-bootstrap@ietf.org>; Fri, 3 Mar 2017 13:06:26 -0800 (PST)
Received: by mail-qk0-x22d.google.com with SMTP id 1so77686442qkl.3 for <anima-bootstrap@ietf.org>; Fri, 03 Mar 2017 13:06:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9wMP5ewi2ekReV3h+o0QiWmht9Co9egHBX1z4v01OMw=; b=GK2UTPzEdNlKFbcKPInC55fA/9oouT7SwVxAYYOzzPSPcgMPVbTpyHJVx6Cp6JWA9J CrYSK/nFm5aI5vkJnecdtow5HM0fj6Kbz28/OCt06vpCaPBsNc7oMm86Odp0cv+5024n drGovciEOWEViAc1pEEX83n2aSrZeT/a8BGxs=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9wMP5ewi2ekReV3h+o0QiWmht9Co9egHBX1z4v01OMw=; b=L3GoO4ucVgXtcR6V9UznXzpeZje6hTBtv93lavpBL9w+l48ehFqzHw8LmlM/wMxLzC a+o0cfCPjie/7dX6sGNuGPDwKnY3bfQiaOGM9kPu9mejD0cYTE9Od3Eh94dhdqwZ7Ci5 C3Ua5n84nVtxKEcrBf4aT/A4vBQKX2nhSsLnuG+OKHVkXbMuWRe+jpsw96BM/X9Twjhg CQ/DBtEGiL2XWumhcew7f7TnjlCck0/iax+OBfyyOpbzbyE9pTLwJDGJ1GC+GxqqF7QD WqpOJOIggI5tGnoY15D5nd1/z9CqWoo8Ftg5M2VFUgE2YgojRZioz4BmGyR7EIY1ZBXa 8sfg==
X-Gm-Message-State: AMke39mCYgdVTI00lLDaJAKEjl/ZWuCuO/qtVpXsrKliqEUfuleTmo+l/J9sXXXf0L8EwA==
X-Received: by 10.237.59.19 with SMTP id p19mr4840173qte.28.1488575184612; Fri, 03 Mar 2017 13:06:24 -0800 (PST)
Received: from [172.16.0.92] ([96.231.228.203]) by smtp.gmail.com with ESMTPSA id r189sm8349723qkf.58.2017.03.03.13.06.22 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 03 Mar 2017 13:06:23 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Sean Turner <sean@sn3rd.com>
In-Reply-To: <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com>
Date: Fri, 3 Mar 2017 16:06:21 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <E24F665F-B07E-4B34-9808-E13529022CCA@sn3rd.com>
References: <18454.1488305685@obiwan.sandelman.ca> <14573.1488419571@obiwan.sandelman.ca> <8C184CD7-69EB-424B-9D95-1C64A8FD706F@vigilsec.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima-bootstrap/moiMIstTw5fYLjHBoM24boAhpw4>
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 21:06:28 -0000

> On Mar 3, 2017, at 15:43, Russ Housley <housley@vigilsec.com> wrote:
> 
>> 
>> 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
> 

And, there’s an RFC for that (TM) :)
https://datatracker.ietf.org/doc/rfc7093/

spt