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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 24 Apr 2013 18:26:05 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-core-coap-15: 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 http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

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

I will end up balloting yes for his. I think its good work
and has lots of implementations. Note also that some of the
discuss points here should be easily resolved or are just
checking stuff. (Its in the nature of very very long
documents that the accumulation of such stuff generates more
discuss points.) Anyway, let's discuss...

(1) 2.3: What if the URI scheme doesn't have a host or port
or path or query?  Also in 5.6, 2nd bullet in list: Just to
note that if you were using ni URIs with CoAP, then you no
longer need to insist on exactly the same URI (e.g. the
authority part needn't matter with ni URIs, the alg-val part
is what counts). That might be true of other schemes too, so
perhaps this statment is scheme specific to some extent?
This is just a discuss point to check that you're ok with
CoAP being restricted to some URI schemes in this manner,
the ni URI case is just an example I happen to know fairly
well:-) So I'll clear this one when told that this is
considered acceptable but I want to check the general issue
about uri-scheme dependencies for CoAP. The same point
occurs in 5.7.1 and maybe elsewhere btw. So basic point is:
please provide some sensible description of which URI
schemes can be used with CoAP and which cannot.

(2) 4.2, "when the timeout is triggered" - what happens with
sleepy nodes that only wake on external events, and where
e.g. if 2 timeouts have elapsed whilst asleep? Not sure if
odd behaviour of that kind could cause much harm, but was it
considered? This could also affect the definition in 4.8.2
of MAX_TRANSMIT_SPAN.

(3) 4.2, last para: this creates an attack that can work
from off-path - just send loads of faked ACKs with guessed
Tokens and some of 'em will be accepted with probability
depending on Token-length and perhaps the quality of the RNG
used by the sender of the CON. That could cause all sorts of
"interesting" application layer behaviour. Why is that ok?
(Or put another way - was this considered and with what
conclusion?) I suspect you need to have text trading off the
Token length versus use of DTLS or else CoAP may end up too
insecure for too many uses. (Note: the attack here is made
worse because the message ID comparison can be skipped.
Removing that "feature" would help a lot here.) 5.3.1's
client "may want to use a non-trivial, randomized token"
doesn't seem to cut it to me. How does this kind of
interaction map to DTLS sessions/epoch? Basically, I'd like
to see some RECOMMENDED handling of token length that would
result in it not being unsafe to connect a CoAP node to the
Internet. (And please note recent instances where 10's of
thousands of insecure devices have been found via probing
the IPv4 address space. These are real attacks.)

(4) 4.4, implementation note - this seems unwise since it
means that once Alice has interacted with Bob, then Bob can
easily guess the message IDs that Alice will use to talk to
Charlie.

(5) 4.6, last para  - this only applies to insecure uses of
CoAP, you should point that out

(6) 6.2 - "the UDP datagrams MUST...use DTLS" is fine but
maybe not enough, if the request uses DTLS then presumably
so MUST *all* response messages, and they MUST use the same
DTLS session? Or perhaps one with the same authenticated
endpoints. Don't you need to say that? If you don't then
just sending the request via DTLS but getting (some)
response messages in clear would seem to be allowed.  I
think 9.1 might cover all the above, but want to just check.

(7) 9.1.1, 1st para: what is "the server" - is that the
destination host from the URI? If yes, then fine.  If no,
then we need to DISCUSS that. 

(8) 9.1.3.3 - "signed by an appropriate chain of trust" is
an odd phrase - do you mean it MUST be validated as per RFC
5280 section 6? If so, say so. If not, say what you do mean.
(But we might need to talk about it in that case,
depending;-)

(9) 9.1.3.3 - you don't mention certificate status checking.
I can see why that's hard to impossible in some n/w's but
entirely ignoring it seems wrong. Perhaps call out the
vulnerability and point at OCSP stapling as a potential
solution, but one that requires further work and/or further
specification?

