Subject: Re: [Suit] WG Review: Software Updates for Internet of Things (suit)

From: Rajesh Kanungo <[email-masked]>
Date: Sat, 4 Nov 2017 10:47:10 +0530

2 questions and a comment:

Question: Any idea about the timestamp start, granularity, end?

Question about signatures: would you consider a more structured signature
field? Something like:
https://github.com/multiformats/multihash

fn code  dig size hash digest
-------- -------- ------------------------------------
00010001 00000100 101101100 11111000 01011100 10110101
sha1     4 bytes  4 byte sha1 digest

Comment:

> Also: is RFC 4108 really a "current best practice"? There seems to be
nearly no implementations of that in the IoT space, or at least none that
have spoken up about it.

I don't know if it is a current best practice or not but I introduced CMS
as a method to update Itron's smart electricity meters over the air roughly
6 years ago. There are probably 20 million of them out there by now and
counting.

CMS allows one feature that I really liked:  co-signing.  This allows a
firmware update to be co-signed by an operator so that the devices would
accept only firmware approved by the operator (e.g. Utility) .  Many times,
the operator would test out a manufacturer signed firmware update in their
own setup, work with the manufacturer to fix any issues, then co-sign the
firmware before distribution.  The target device would only accept utility
signed firmware ...

CMS also allows customers to use standard OpenSSL tools to examine the
contents of the payload.

However:
There is no reason the proposed format can't be nested to provide the above
properties especially if the manufacturer's signed firmware release is not
re-encrypted.  Hence, even though I used CMS, I think it is overkill for
smaller limited devices.

Rajesh

---------- Forwarded message ----------
From: Paul Hoffman <[email-masked]>
To: The IESG <[email-masked]>
Cc: [email-masked]
Bcc:
Date: Fri, 03 Nov 2017 11:04:03 -0700
Subject: Re: [Suit] WG Review: Software Updates for Internet of Things
(suit)
On 3 Nov 2017, at 10:49, Carsten Bormann wrote:

The initial focus of this group will be development of a manifest approach
>> based on CMS and the ASN.1 encoding. This work will result in a revision
>> of
>> RFC 4108 that reflects the current best practices.
>>
>
I’m slightly confused by this charter proposal.
> The recent mailing list discussion went into a different direction.
> Is this the current proposed text?
>

I agree with Carsten: that's not what the recent list traffic was aiming
for. The draft charter from a month ago didn't force the WG into ASN.1, and
I don't see any list traffic asking for that.

Also: is RFC 4108 really a "current best practice"? There seems to be
nearly no implementations of that in the IoT space, or at least none that
have spoken up about it.

Use of the ASN.1 encoding
>> is desirable due to existing ASN.1 support in crypto libraries used within
>> current IoT operating systems.
>>
>
The same could be said for CBOR/COSE. It is probably inaccurate to cite
"ASN.1 support" given that different parts of a system might each implement
its own ASN.1 stack.

The group may later adopt alternate manifest
>> formats using other serialization approaches (e.g., CBOR).
>>
>
Why not let the WG decide which it wants?

--Paul Hoffman

---------- Forwarded message ----------
From: "Waltermire, David A. (Fed)" <[email-masked]>
To: Paul Hoffman <[email-masked]>, The IESG <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Bcc:
Date: Fri, 3 Nov 2017 18:43:57 +0000
Subject: Re: [Suit] WG Review: Software Updates for Internet of Things
(suit)
Paul and Carsten,

My comments are inline below.

> >> The initial focus of this group will be development of a manifest
> >> approach based on CMS and the ASN.1 encoding. This work will result
> >> in a revision of RFC 4108 that reflects the current best practices.
>
> > I’m slightly confused by this charter proposal.
> > The recent mailing list discussion went into a different direction.
> > Is this the current proposed text?
>
> I agree with Carsten: that's not what the recent list traffic was aiming
for. The
> draft charter from a month ago didn't force the WG into ASN.1, and I
don't see
> any list traffic asking for that.

The guidance we received from the IESG is that they want the question
around one or more formats resolved during the chartering process. We have
had a number of views expressed on the list. We need to focus in on what
the consensus within the group is. We need to identify what our initial
work items will be regarding format(s).

To that end, this text can be updated. Do you have alternate text to
propose?

> Also: is RFC 4108 really a "current best practice"? There seems to be
nearly no
> implementations of that in the IoT space, or at least none that have
spoken up
> about it.
>
> >> Use of the ASN.1 encoding
> >> is desirable due to existing ASN.1 support in crypto libraries used
> >> within current IoT operating systems.
>
> The same could be said for CBOR/COSE. It is probably inaccurate to cite
> "ASN.1 support" given that different parts of a system might each
implement its
> own ASN.1 stack.

