Subject: [core] Kathleen Moriarty's Discuss on draft-ietf-core-http-mapping-14: (with DISCUSS)

From: "Kathleen Moriarty" <[email-masked]>
Date: Mon, 26 Sep 2016 11:02:47 -0700

Kathleen Moriarty 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:
----------------------------------------------------------------------

This is one discuss point with 2 questions.  The second part is what's
discussable and the first should be easy to fix either with the text
provided or something similar.

1. In Section 10.1, this is more of a security than a privacy
consideration as this is "network reconnaissance".  This is a typical
pre-cursor to an attack one the the attacker has gathered more
information on the network.

   From a privacy perspective, they can be
   used to gather detailed information about the resources hosted in the
   constrained network. 

How about:
   This can be
   used to gather detailed information about the resources hosted in the
   constrained network, as siting with network reconnaissance.

then for the last sentence:
   If privacy is a concern, for
   example whenever the HTTP request transits through the public
   Internet, the request SHOULD be transported over a mutually
   authenticated and encrypted TLS connection.

How about:
   If confidentiality of the network is a concern, for
   example whenever the HTTP request transits through the public
   Internet, the request SHOULD be transported over a mutually
   authenticated and encrypted TLS connection. 

The word privacy here is confusing, so it's better to state exactly the
issue.

More importantly, if you can do network reconnaissance, what's to stop
the attacker from using this new method of connecting?  Some mention of
this threat should be explicitly stated, maybe section 10.1 is the best
place to do that, expanding on the existing text with another sentence. 

