Re: [Ace] Stephen Farrell's Yes on draft-ietf-ace-usecases-09: (with COMMENT)

On 22/10/15 14:59, Carsten Bormann wrote:
> Hi Stephen,
> 
> I agree with all of these. However, they are not specific to ACE;
> they are general security considerations for constrained devices (or
> IoT things in general). I think what we need to do is collect the
> security considerations we have in, say, RFC 7252, RFC 7228, etc.,
> combine this with the points below and a few more that came up, and
> generate a referenceable “Security Considerations for Constrained
> Devices on the Internet” document.  I’d love to reference that from
> any document I’m working on.

Such a document would indeed be a fine thing. Do we have folks who
are willing and able already?

That said, I do think there may be ace-specific use-cases to be
derived from (some of) the points raised, e.g. handling end of
life is maybe not the same as a handover after the vendor is off
the stage.

S.

> 
> Grüße, Carsten
> 
> 
>> On 22 Oct 2015, at 15:29, Stephen Farrell
>> <stephen.farrell@cs.tcd.ie> wrote:
>> 
>> Stephen Farrell has entered the following ballot position for 
>> draft-ietf-ace-usecases-09: Yes
>> 
>> 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-ace-usecases/
>> 
>> 
>> 
>> ----------------------------------------------------------------------
>>
>> 
COMMENT:
>> ----------------------------------------------------------------------
>>
>>
>>
>> 
Excellent and well written document, thanks. I think there are
>> five things you could usefully add, see below. That said, I agree
>> that this cannot and should not try to be fully complete so I won't
>> argue (much:-) if you prefer to omit these. We/you can figure out
>> what if any text to add I'm sure, but I'm happy to chat about
>> that.
>> 
>> 1. Software update is really needed and often missing and usually
>> hard. There's at least a need to authenticate and authorize new
>> firmware, when there is any update. That may not be the same as
>> authorizing a new config.
>> 
>> 2. Alice buys a new device, and would like to know if it is calling
>> home or what it is doing before she configures it, or perhaps
>> before she accepts it in her network. Even if she accepts it, she
>> may want to be able to monitor the data it is sending "home" e.g.
>> to ensure her TV is not sending data when she inserts a USB stick,
>> if that is undesired.
>> 
>> 3. Device fingerprinting is a threat that ought be considered by
>> solution developers, especially if there is no reliable software
>> update. Probably the best to be done is to try to make it hard for
>> unauthorized parties to fingerprint a device, but that's also
>> hard.
>> 
>> 4. Commercial Devices will be end-of-lifed by vendors, and yet 
>> Alice still needs to be able to use, and perhaos to update, the
>> device. That calls for some kind of authorization handover which is
>> not quite the same as a change of ownership.
>> 
>> 5. Penetration testing will happen and devices should not barf even
>> then. Maybe that's a security consideration worth a mention.
>> 
>> See also the secdir review. [1] It'd be good to see a response to
>> that.
>> 
>> [1]
>> https://www.ietf.org/mail-archive/web/secdir/current/msg06101.html
>> 
>> 
>> _______________________________________________ Ace mailing list 
>> Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
>> 
> 