How would you change this text to improve it?

> >> The group may later adopt alternate manifest formats using other
> >> serialization approaches (e.g., CBOR).
>
> Why not let the WG decide which it wants?

This statement is intended to do that. We need to figure out what we are
working on initially and reflect that in the charter and milestones. Are
you suggesting that the text should be made more clear? If so, then how?

> --Paul Hoffman

Thanks,
Dave

---------- Forwarded message ----------
From: Dave Thaler <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Waltermire, David A. (Fed)" <[email-masked]>
Bcc:
Date: Fri, 3 Nov 2017 18:51:01 +0000
Subject: [Suit] Notetaker and jabber scribe

The SUIT BoF is now just over one week away.  Do we have any volunteers who
would be willing to be

either a note taker or a jabber scribe?

If so, please send email to the BoF chairs (Dave and Dave).

Dave Thaler

_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit

-- 
Rajesh Kanungo
President and CTO
TalaSecure, Inc.
(408) 431-3035

---

From: Jim Schaad <[email-masked]>
Date: Fri, 3 Nov 2017 22:26:03 -0700

From: Suit [mailto:[email-masked]] On Behalf Of Rajesh Kanungo
Sent: Friday, November 3, 2017 10:17 PM
To: [email-masked]
Subject: Re: [Suit] WG Review: Software Updates for Internet of Things (suit)

Question about signatures: would you consider a more structured signature field? Something like: 

 

[JLS] I am not sure what you think you are going to get from this.  What is the end goal you are asking for.

Comment:

> Also: is RFC 4108 really a "current best practice"? There seems to be nearly no implementations of that in the IoT space, or at least none that have spoken up about it.

I don't know if it is a current best practice or not but I introduced CMS as a method to update Itron's smart electricity meters over the air roughly 6 years ago. There are probably 20 million of them out there by now and counting.  

CMS allows one feature that I really liked:  co-signing.  This allows a firmware update to be co-signed by an operator so that the devices would accept only firmware approved by the operator (e.g. Utility) .  Many times, the operator would test out a manufacturer signed firmware update in their own setup, work with the manufacturer to fix any issues, then co-sign the firmware before distribution.  The target device would only accept utility signed firmware ...

[JLS] You will be happy to know that this is natively supported by COSE – either as a co-signature or a counter-signature just like CMS.

Jim

CMS also allows customers to use standard OpenSSL tools to examine the contents of the payload.

However:

There is no reason the proposed format can't be nested to provide the above properties especially if the manufacturer's signed firmware release is not re-encrypted.  Hence, even though I used CMS, I think it is overkill for smaller limited devices.  

Rajesh

---------- Forwarded message ----------
From: Paul Hoffman <[email-masked] <mailto:[email-masked]> >
To: The IESG <[email-masked] <mailto:[email-masked]> >
Cc: [email-masked] <mailto:[email-masked]> 
Bcc: 
Date: Fri, 03 Nov 2017 11:04:03 -0700
Subject: Re: [Suit] WG Review: Software Updates for Internet of Things (suit)

The initial focus of this group will be development of a manifest approach
based on CMS and the ASN.1 encoding. This work will result in a revision of
RFC 4108 that reflects the current best practices.

I agree with Carsten: that's not what the recent list traffic was aiming for. The draft charter from a month ago didn't force the WG into ASN.1, and I don't see any list traffic asking for that.

Also: is RFC 4108 really a "current best practice"? There seems to be nearly no implementations of that in the IoT space, or at least none that have spoken up about it.

The same could be said for CBOR/COSE. It is probably inaccurate to cite "ASN.1 support" given that different parts of a system might each implement its own ASN.1 stack.

--Paul Hoffman

---------- Forwarded message ----------
From: "Waltermire, David A. (Fed)" <[email-masked] <mailto:[email-masked]> >
To: Paul Hoffman <[email-masked] <mailto:[email-masked]> >, The IESG <[email-masked] <mailto:[email-masked]> >
Cc: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Bcc: 
Date: Fri, 3 Nov 2017 18:43:57 +0000
Subject: Re: [Suit] WG Review: Software Updates for Internet of Things (suit)
Paul and Carsten,

> I agree with Carsten: that's not what the recent list traffic was aiming for. The
> draft charter from a month ago didn't force the WG into ASN.1, and I don't see

