Subject: [core] Kathleen Moriarty's Discuss on draft-ietf-core-etch-03: (with DISCUSS)

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 12 Oct 2016 10:33:41 -0700

Kathleen Moriarty has entered the following ballot position for
draft-ietf-core-etch-03: Discuss

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-core-etch/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I'd like to see more of the actual requirements for this draft in the
security considerations as the pointers include all of the configuration
options for DTLS, including the "nosec" option.  I would think this
operation would require authentication to prevent unauthorized access by
devices that are clones.  This is a real problem in the non-IoT space for
firmware updates and will be a problem in this space if it isn't already
- knock off hardware that installs the firmware of a popular product.  In
In section 5 of RFC5789, I see this:
   These
   include authorizing requests (possibly through access control and/or
   authentication) and ensuring that data is not corrupted through
   transport errors or through accidental overwrites. 

And would like to see something similar in this section to at least list
some of the requirements and reasoning.  For patch and fetch, I think the
reason outlined above needs to be included as well so it is top of mind
for implementers and they are aware of this very real threat.  It is
important they understand why they need authentication and encryption to
prevent attacks against their brand.  If someone buys knock-off hardware
that is faulty and uses their firmware, they have multiple problems to
deal with, not just the loss of sales.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 13 Oct 2016 09:59:04 +0200

Hi Kathleen,

thank you for this review.

Maybe I'm not reading this right, but a lot of what you are saying
sounds like considerations that apply to all of CoAP's methods.  These
should already be covered by the security considerations of RFC 7252,
which we do refer to.  Alissa indeed had an observation about a security
consideration that is specific to FETCH that we had overlooked, and we
have added that in the editors' draft.
I can't really make out which of your comments indicate security
considerations specific to FETCH, or to PATCH/iPATCH, or to both, that
are not already covered by RFC 7252.

Grüße, Carsten

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 13 Oct 2016 08:44:12 -0400

Hi Carsten,

On Thu, Oct 13, 2016 at 3:59 AM, Carsten Bormann <[email-masked]> wrote:

> which we do refer to.

Please do read my discuss again.  The main point I started off with is that
the reference to section 9 of 7252 includes all of the options for COAP
security, which includes no encryption or authentication.  I am asking for
specific requirements to this method as was done in 5789.  Since the
security considerations section is just a set of pointers to drafts with
different options and requirements, it is not clear what applies to the
FETCH, PATCH, and iPATCH methods.

Specific to PATCH, I then pointed out an attack type where a resource that
should not be authorized is able to get an update or modification.  The
more obvious case of a resource getting a malicious update may already be
covered, but the case I am pointing out specific to PATCH is not covered.
I pointed to a specific sentence in RFC5789 that I would like to see
repeated so the requirements for these methods are clear.

If you look at the security considerations section of this draft, it starts
out with the most generic pointer to RFC7252 section 9 that includes all
options.  Then it starts to get more specific and it seems to tighten up
the requirements, but then finishes referring to section 9 of RFC7252 that
includes all of the methods, including nosec, again.

This is confusing.  As such, adding a sentence or two on the specific
security considerations for this draft is important.  I'd also like to see
mention of the threat I pointed out in my discuss unless you can explain
how that is not applicable (which I don't think is the case) to IoT.  I've
had to work on the remediation and prevention of that specific attack type
for other devices and it's hit most (if not all) big vendors.

> Alissa indeed had an observation about a security

I'm not sure how this is helpful here and it's probably better that you
don't expand on it.

Thank you,
Kathleen

-- 

Best regards,
Kathleen