Subject: [core] Stephen Farrell's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS and COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Tue, 27 Sep 2016 10:18:18 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-core-http-mapping-14: 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-http-mapping/

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

I don't get why you don't at least RECOMMEND that HTTP
requests need to be authenticated? And I don't get why you
don't REQUIRE HC implementations support some form(s) of
strong-ish user authentication. We are seeing fairly major
botnets being built from the kinds of device that might use
CoAP and (with careless implementations all around) this
could provide a nice way to expose those to the Internet.
Isn't a good bit more caution needed in what we describe
here? Note: I'm not saying HTTP authentication, nor
specifically TLS client auth.

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

Generally, I'd have been happier if this document went more
towards reducing the attack surface and seemed less keen on
being more flexible. I assume though that the WG considered
that. (Some specific places that occurred to me are noted
below.)

I also agree with Kathleen's discuss.

- 6.1: "free to attempt mapping a single Accept header in a
GET request to multiple CoAP GET requests" - does that
provide a potential way to DoS (e.g. battery depletion)
devices in the constrained network? If so, would a warning be
useful? E.g. to limit the number of times a given media type
is attempted.

- 6.1: What "other forms of access control" do you mean?

- 6.2: This looks like it allows too large an attack surface
and maybe you ought default to denying 

- 6.5: Transcoding bugs galore! Given the history of bugs in
transcoding libraries shouldn't you recommend some caution
here? And are there forms of zipbomb that might cause
problems?

- 8.2: The presentation of the formula is not clear to me.
You say "reduces M_R iff..." but that's not a clear "method
to decide" as promised. 

- 10.3: In practice, what does "other means" mean in "This
recommendation may be relaxed in case the destination network
is believed to be secured by other means." ?

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Tue, 27 Sep 2016 23:16:13 +0000

Hi Stephen,

I'm only going through the COMMENTS section for now since that looks
easier than the DISCUSS :-)

I understand this concern in principle, but from a practical standpoint
I'm not super convinced that the surface it introduces is large enough to
deserve mentioning.  Currently, CoAP defines 8 different content formats.
So, worst case, the amplification would be x7 on the first request, then
caching should kick in (since 4.06, like all 4.xx, is cacheable) and the
HC proxy would then absorb any equivalent request (until max-age expires).
(The reasoning above should be fine provided the HC proxy default-denies
forwarding HTTP requests with "application/coap-payload" -- as you suggest
below.)

>- 6.1: What "other forms of access control" do you mean?

I guess you mean "other" is weirdly placed in that sentence?  It should
probably just say: "some form of access control".

>and maybe you ought default to denying

I guess you are referring to the last para: "A HTTP client may use the
media type "application/coap-payload" [...]"?  If so, nice catch!

OLD:

A HTTP client may use the media type "application/coap-payload" as a
   means to send a specific content format to a CoAP server via a HC
   Proxy if the client has determined that the HC Proxy does not
   directly support the type mapping it needs.  This case may happen
   when dealing for example with newly registered, yet to be registered,
   or experimental CoAP content formats.

NEW:

A HTTP client may use the media type "application/coap-payload" as a
   means to send a specific content format to a CoAP server via a HC
   Proxy if the client has determined that the HC Proxy does not
   directly support the type mapping it needs.  This case may happen
   when dealing for example with newly registered, yet to be registered,
   or experimental CoAP content formats.  However, unless explicitly
   configured to allow pass-through unknown content formats, the HC
   proxy SHOULD NOT forward requests carrying a Content-Type or Accept
   header with an "application/coap-payload", and return an appropriate
   client error (4xx) instead.

>here?

It looks like a sensible advice, but I'm not sure what to write exactly.
This might be covered by the "quality of implementation" argument in the
diff I sent previously to address Kathleen's DISCUSS?

>And are there forms of zipbomb that might cause
>problems?

Yes, probably worth pointing out that a JSON->CBOR transcoder might
inflate [1].

[1] https://tools.ietf.org/html/rfc7049#section-4.2

>You say "reduces M_R iff..." but that's not a clear "method

Sorry, I don't understand why you think that that wouldn't define an
unambiguous decision criterion?
In practice, you start Observing a given resource and track:
- the frequency of the updates on the CoAP side, and
- the inter-arrival time of the requests targeting that same resource on
the HTTP side.
After a while the formula allows you to decide whether the resource is
popular enough -- and so you should keep on observing it -- or if it's
better to unsubscribe and go back to Etag revalidation.