(10) 10.1 - what does https mean here? If it means that
the request/response are in clear between the source and
proxy and then encrypted then a) you really really need to
say that clearly and b) why is that even acceptable and c)
what if the destination resource requires client auth? It
just seems broken to pretend to use https this way. Going
via a cross-proxy breaks security.  Similarly, what does
coaps mean in 10.2?

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

general: 112 pages, sheesh;-) Seriously though, there is
repetition here that'd be better not there and fewer words
is better. Too late now though.

abstract: "CoAP easily..." is a bit of sales-talk, better to
say "CoAP is designed to easily..."

intro, 2nd para: better to not talk about the WG name and
its work really, but about the resulting protocol

intro, 2nd para: suggest s/limiting the use of/limiting the
need for/

intro, last para: more sales pitch language

1.2, critical option - I wondered here if proxies have to
know these or just client & server.  "Endpoint receiving the
message" doesn't make that (ctystal) clear. "Unsafe Option"
made me wonder more. (It is clear later.)

2.2: This is the first time Token is used. Might be no harm
to distinguish that explicitly from Message ID.

2.3: For what "security reason" are proxies useful? 

3: Ver field "MUST set this field to 1" - I guess someone
might set both bits to 1, so saying '01'B might be better.

Section 3: I didn't see where Message ID wrap-around was
described. I see Martin has a discuss on that which I
support.

3: Message ID - with 16 bits that imposes a rate limit on
how often you can send. I don't think that's described and
I'm curious as to whether it'd set to max goodput for CoAP
that'd be way less than otherwise possible with e.g. HTTP.

3.2: So I can't have an option with a uint value where
missing != 0? Might be worth saying.

4.1: middle two paragraphs seem like repetition - maybe they
could be deleted?

4.2, 1st para, "acknowledge such a message" - do you mean
all CONs or just an empty CON? splitting up this para into a
few or using a bullet list or pseudo-code would be better I
think.

4.2, "a random number between 2 and 3" (replacing names with
defaults) - ought you recommend some minimun granularity
just in case some careless developer did something like:

       initialTimeout=ACK_TIMEOUT+
          rand()%(ACK_TIMEOUT*ACKRANDOM_FACTOR-ACK_TIMEOUT)

4.3, last sentence in parenthesis - I have no idea what that
means

4.4, last para: I just wonder if any NAT or v6 transition
schemes might invalidate this MUST?

4.6, 1st sentence: don't get that, maybe better deleted.

4.8.1, DEFAULT_LEISURE is in table 1 but not discussed until
section 8, a fwd ref at least would be good

5.2.2, "The server maybe initiates..." seems too casual.

5.3.1, 3rd para - the note about using the same token for
different source ports seems broken to me. I don't think you
say anything to the effect that the response has to go to
that source port.

5.4.6, option numbers can be 16 bits long, in that case bit
7 is not the lsb - does that need fixing? Similarly with
Figure 11.

5.5.2, I buy your argument here about language tagging, but
what happens at a CoAP->HTTP g/w? Doesn't language tagging
become an issue there? How's that handled?

5.10.1 - can any of the valid options for Host from 3986 be
used? e.g. IPv6 addresses as text in square brackets,
decimal form IPv4 addresses? You do have some guidance later
but I think that'd be bettern being more obvious.

5.10.5 - I'm probably just confused by reading so much;-) If
there are two Max-Age options, which wins? Where's that
stated in general?

5.10.8.1 - I don't get why its ok to not say which If-Match
to pick if more than one matches. Why's that?

