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

[Sean Turner <[e-mail]>]

> On Mar 3, 2017, at 15:43, Russ Housley <[e-mail]> wrote:
> 
>> 
>> On Mar 1, 2017, at 8:52 PM, Michael Richardson <[e-mail]> 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