The guidance we received from the IESG is that they want the question around one or more formats resolved during the chartering process. We have had a number of views expressed on the list. We need to focus in on what the consensus within the group is. We need to identify what our initial work items will be regarding format(s).

To that end, this text can be updated. Do you have alternate text to propose?

> Also: is RFC 4108 really a "current best practice"? There seems to be nearly no
> implementations of that in the IoT space, or at least none that have spoken up
> about it.
>
> "ASN.1 support" given that different parts of a system might each implement its
> own ASN.1 stack.

> Why not let the WG decide which it wants?

This statement is intended to do that. We need to figure out what we are working on initially and reflect that in the charter and milestones. Are you suggesting that the text should be made more clear? If so, then how?

Thanks,
Dave

---------- Forwarded message ----------
From: Dave Thaler <[email-masked] <mailto:[email-masked]> >
To: "[email-masked] <mailto:[email-masked]> " <[email-masked] <mailto:[email-masked]> >
Cc: "Waltermire, David A. (Fed)" <[email-masked] <mailto:[email-masked]> >
Bcc: 
Date: Fri, 3 Nov 2017 18:51:01 +0000
Subject: [Suit] Notetaker and jabber scribe

The SUIT BoF is now just over one week away.  Do we have any volunteers who would be willing to be

Dave Thaler

_______________________________________________
Suit mailing list
[email-masked] <mailto:[email-masked]> 
https://www.ietf.org/mailman/listinfo/suit

-- 

Rajesh Kanungo

President and CTO

TalaSecure, Inc.

(408) 431-3035

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 4 Nov 2017 12:02:05 +0100

On Nov 4, 2017, at 06:17, Rajesh Kanungo <[email-masked]> wrote:
> 
> one feature that I really liked:  co-signing.  This allows a firmware update to be co-signed by an operator so that the devices would accept only firmware approved by the operator (e.g. Utility) .  Many times, the operator would test out a manufacturer signed firmware update in their own setup, work with the manufacturer to fix any issues, then co-sign the firmware before distribution.  The target device would only accept utility signed firmware …

Thank you for adding content here that leads us away from the format wars.

So basically, you have two signed claims:

Issuer: manufacturer
Subject: (the firmware)
Claim: This firmware is appropriate for manufx model 0815 rev 4 to 17, when equipped with 128 KiB of RAM
Claim: This firmware provides feature set A, B, M
Claim: This firmware has version 2.17.33 and replaces all numerically smaller firmware versions

Issuer: utility
Subject: (the firmware)
Claim: This firmware is appropriate for use in Wesernetz in eastern Bremen, contract types 17, 32, and 38, installation types beta, gamma, and ny.
Claim: Do not replace 2.17.31 with this just yet, there is a bug in the updater that will be worked around later.

The authorization policy for the upgrade would check all these claims for (authorized authentication and) the requirements that are specific to the device/model and the installation/usage/contract type.

Of course, a very constrained device would prefer to (also?) get one claim from its authorization manager:

Issuer: authorization manager
Subject: (the firmware)
Audience: You, the device
Claim: This is good for you

Grüße, Carsten

---

From: Rajesh Kanungo <[email-masked]>
Date: Sat, 4 Nov 2017 18:18:30 +0530

About Claims:
JNLP allowed similar constraints but for JVM versions.
Come to think f it, accidentally bricking a remote IoT device is high up on
my list of worries.  Your constraints definition is good.

Questions:
I am not clear about the signer's public key or certificate is matched to
the signature.

I am also not clear regarding how the signing public keys or certificates
are distributed and/or revoked.  Is that outside the scope of the
document?  Or am I just not reading the spec properly.

Also, I am not clear if we can insert run some prescribed actions to be run
before or after firmware installation.

Rajesh

On Sat, Nov 4, 2017 at 4:32 PM, Carsten Bormann <[email-masked]> wrote:

> > one feature that I really liked:  co-signing.  This allows a firmware
> update to be co-signed by an operator so that the devices would accept only
> firmware approved by the operator (e.g. Utility) .  Many times, the
> operator would test out a manufacturer signed firmware update in their own
> setup, work with the manufacturer to fix any issues, then co-sign the
> signed firmware …
> Claim: This firmware is appropriate for use in Wesernetz in eastern
> Bremen, contract types 17, 32, and 38, installation types beta, gamma, and
> ny.
> Claim: Do not replace 2.17.31 with this just yet, there is a bug in the
> updater that will be worked around later.
>
> The authorization policy for the upgrade would check all these claims for
> (authorized authentication and) the requirements that are specific to the
> device/model and the installation/usage/contract type.
>