6.1 - I don't get what you mean by saying that the coap URI
scheme "supports" /.well-known, maybe that'll be clear in
section 7. (I don't think it was.)

6.2 - s/for privacy// - DTLS does authentication, integrity
and confidentiality, not privacy

7.1 - what if I want to only do discovery via DTLS? What
does "support" mean for port 5683 then?

7.2 - I didn't really get how this works, but I assume that
if I re-read RFC6690, then I'd get it. Is that a good
assumption?

8.2.1, 1st para - this talks about "the cache" but I don't
think you've (so far) told me that clients that send
multicast requests have to have a cache for responses. Don't
you need to?

8.2.2 - Please make it clear(er) that bormann-coap-misc is
properly an informative ref. (Assuming it is.)

section 9, last para: what's that mean? I got the feeling
the text was trying to hide something from me fwiw.

6.5 - I thin you need a security consideration somwhere
about comparing coap(s) URIs and the potential for access
control screw-ups. 

9.1 - have people implemented the ECDH ciphersuites in CoAP
testing? Knowing if this is just text or also running code
might help discuss resolution.

9.1.3.3 - throwing in RSA as a SHOULD (albeit within a
section that's a MAY) is odd - if devices can do RSA then
why not have 'em all do it for the raw public keys and get
the interop gains that will accrue from that.

11.5 - this is a bit detailed, wouldn't a reference do
most of it?

12.7 - as it turns out I also don't see why this needs
two ports - the cost is two more bytes for security which
is significantly-enough less than the current cost (in
terms of message size) for security. Am I wrong?
 
Please also consider the secdir review [1] (if you've
not done so already, I do see a shepherd response).

   [1] http://www.ietf.org/mail-archive/web/secdir/current/msg03873.html

---

From: Carsten Bormann <[email-masked]>
Date: Sat, 27 Apr 2013 21:33:05 +0200

Stephen,

thank you for this comprehensive review.
I have done some of the changes as simple editorial fixes, these are
marked like [1316] below and can be reviewed in
http://trac.tools.ietf.org/wg/core/trac/changeset/1316
(Overview in http://trac.tools.ietf.org/wg/core/trac/timeline).

Some of the replies are marked "-> Ticket": This means that the
authors think that the change is a good idea, but probably needs a bit
more discussion with the WG, so we will handle this as a ticket.

Grüße, Carsten

        documents

... that they get longer with each review cycle, and ...

        that the accumulation of such stuff generates more
        discuss points.) Anyway, let's discuss...

That is a very good point.  I think what happens here is that some
schemes such as the ni scheme open a way of matching that is specific
to that scheme and not available in the default case.  We should add a
statement to this effect to the definition of "Cache-Key" that needs
to be added at the end of this section.

Add at the end of (the introduction to) 5.6:
»The set of options that is used for matching the cache entry is also
collectively referred to as the "Cache-Key".  For URI schemes other
than coap and coaps, matching of those options that constitute the
request URI may be performed under rules specific to the URI scheme.«

-> Ticket

The specification defines two URI schemes, coap and coaps.
It is probably a good idea to start some thinking about how RFC 6920
can be used, but that should be a separate specification.
So, I think, the answer is "any URI scheme defined to use the CoAP
protocol".  Do we need to state this explicitly?

The intention is that retransmissions stay in the overall envelope of
MAX_TRANSMIT_SPAN, even if they are not perfectly spaced.
Indeed, this could benefit from some additional discussion.
-> Ticket

        conclusion?)

Actually, the ACK would be matched on the Message ID (or I could
simply point to the penultimate paragraph of 5.3.1).  This is a
relatively powerful attack that could be added to the list in 11.4.
-> Ticket

        I suspect you need to have text trading off the

Well, ceterum censeo BCP39.
But it seems the discussion at the end of 5.3.1 could make the
security considerations for selecting a token value in NoSec mode more
explicit.  Right now the basic consideration, but not the parameters
that go into it, is discussed in 11.4 as well.
-> Ticket

Not every CoAP client will have the means to keep state per peer server.
(It is not quite "once Alice has interacted", because the initiator of
an exchange chooses the Message ID.  But it is often not too hard to
trick Alice into initiating an exchange.)

"can" is indeed probably too strong.
-> Ticket

This is implicit in the fact that all exchanges (except for multicast)
use the same pair of endpoints for both directions, so you simply
can't reply via NoSec to a DTLS message.  It probably doesn't hurt to
make that explicit somewhere.
-> Ticket.

Yes, it is.

We probably should say:
The certificate MUST be validated as appropriate for the security
requirements, using functionality equivalent to the algorithm
specified in RFC5280 Section 6.
-> Ticket.

Yes, we should point this out.
-> Ticket

        what if the destination resource requires client auth?

Well, it is way worse, because the proxy needs to decide on the
security policy that it wants to apply to the TLS connection
underlying HTTPS.  This kind of proxy function only makes sense if the
proxy has a legitimate role in the trust chain, e.g. as a domain
boundary controller.  In constrained node networks, this is actually a
likely use case.

        It just seems broken to pretend to use https this way. Going
        via a cross-proxy breaks security.  Similarly, what does coaps
        mean in 10.2?

Again, doing this kind of proxying only makes sense if the proxy has a
legitimate role.

(See above...)

[1316]

We used the "CoRE" tag in RFC 6690, and would like to continue using
it, for the overall architecture that the CoAP protocol is a part of.
(If that is a problem, please rename all MPLS documents first :-)

[1317]

But it's all true and not even exaggerated!

Hmm.  See my attempt in [1320].

[1318]

The domain boundary controller one (see above).

[1319]

(See my reply there.)

        how often you can send. 

The rate limit is ~ 250 messages per second per pair of endpoints with
default parameters.

        I don't think that's described

It will be described in the LWIG documents that are discussing Message
ID management in more detail.

        and I'm curious as to whether it'd set to max goodput for CoAP
        that'd be way less than otherwise possible with e.g. HTTP.

Answer: Yes.  (~ 250 KiB/s with default parameters and large messages;
20 kB/s with more realistic 80-byte messages.)  If you need faster,
please use TCP (you will get better congestion control, too).

I'm not sure I'm decoding this sentence correctly, but a present
option with a zero-byte uint (value 0) is distinguishable from an
absent option.  E.g., Max-Age has a default value (that is used if the
option is absent) of 60 (seconds).  If the option is present with a
zero-byte value encoding, the default is overridden and Max-Age is set
to 0.

In teaching, I love repetition, if it is done at the right place.
This is trying to recap types and codes, and I think it is at the
right place.

I don't want to hixiefy the spec too much (section 6 is worse enough).
Just fixed the specific problem: [1321]

I'm not sure there is a good basis for defining a specific minimum
granularity.  This is a good observation for the LWIG implementation
guidance draft, though.
For the specification, I slightly clarified: [1324]

It means that, since RSTs can refer to both CONs and NONs, you need to
avoid using the same Message ID for a CON and a NON during the time
you might hit a RST.

This is a matching rule that is enforced at the endpoint that sent a
CON/NON.  If the NAT/transition scheme breaks the property that when
you send a message to IP address X and Port Y, you get back the reply
message from IP address X and Port Y, CoAP is not going to work over
it.  (Neither will DNS or anything else much, so I hope no such NAT or
transition scheme is deployed widely).  By the way, it also means you
fundamentally can't do ACKs to a multicast message, because they won't
match.

This is trying to alert implementers to the fact that there may be
overriding concerns with respect to the choice of a message size that
are not part of the CoAP spec.

[1322]

[1323]

This is implied in the endpoint concept.  A different port is a
different endpoint is a different client.  (What the introduction to
5.3 is really trying to say is that the token space is per
endpoint-pair.)

Clarified some more: [1325]
(Figure 11 is fine, because this operates on the actual number.)

This is best compared to the human-readable component of the HTTP
status line, called Reason-Phrase in RFC 2616 and reason-phrase in
section 3.1.2 of draft-ietf-httpbis-p1-messaging-22.txt.
We mainly simplify this from "an encoding that is a superset of
US-ASCII [USASCII]" to "UTF-8".  It is unlikely that constrained node
implementations will need a language-tag here more urgently than HTTP
users.

Unfortunately, CoAP needs to use URIs pretty much as-is, so it does
import all this complexity.  Note that the default value of Uri-Host
already uses an IP address, so the need for address literals should be
clear from the context.

For options that are not specified as repeatable (table 3),
supernumerary option instances are interpreted according to 5.4.5
(which we just fixed slightly in [1308]).

There is only one current representation of the target resource.  If
that matches any of the If-Match options, the condition is fulfilled.
Essentially, you can say "if the resource has value a or b, replace it
with the payload c of this message".  Whether it had value a or b does
not matter, because there is only one replacement value c that can be
given.  (If that is not the intention, there is no way to say this
with what we have.)

RFC5785:
   A well-known URI is a URI [RFC3986] whose path component begins with
   the characters "/.well-known/", and whose scheme is "HTTP", "HTTPS",
   or another scheme that has explicitly been specified to use well-
   known URIs.

We thus explicitly specify that usage for the COAP scheme (and by
derivation in 6.2 for COAPS).

Oops.  [1326]

Well, what links exactly you offer there is up to the server.
But the current text says that if you do any resource discovery at
all, you also MUST provide something via CoAP over UDP on port 5683.
There is a trade-off between security and manageability here.
Using this, I can find out that a node does speak CoAP, and if it
wants to make any (e.g. management) resources widely available, it can
offer them there.
(We can argue how MUSTy that MUST must be.  E.g., RFC 4443 requires
any router to send an ICMPv6 Time Exceeded message with Code 0 in
response to a packet sent to it that is formed in a certain way.  On
the other hand, there is only a "MUST implement" on the ICMP echo
function.)

You probably need to read the whole tome on Web linking (starting from
RFC 5988) as well; reading draft-shelby-core-resource-directory-05.txt
won't hurt either.  There is a lot of interest in making this work
well for Smart Object Networks, so I expect documentation to grow in
this space.

s/the/a/ [1327]

s/a/one/ [1328]

To the contrary, it is making very explicit some important limitations
on what the current authorization can do.  Essentially, you can only
be secure through a proxy using either object security (end-to-end) or
when the proxy actually is part of your security model.

Good point.
-> Ticket

Don Sturek reported on the list that multiple interoperable
implementations exist (and obtained ZigBee IP certification) for
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, also using it with (TCP) TLS for
SEP 2.0.  Zach Shelby reports they have the same ciphersuite running
with DTLS/CoAP (CoAPS).

Various open source implementations of CoAPS are ongoing.
Matthias Kovatsch reports on the list:
Californium has a full CoAPS implementation (PSK, ECDHE,
RawPublicKeys, Certificates):
https://github.com/mkovatsc/Californium
We had DTLS interops with Bremen (TinyDTLS), SICS (JCoAP + own DTLS),
and Silicon Labs (own DTLS, unknown CoAP).
PSK worked with all of them.
ECDHE was tested successfully with SICS and Silicon Labs.
Mutual Authentication was working with SICS.
Fragmentation and RawPublicKeys could not be tested for
interoperability with others so far, but it works with Californium
only nodes.

Well, this is for the (somewhat high-end) case of cert usage.

WG: Is there a cipher suite that better its the other ones we use?
E.g., Why didn't we use TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA (RFC 5489)?
I notice that in the transition from -05 to -06, we got rid of
TLS_RSA_WITH_AES_128_CBC_SHA in favor of
TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, but not of
TLS_RSA_PSK_WITH_AES_128_CBC_SHA.  The changes comment is "DTLS cipher
suites aligned with ZigBee IP, DTLS clarified as default CoAP security
mechanism (#138, #139)".
http://trac.tools.ietf.org/wg/core/trac/ticket/139 mentions
TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8, but
not anything about the cert-with-PSK case.

-> Ticket

It may be a bit graphic, but I don't know a good reference discussing
CoAP cross-protocol attacks.  Just discussing them in general terms
didn't seem to cut it.  (And the secdir reviewer liked the text :-)

On constrained node networks, we are fighting for every byte.  GHC
gives us back most of what DTLS and the relevant ciphersuites waste a
bit carelessly, so we mostly pay for the authenticator, and that is
money (battery) well-spent.  There are indeed good ways to multiplex
on the first byte of the message (we effectively use only 1/4 of the
space), but that would require the cooperation of the TLS WG, and we
removed this feature between coap-06 and coap-07 (we discussed this
again in the Atlanta TSVAREA meeting,
http://www.ietf.org/proceedings/85/minutes/minutes-85-tsvwg).
So for now, the second port is the way we arrived at.

The comments from that review should have been covered in -15 already.

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 28 Apr 2013 17:01:14 +0100

Hi Carsten,

> (Overview in http://trac.tools.ietf.org/wg/core/trac/timeline). 

FWIW, I'm not finding the above that useful but will check
a diff when an updated I-D is produced so that's ok.

I only responded to some bits below, I expect the rest will
be worked out as we go, if they're not already pretty obvious.

> more discussion with the WG, so we will handle this as a ticket.

I think you do since you refer to carrying http and https
URIs and I guess folks may well try ftp URIs with CoAP
or maybe even mailto, who knows.

I've no strong opinion as to what you ought say about
schemes other than coap(s) but I think you do need to say
something. (BTW, 6920 is not an important case here at all,
maybe it was a bad example to pick, even if it is one that
highlights some of this.)

> relatively powerful attack that could be added to the list in 11.4.

Not sure we're talking about the same thing, so just to
check.

Figure 5 shows the nominal behaviour, the variant on
that below (use fixed width to see it) tries to show
the attack.

                         Client              Server
                            |                  |
                            |   CON [0x7a10]   |
                            | GET /temperature |
                            |   (Token 0x73)   |
                            +----------------->|
                            |                  |

                            |                  |
                            |<-----------------+
                            |<-----------------+
 bad guy sends loads of     |   CON [0x23bb]   |
 these, this one matches    |   2.05 Content   |
 the token value            |   (Token 0x73)   |
                            |    "-273.15 C"   |
                            |<-----------------+
                            |<-----------------+
                            |<-----------------+
                            |                  |
 this is the original ack   |   ACK [0x7a10]   |
 but bad guy has won the    +----------------->|
 race already               |                  |

So in the above scenario the bad guy only needs to
match the Token value to achieve his intended
chilling effect:-)

I think the fix here is to disallow accepting the bad
guy's message there by saying that you can only do that
with an at-least N bit Token where maybe N=80 or so.
N ought be whatever we think will be safe to use when
directly connecting a CoAP node to the Internet for
the next few (5?) years at leats.

I'd also like to argue for a RECOMMENDATION that the
combined length of Message ID + Token be at least
N bits, for the same N, for the same basic reason.

> trick Alice into initiating an exchange.)

Not sure if you're proposing to change that or not. I'd say
describing a case where Message IDs are always random would
be better.

>         then we need to DISCUSS that. 

Great.

> Again, doing this kind of proxying only makes sense if the proxy has a

Hmmm. I suspect we'll want to chat more about this one.
I don't see how the sender can in general know whether
or not a "legitimate" proxy is going to do the right,
or entirely wrong, thing. I also think that if an HTTPS
endpoint somewhere on the Internet hands out an https URL
then the current scheme doesn't meet their expectations
in quite a bad way.

Your responses to the comments are almost all ok - close
enough to skip quibbling anyway:-) But I'm happy to chat
if there're ones that need that.

Cheers,
S.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Apr 2013 13:31:52 +0200

> then the current scheme doesn't meet their expectations

So let's talk about the proxy thing.

A forward proxy is explicitly chosen by the client.
One would expect the client to choose a proxy that will fit to its security requirements.
(Assuming that the client cannot talk https directly, which would always be preferable.)
What can we do in the protocol to make this work better?

A reverse proxy somehow managed to get itself accepted in the DTLS handshake.
So it seems to work together with the origin server, which we hope will work with it on its security requirements.
Again, what can we do in the protocol to make this work better?

The underlying problem, again, is that a coaps (or https) URI only gives a boolean "be secure", but doesn't tell you what the kind of security assurance is that you need.  I think that is an important thing to work on (many people actually strongly disagree with that).  I just think it is more general about the use of URIs in the Web, not just about the CoRE part of it.  In the HTTP world, we are using HSTS to augment the security semantics of an http URI out of band, cert pinning or trying to add things from the DNSSEC side does the same for https URIs.

We also have to think about what the equivalent to an httpauth would be in the CoRE world.
What we can do at the moment is authentication via DTLS, keeping authorization completely outside the protocol.  You cannot help a proxy authenticate to the next endpoint.  Some form of delegated authorization will also need to be added, and that will have to work through proxies, too.  A student here actually implemented a form of OAuth 2.0 proxy, in order to be able to talk to a google+ service from a CoAP client.

Grüße, Carsten

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 29 Apr 2013 15:13:04 +0100

> One would expect the client to choose a proxy that will fit to its security requirements.

Yeah. Doesn't always happen though.

> What can we do in the protocol to make this work better?

Yes, if (D)TLS works from the client that's better. Sure.

However, as-is, I think the spec says that a client with a
configured forward proxy just sends all https or coaps URIs
in clear to that proxy and gets responses in clear. Is that
right?

I note that that forward proxy is also allowed to have
another forward proxy, so in practice a coaps or https
request could get all the way to the origin server with
only the very last hop using (D)TLS.

I assume someone suggested at some point to never send
coaps or https out in clear. What was the winning argument
against that? (A pointer to the list archive will do if
there's a good thread.)

> Again, what can we do in the protocol to make this work better?

I'm less sure here to be honest. On the web most reverse
proxies are tightly coupled to the "real" application
server in a maybe-secure environment (e.g. a DMZ) - is
that considered likely to be the same with CoAP?

I guess scenarios where a UA on the Internet accesses
an actuator via a coaps or https URI but where there's a
cleartext CoAP exchange between a reverse proxy and the
actual actuator node might be somewhat to very scary.
(And I could see people deploying that with crappy or
no authentication too since it'd be "encrypted over
the Internet" according to their marketing literature;-)

> What we can do at the moment is authentication via DTLS, keeping authorization completely outside the protocol.  You cannot help a proxy authenticate to the next endpoint.  Some form of delegated a…

I agree that the above are good things for future work, i.e.
the DISCUSS isn't saying that I think you need to solve
e2e authentication and authorization now for all proxy
scenarios.

Cheers,
S.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 29 Apr 2013 22:26:20 +0200

> in clear to that proxy and gets responses in clear. Is that

I sure hope it doesn't say that.
We may never have written anything about this because it seemed obvious.
(I know, famous last words.)

In 11.2, we are discussing security and caching in a proxy.

We could insert something between the first and second paragraph, as in:

"The security properties of (a) the exchange toward the proxy, (b) the handling of the data in the proxy and (c) the exchange from the proxy onward, all contribute to the overall security properties.  Note that (c) includes the transitive closure of the security properties encountered in conjunction with any further proxies on the way.  Trivially, a client that chooses a forward proxy needs to ensure that the security properties it expects from its choice of URI scheme (e.g.,  HTTPS or CoAPS) are actually provided by the proxy [c] and that the exchange towards the proxy [a] and the data handling inside the proxy [b] are also compatible with these security properties.  Similarly, a reverse proxy that is addressed via CoAPS or HTTPS needs to ensure the security properties desired by its client are preserved by its own data handling [b] and on the way towards the origin server [c].  In most cases, this means that a CoAPS or HTTPS exchange is forwarded as a CoAPS or HTTPS exchange on the next leg."

Or so.

Grüße, Carsten