>is believed to be secured by other means." ?

I think the sentence just below that should provide an example (firewall):

"Assuming that CoAP nodes are isolated behind a firewall as in the HC
proxy deployment shown in Figure 1, the HC proxy may be configured to
translate the incoming HTTPS request using plain CoAP (NoSec mode)."

Cheers and thanks!
t

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Wed, 28 Sep 2016 09:00:16 +0000

Hi Stephen,

On 27/09/2016 18:18, "Stephen Farrell" <[email-masked]> wrote:
>I don't get why you don't at least RECOMMEND that HTTP requests need to
>be authenticated?

We haven't done it because it is not generally applicable.  Two examples:
- Reverse HC proxy that bridges a legacy HTTP controller to CoAP actuators;
- Transparent HC proxy boxes tout court.

The idea being that we would state which specific cases need user auth in
the security/privacy consideration section and do the RECOMMENDation
there.    (If you think there's anything missing, please suggest and we
will add.)

>And I don't get why you don't REQUIRE HC implementations support some
>form(s) of strong-ish user authentication.

The main issue I see with that is that saying "MUST use some form of user
auth" without specifying which exact form of user auth we want the box to
implement is equivalent to say nothing in terms of interop -- except we
are using more words ;-)
The other thing is the transparent HC box that just can't do that.

The way I see this is that there exist (lots of) use cases where either
the box implements strong user auth (and by that I mean mutual auth TLS)
or it is just not fit for the purpose.  Therefore a box vendor has an
incentive to ship boxes that do strong user auth, but if it doesn't
because its market segment doesn't need that, then fair enough.

>We are seeing fairly major botnets being built from the kinds of device
>that might use CoAP and (with careless implementations all around) this
>could provide a nice way to expose those to the Internet.  Isn't a good
>bit more caution needed in what we describe here?

This is very interesting.  Could you suggest text to add to the security
considerations that cover this topic (or pointers to literature)?

Cheers & thanks a lot for the discussion so far.
t

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Sep 2016 15:02:45 +0100

Hi Thomas,

On 28/09/16 10:00, Fossati, Thomas (Nokia - GB) wrote:
> We haven't done it because it is not generally applicable.  

I guess I'm surprised by that. I would have thought that the
most applicable case was a proxy to a sensor that may be
dealing with privacy sensitive data or to an actuator that
is very likely to be security sensitive. (Which is why I'd
argue for a "SHOULD be authenticated" for example.)

> Two examples:

How about 47000 counter examples? [1] :-)

   [1]
https://blog.sucuri.net/2016/09/iot-home-router-botnet-leveraged-in-large-ddos-attack.html

> there.    (If you think there's anything missing, please suggest and we

But why not reverse the logic and say "MUST be authenticated unless..."

Seems a lot safer to me tbh.

> implement is equivalent to say nothing in terms of interop -- except we

That's an issue yes. But I figure we could word around that
as mostly it'll be a shared secret over a server-auth TLS
and with cookies thereafter. That's a little sad but quite
doable. (Well, modulo getting a cert for the http server
where there are deployment but not interop problems.)

> because its market segment doesn't need that, then fair enough.

See [1]. I think we have to factor in the lowish quality of lots
of implementations in this space.

> considerations that cover this topic (or pointers to literature)?

Sure. Haven't time right now but happy to help with text
and references.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 29 Sep 2016 16:47:17 +0100

> forwarding HTTP requests with "application/coap-payload" -- as you suggest

Fair enough I guess.

> [1] https://tools.ietf.org/html/rfc7049#section-4.2

All the above are fine.

> better to unsubscribe and go back to Etag revalidation.

The above would define it well, but (iirc) the text didn't
actually say that clearly (where that == a decision). Maybe
take another look and see if some of the text you wrote
above might help?

Cheers,
S.

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Fri, 30 Sep 2016 09:50:01 +0000

Hi Stephen,

>> [1] https://tools.ietf.org/html/rfc7049#section-4.2

OK

>take another look and see if some of the text you wrote

OK

All these edits are now in my working copy.

Cheers, thanks,
t