Subject: [Anima] Kathleen Moriarty's No Objection on draft-ietf-anima-voucher-06: (with COMMENT)

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 13 Dec 2017 09:01:07 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-anima-voucher-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-voucher/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for addressing Russ' Gen Art comments.  With that, I'm wondering if a
recommended signature algorithm should be specified.  This change had the work
go from just supporting RSA to including other (and better) choices.

Thanks,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Dec 2017 14:53:05 -0500

> go from just supporting RSA to including other (and better) choices.

I don't think we should recommend anything, or really need to.
There is only a small interoperability issue with algorithm selection here.

The manufacturer (in the form of the MASA) must generate a signature that
their product (the pledge) is able to verify.

So the selection of signature algorithm is essentially driven by the
capabilities of the pledge.  The manufacturer knows what that is, and so can
select appropriately.

There are tradeoffs of bandwidth, power consumption, code size, and longevity
of algorithm, and I think that specific recommendations should be left to
those closer to the specific kind of deployment.   A choice for a home NAS
device intended to be sold immediately and deployed (with a ~5 year lifespan)
might have significant differences than for a 50-port 10GE switch to be
deployed in a secured data center after being warehoused for 10 years as a
spare.

The voucher contains a pointer to the owner (the Registrar) within it, and I
think that algorithm will be subject to a different set of constraints.

The intermediate system (JRC, or Registrar) is given the opportunity to audit
the resulting voucher.  As such, it needs to be able to verify the voucher,
and it is here that we have some interoperability issue if the manufacturer
picks an unusual algorithm.   The Registrar could deny the new device,
consult with a human for an exception, or something more complex.

Finally an additional constraint is that the MASA's signing infrastructure
may need to have the private key available, and so some kind of HSM might be
appropriate, and those do not unfortunately track the bleeding edge of
cryptography.

Personally, I'd like to recommend edwards25519 (RFC8032), but tooling is
not up to that today.  That leaves one debating between size of RSA >2048bit,
vs security of secp256k1... depending upon code space and hardware
acceleration available in target device.   One would want to pick the same
algorithm as for SUIT and other stuff.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 13 Dec 2017 12:12:27 -0800

On Wed, Dec 13, 2017 at 11:53 AM, Michael Richardson <[email-masked]>
wrote:

> not up to that today.  That leaves one debating between size of RSA
> >2048bit,
> vs security of secp256k1

Nit: you mean secp256r1, i.e., P-256. Typically we don't use k1, though
bitcoin
does...

-Ekr

... depending upon code space and hardware

---

From: Kathleen Moriarty <[email-masked]>
Date: Wed, 13 Dec 2017 15:20:33 -0500

>> appropriate, and those do not unfortunately track the bleeding edge of

Thanks for the explanation, this makes sense and it was a non-blocking
question.  I'm fine with this response and leaving the document as-is.

Kathleen

-- 

Best regards,
Kathleen

---

From: Michael Richardson <[email-masked]>
Date: Wed, 13 Dec 2017 16:52:10 -0500

Eric Rescorla <[email-masked]> wrote:
    > Nit: you mean secp256r1, i.e., P-256. Typically we don't use k1,
    > though bitcoin
    > does...

yeah, I was going to lookup which was which again, because I never remember.