-- 
Rajesh Kanungo
President and CTO
TalaSecure, Inc.
(408) 431-3035

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 4 Nov 2017 14:11:26 +0100

On Nov 4, 2017, at 13:48, Rajesh Kanungo <[email-masked]> wrote:
> 
> I am not clear about the signer's public key or certificate is matched to the signature.  

I hand-waved over that as it is part of the “authorized authentication”.

I generally try to avoid thinking about these authorization problems in terms of certificates, as these are a hammer that may not fit a specific kind of workpiece (which may, after all, not be a nail).

> I am also not clear regarding how the signing public keys or certificates are distributed and/or revoked.  Is that outside the scope of the document?  Or am I just not reading the spec properly.

If you think in terms of certificates, that problem can somehow be considered solved.
But I think in general certificates are just one way to authorize authentication, and we should cast a wider net here.

If you don’t have (want to rely on) the authorization manager, the device will need to be configured with some trusted information that can be used to transitively authorize the authentication of the manufacturer and the operator; authorization chains for these two can be combined or kept separate.

In your applications, do you have a secure real-time clock (i.e., can you securely check not-before and expiration times)?
That may help getting rid of older certificates, but it also means that a firmware image that is delivered together with such certificates ages out.

Revocation can be done in a push (e.g., CRL) or a pull (e.g., OCSP or token introspection) manner; CRLs are not really appropriate for embedded devices.

> Also, I am not clear if we can insert run some prescribed actions to be run before or after firmware installation.  

That sounds good and would need to be added to the signed claims.
Is there a good way to specify these actions in a way that is somewhat detached from a specific system or platform?

Grüße, Carsten

---

From: Rajesh Kanungo <[email-masked]>
Date: Sat, 4 Nov 2017 19:41:27 +0530

On Sat, Nov 4, 2017 at 6:41 PM, Carsten Bormann <[email-masked]> wrote:

> I generally try to avoid thinking about these authorization problems in
> terms of certificates, as these are a hammer that may not fit a specific
> kind of workpiece (which may, after all, not be a nail).
>

I had a simpler problem:  A device may have 10 public keys.  The firmware
update arrives with a signature.   How do you use the right public key to
verify the signature?

Remember that signature checks on these devices (especially energy limited
devices) can have a small but not so insignificant drain.

>
> > I am also not clear regarding how the signing public keys or
> certificates are distributed and/or revoked.  Is that outside the scope of
> the document?  Or am I just not reading the spec properly.
>
> But I think in general certificates are just one way to authorize
> authentication, and we should cast a wider net here.
>
> If you don’t have (want to rely on) the authorization manager, the device
> will need to be configured with some trusted information that can be used
> to transitively authorize the authentication of the manufacturer and the
> operator; authorization chains for these two can be combined or kept
> separate.
>
> In your applications, do you have a secure real-time clock (i.e., can you
> securely check not-before and expiration times)?
> That may help getting rid of older certificates, but it also means that a
> firmware image that is delivered together with such certificates ages out.
>
> Revocation can be done in a push (e.g., CRL) or a pull (e.g., OCSP or
> token introspection) manner; CRLs are not really appropriate for embedded
> devices.
>

Unfortunately turns out to be an issue if the headend gets compromised.
Utilities have demanded this mechanism.  We do need to revoke older keys
and install new public keys.

>
> > Also, I am not clear if we can insert run some prescribed actions to be
> run before or after firmware installation.
>
> Is there a good way to specify these actions in a way that is somewhat
> detached from a specific system or platform?
>
>
The crudest thing is a reference to entries in table of actions.  Fairly
language independent.  I said fairly because I can foresee format wars ...
your favorite ...

The installed firmware must support preinstall actions.  The post install
actions must be supported by the complete installed firmware.

I doubt we can enforce transactional semantics in these devices.

Grüße, Carsten

-- 
Rajesh Kanungo
President and CTO
TalaSecure, Inc.
(408) 431-3035

---

From: Russ Housley <[email-masked]>
Date: Sat, 4 Nov 2017 13:15:17 -0400

> On Nov 4, 2017, at 10:11 AM, Rajesh Kanungo <[email-masked]> wrote:
> 
> 
> 
> On Sat, Nov 4, 2017 at 6:41 PM, Carsten Bormann <[email-masked] <mailto:[email-masked]>> wrote:
> On Nov 4, 2017, at 13:48, Rajesh Kanungo <[email-masked] <mailto:[email-masked]>> wrote:
> >
> I had a simpler problem:  A device may have 10 public keys.  The firmware update arrives with a signature.   How do you use the right public key to verify the signature?  

