Subject: Re: [Anima-bootstrap] voucher yang

From: Kent Watsen <[email-masked]>
Date: Wed, 1 Mar 2017 22:14:38 +0000

Hi Michael,

> Kent, thanks for the updates to the YANG for the voucher.
> Some comments:
>
>      leaf assertion {
>        description
>          "The assertion is a statement from the MASA regarding how
>           the owner was verified.   This statement enables pledges
>           to support more detailed policy checks.  Pledges MUST
>           ensure that the assertion provided is acceptable before
>           processing the voucher.";
>
>I think that it's more about the registrar than the pledge activity.

While the registrar can inspect the voucher, it ultimately must pass
it to the pledge unmodified.  Also, note that there no "registrar" 
concept in the NETCONF zerotouch draft.

>        leaf subject-hash {
>          type binary;
>          description
>
> Will there be an update to RFC5280 that will unlock us from SHA-1?
> Are all of subject-hash/cn-id/dns-id required, or is it one of the above?

As the description statement explains, SHA-1 is used because it is
interoperable with OpenSSL.  We could hardcode SHA-256, or even allow
it be to parameterized, but that would put more code on the pledges,
do you want to go this route?

>      leaf-list device-identifier {
>        type string;
>        min-elements 1;
>        description
>          "A non-empty list of POSIX regular expressions, each
>           identifying one or more device identifiers (e.g., serial
>           numbers). For instance, the expression could match just
>           a single serial number, or it might match a range of
>           serial numbers.
>
>           When processing a vouchers, pledges MUST ensure that their
>           unique identifier matches at least one regular expression in
>           the list.  If no matching regular expression is found, the
>           pledge MUST NOT process this voucher.";
>
> Oh, wow. I'd really rather not have a regex here!
> I'm more worried about the possible Turing-completeness of the regex rather
> than the code space issue.  I think in IoT, if the device hasn't got a
> regex parser, then the vendor just won't issue vouchers with regex in them,
> so that is okay.
> If we have to, I guess I'd rather have a PCRE if we can find a specification
> for that.

I'm okay with PCRE in theory, but I've read that a compiled stripped 
library is large, do you know?

>      leaf nonce {
>        type string;  // unit64?
>
> I think it should be binary?

A 'binary' type would allow the nonce to be any length octet sequence,
which is converted to base64 encoded string for JSON.  Is this what 
you want?

Kent

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Mar 2017 20:52:51 -0500

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 Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Mar 2017 21:39:27 -0500

> concept in the NETCONF zerotouch draft.

What I'm saying is that the pledge can't know how the owner was verified.
The pledge actually has to process the same as for "verified" as for
"logged".  It doesn't change the pledge's behaviour.

    > do you want to go this route?

If we have to pick something, let's pick SHA256 for now, or maybe, as I wrote
in the other message I CC to spasm, maybe we should just put the DER itself?

    > library is large, do you know?

I don't know. I don't want either :-)
If I have to pick a regex library (vs shell-style globbing...) then I'd
rather pick PCRE if we can find a stable reference.

    > which is converted to base64 encoded string for JSON.  Is this what

I want as much entropy in as small a space as possible.
string seems to waste 2-bits per byte if it's base64 encoded in a binary
format (CBOR).  If JSON has to base64 encode things, I'm okay with that.

I would assume that integers get network-byte order considerations which
might lead to implementation bugs, where as binary[8] (if such a thing
exists) would not.  I think uint64 might be too small.

---

From: Kent Watsen <[email-masked]>
Date: Thu, 2 Mar 2017 19:12:57 +0000

> "logged".  It doesn't change the pledge's behaviour.

But it does.  Some pledges may be coded to only support 'verified' vouchers.

> in the other message I CC to spasm, maybe we should just put the DER itself?

The DER itself works for me (the privacy concern seems minor).  It's also more
code (relative to just using an openssl command line option), but actually it's
one step less code than calculating the SHA256 fingerprint.

> If I have to pick a regex library (vs shell-style globbing...) then 
> I'd rather pick PCRE if we can find a stable reference.

As discussed in another thread, I'm beginning to think that we should
do away with having a single voucher for many devices, because we'd
want revocations to be as granular as possible.

> exists) would not.  I think uint64 might be too small.

Okay, let's change the nonce to a binary type.

Kent

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Mar 2017 09:12:33 -0500

> But it does.  Some pledges may be coded to only support 'verified'

I agree, but the verification involved can't be confirmed by the pledge.

    > The DER itself works for me (the privacy concern seems minor).  It's
    > also more code (relative to just using an openssl command line option),
    > but actually it's

A constrained device might not have a shell to run an openssl command line :-)

    > want revocations to be as granular as possible.

Good!

    > Okay, let's change the nonce to a binary type.

Can we say the nonce is 8 to 32 bytes in size?
If we have to pick a single number, I'd say 16 bytes.

---

From: Kent Watsen <[email-masked]>
Date: Fri, 3 Mar 2017 18:37:21 +0000

> I agree, but the verification involved can't be confirmed by the pledge.

The pledge confirms the voucher as a whole, which includes the assertion
statement.  What else might you mean?

>> but actually it's one step less code than calculating the SHA256
>> fingerprint.
>

I'm okay with making it a DER.

> If we have to pick a single number, I'd say 16 bytes.

According to https://tools.ietf.org/html/rfc7950#section-9.8.1:

   A binary type can be restricted with the "length" (Section 9.4.4)
   statement.  The length of a binary value is the number of octets it
   contains.

And Section 9.4.4 says:

   A length range consists of an explicit value, or a lower bound, two
   consecutive dots "..", and an upper bound.

Which means we can have:

  leaf nonce {
    type binary {
      length 8..32;
    }
  }

Cheers,
Kent

---

From: Russ Housley <[email-masked]>
Date: Fri, 3 Mar 2017 15:43:04 -0500

> On Mar 1, 2017, at 8:52 PM, Michael Richardson <[email-masked]> wrote:
> 
> 

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

---

From: Sean Turner <[email-masked]>
Date: Fri, 3 Mar 2017 16:06:21 -0500

> On Mar 3, 2017, at 15:43, Russ Housley <[email-masked]> wrote:
> 
>> 

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

spt

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Mar 2017 17:51:57 -0500

> I’m sure you know that there are three important properties for hash

Yes.

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

Yes, I agree completely.

What I'm asking for, is if there is a good, well-established container that
we can reference, that essentially gives us the agility to move from SHA1 to
SHA256, and to SHA3 if we have to.

Alternatively, for the use case involved, which is to refer to a certificate
by reference-to-CA + reference-to-DN, if there is some other construct that
would better do what we want, and *also* provide us with the agility we would
like.

(Some ownership vouchers may sit in filing cabinets for a few decades in
a warehouse somewhere)

---

From: Michael Richardson <[email-masked]>
Date: Fri, 03 Mar 2017 18:44:16 -0500

> statement.  What else might you mean?

Yes, but it can't know if the event having been logged as the MASA said it
would, was examined by the Registrar.

    > I'm okay with making it a DER.

I'm reading: https://tools.ietf.org/html/rfc7093
at Sean Turner and SPASM WG suggestion.  I think that this is the thing we
actually need.

    > length 8..32;

Works for me.

---

From: Russ Housley <[email-masked]>
Date: Mon, 6 Mar 2017 10:54:42 -0500

> (Some ownership vouchers may sit in filing cabinets for a few decades in

As Sean said, RFC 7093 gives ways that the CA can compute the Subject Key Identifier, and the CA can migrate from SHA-256 if needed in the future.

Russ