2. (Really part of #1, but a separate point) Could transforms of URIs
result in successful attacks?  I would think that would be the highest
security consideration.  Although RFC7230 includes similar
considerations, the mapping aspect of this draft could open up new attack
possibilities, especially if a media type mapping is used.  If there is
an attack possible in the IoT space that is not in the HTTP world (device
specific, or related to size constraints and coding), an intrusion
prevention system monitoring the HTTP traffic before it is transformed
would not pick it up and the attack traffic would evade detection.  I
think this merits mention and some text in the draft.  Please let me know
if it is elsewhere and another pointer is all that is needed.

Thank you.

---

From: "Fossati, Thomas (Nokia - GB)" <[email-masked]>
Date: Mon, 26 Sep 2016 22:55:37 +0000

Hi Kathleen,

Thanks very much for your comments!  Some initial thoughts inlined.

I guess the privacy issue we want to highlight here is that a query to
/.well-known/core might return, for example, the inventory of someone's
home appliances and devices.  This might still be interesting information
for an attacker that is not necessarily searching for vulnerabilities in
the protocol stack of the fridge.

Could you please suggest a better term than "privacy" to describe the
concern above?

BTW, your point about network reconnaissance is great and I'd like to
incorporate your suggestion in section 10.1.

>place to do that, expanding on the existing text with another sentence.

Sorry, I don't understand what you mean by "what's to stop the attacker
from using this new method of connecting?".

>if it is elsewhere and another pointer is all that is needed.

Re: URI mapping.  I can't see an obvious (or less obvious) way this could
be an issue per se -- assuming the HTTP parser and the CoAP encoder are
both correct (as discussed in the security considerations of RFC 7230 and
RFC 7252).

Re: Media mapping.  The funnel has a disproportionately big mouth and a
minuscule stem, allowing very few degrees of freedom: I might be wrong but
it seems to me that the attack surface is virtually zero there.  Are you
thinking of the optional "loose" mapping defined in section 6.3 instead?
(If so, the last paragraph of section 6.1 has text suggesting stricter
access control if that feature is enabled.  Is that enough?  Should it be
moved to the security considerations?)

It's late and I certainly lack a bit of imagination (I can only think of
issues deriving from buggy implementations, nothing that is intrinsic to
the protocols' interactions).  Do you have anything precise in mind?

Cheers, thanks,
t.

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 26 Sep 2016 21:02:05 -0400

Hi Thomas,

Thanks for your quick response, inline.

> Could you please suggest a better term than "privacy" to describe the

Oh, that point wasn't clear in the draft and is certainly a privacy
consideration.  What I read from the text was a network recon threat,
which was about confidentiality of the network services - their
existence and not privacy related information that could be
discovered.  As such, covering both threats would be best, but I would
suggest you expand the current text to explain this threat.

> from using this new method of connecting?".

By new method, I mean that you now have a proxy to translate HTTP to
COAP.  You would not have been able to make such connections before.
Could anything happen at the proxy when the traffic is proxied?

> both correct (as discussed in the security considerations of RFC 7230 and

But could anything happen in that translation?  If there is an exploit
possible through a malformed URI, that isn't bad on one side of the
translation, but is on the other?  The pointer to the HTTP drafts is
good, but I am still wondering if anything could happen and if there
is a reason why this should also be called out as a consideration. The
discussion just points to the HTTP security considerations, are there
some for COAP?

> thinking of the optional "loose" mapping defined in section 6.3 instead?

I'm just wondering, and could be wrong (hence wanting t discuss it
since this isn't explained in the draft as a consideration.  I would
think there would be some considerations related to proxying this
content between 2 protocols.

> moved to the security considerations?)

I'm also asking.  Could there be code problems on the COAP enabled
devices that could be exploited with malformed URIs?  Is this covered
in a COAP security consideration section somewhere and a pointer
should be added?  Am I way off base?

> the protocols' interactions).  Do you have anything precise in mind?

Hmm, the HTTP draft covers malformed URIs that would only be an issue
with a buggy implementation because this attack type is so common, so
I was referring to an issue like this for COAP and wondering if there
should be some warning text.  The IoT space is so large and there are
bound to be issues.  If you out-of-scoped such issues, but said this
could also be a problem with COAP, that would cover my concern.

It is late, thanks for the discussion.  I'd just like to make sure we
aren't missing a warning that could be helpful.

Thanks.

-- 

Best regards,
Kathleen

---

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

>suggest you expand the current text to explain this threat.

OK.  I'll expand the privacy concern to make it more clear, and add the
network reconnaissance threat that you suggested as well.

>discussion just points to the HTTP security considerations, are there

I think it's worth pointing out (at the very beginning of section 10) that
the correctness of the request parsing, and in particular the URI
translation process, is essential to the security of the HC proxy.  We
could refer to the relevant parts of CoAP and HTTP that already highlight
this criticality (the request parsing caveats in section 9.3, 9.4, 9.5 and
9.6 of RFC7230 [1] and the bits related to URI parsing in [2]).  The point
to raise here, I think, is that the implementation quality of the HC proxy
-- i.e. careful implementation and/or selection of the third party
libraries, sane configuration defaults - is essential to the security of
potentially *lots* of things on the constrained side.

[1] https://tools.ietf.org/html/rfc7230#section-9
[2] https://tools.ietf.org/html/rfc7252#section-11.1

>should be added?  Am I way off base?

No, you are certainly not off base, the threat is real.  And the risk of
the HC proxy becoming an integral part of the threat (rather than part of
the solution) is factual given where it sits in the network.  This needs
to be clearly spelled out, probably as an argument that reinforces the
need for the highest quality of implementation (see above).

>could also be a problem with COAP, that would cover my concern.

I agree.  As per the warning text, I think this would be covered by the
proposed text above re: QoImpl?

>I'd just like to make sure we

Sure, your comments are super helpful.  Thanks again!

(If you are OK with the rationale I'll go on and prepare a diff for you to
look at.)

Cheers, t

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 27 Sep 2016 09:50:01 -0400

Hi Thomas,

> (If you are OK with the rationale I'll go on and prepare a diff for you to

Thank you, that would be great.  I like the approach you are
suggesting and appreciate you responding quickly with a good solution.

-- 

Best regards,
Kathleen

---

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

Hi Kathleen,

I have attached the diff.  Let us know if it's OK.

Cheers, thanks!

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 27 Sep 2016 14:59:36 -0400

Hi Thomas,

Thank you for sending along the diff, the text looks great and I hope
others find it helpful.  I'll clear my discuss now since htis is in
your pending draft.

Thanks,
Kathleen

-- 

Best regards,
Kathleen