In CMS, there are two mechanisms to selecting the certificate of the signer:

	1) issuer and serial number of the signer's certificate; and

	2) subject public key identifier, which is essentially the hash of the signer's public key.

Either of these should let you select the certificate of the signer from the 10 that you have stored.  The second one will also work if you stored 10 raw public keys.

> Remember that signature checks on these devices (especially energy limited devices) can have a small but not so insignificant drain.  
> 
> Unfortunately turns out to be an issue if the headend gets compromised. Utilities have demanded this mechanism.  We do need to revoke older keys and install new public keys.  

The Trust Anchor Management Protocol (TAMP) is one way to do this.

Russ

---

From: Russ Housley <[email-masked]>
Date: Sat, 4 Nov 2017 13:16:10 -0400

> https://github.com/multiformats/multihash <https://github.com/multiformats/multihash>
> 
I do not see what is gained over an IANA registry with registered algorithm identifiers.

Russ

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 4 Nov 2017 18:16:08 +0100

> I had a simpler problem:  A device may have 10 public keys.  The firmware update arrives with a signature.   How do you use the right public key to verify the signature?  

Both CMS and COSE have key identifiers, so that should be solvable.

> Remember that signature checks on these devices (especially energy limited devices) can have a small but not so insignificant drain.  

Right.

> Unfortunately turns out to be an issue if the headend gets compromised. Utilities have demanded this mechanism.  We do need to revoke older keys and install new public keys.  

Indeed.  A CRL can help you with the former, not with the latter.  Any push mechanism that authorizes a new key can also de-authorize an old one.  (If you want to flood the de-authorization, you just need a signed claim that the compromised key is now de-authorized.)

Re actions around an upgrade:

> The crudest thing is a reference to entries in table of actions.  Fairly language independent.  I said fairly because I can foresee format wars ... your favorite …

Which form would these references take?  Text string?  Byte string?

Grüße, Carsten

---

From: Rajesh Kanungo <[email-masked]>
Date: Sun, 5 Nov 2017 08:26:18 +0530

Thanks for your other responses.

On Sat, Nov 4, 2017 at 10:46 PM, Carsten Bormann <[email-masked]> wrote:

> your favorite …

EBCDIC?
More seriously, the general form is a REST API type string.  May be too
much.  Using index numbers is fairly dangerous as it is hard to prevent
collisions.  REST is good but the system can be misused or misunderstood
and can open security holes. A GUID has no meaning; it would be easy to
define and almost impossible to use.  Almost feel like using a URN.  It is
a named procedure we will be invoking.

Mightier minds might want to chime in.

-- 
Rajesh Kanungo
President and CTO
TalaSecure, Inc.
(408) 431-3035

---

From: Brendan Moran <[email-masked]>
Date: Tue, 7 Nov 2017 23:13:35 +0000

I find it useful to distinguish between information that a device needs to know in order to authorise an update, and information that a device needs to know in order to apply an update. I’d like to see a use-case that describes where a device would need purely informational content in a manifest.

I have annotated the claims you have listed below. They seem to fall into two groups
* purely informational claims (these are not used by the device to make decisions).
* pre-installation conditions: checks that the device must perform prior to installing a firmware package.

I expect to also find “claims” that are instructions about how to interpret payloads, how to install them, etc.

In all, I expect ___ semantics for claims:
* pre-installation conditions
* installation instructions
* payload descriptors (how do I obtain the referenced payload? How big is it? How do I verify its integrity?)
* informational claims (this is firmware version 2.17.33)

The device shouldn’t need to know about firmware versions for single-image updates, since the monotonic sequence number of the manifest encapsulates rollback protection.

Is there a good reason to try and combine all of these semantics into a single type of “claim” field?

Best Regards,
Brendan Moran

> On 4 Nov 2017, at 11:02, Carsten Bormann <[email-masked]> wrote:
>

This is a set of pre-installation conditions.

> Claim: This firmware provides feature set A, B, M

This appears to be purely informational.

> Claim: This firmware has version 2.17.33 and replaces all numerically smaller firmware versions

This is may be informational. It is hard to tell. If the metadata has a monotonic sequence number, this should be unnecessary, unless I’m missing a use-case.

> Claim: This firmware is appropriate for use in Wesernetz in eastern Bremen, contract types 17, 32, and 38, installation types beta, gamma, and ny.

This is a set of pre-installation conditions

> Claim: Do not replace 2.17.31 with this just yet, there is a bug in the updater that will be worked around later.

This is a negative pre-installation condition

> Claim: This is good for you

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.