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

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 13 May 2013 09:16:28 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-core-coap-16: 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 (still:-) end up balloting yes for his. 
Just one DISCUSS point remaining.

(1) Cleared, but see comment below

(2) Cleared. 

(3) Cleader, but see comment below.

(4) Cleared, but see comment below.

(5) Cleared.

(6) Cleared.

(7) Cleared.

(8) Cleared.

(9) Cleared.

(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? We had some mail exchanges about that,
but I'm not sure I'm ok with the outcome so I'd like to
DISCUSS this some more. (And did any of that get into 
-16? Not sure.)

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

--- former discuss points

(1) I think you made a change to 5.6 for this but I still
think (now at COMMENT level) that it'd be really good to say
that CoAP is currently well defined only for URI schemes like
coap(s) and http(s) but maybe not others. Basically, you need
a scheme://host:port syntax or else you have to do some more
specification work to get CoAP interop.

(3) You now say "SHOULD use 32 bits of randomness" which
is ok. I think it might be worth adding that CoAP nodes
that might be targetted with many guesses SHOULD also  
detect and react to that.

Text of discuss (3) was:
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. This is no longer a DISCUSS because you said that
the WG figure its ok and given you say to randomise at
the start (of what?) then its marginal. 

--- old comments below, sorta checked against -16 

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

intro, last para: more sales pitch language

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.
- I think in a mail Carsten said its 250/second max or 
something, I still think this'd be great information to
say explicitly early on in the spec since it might prevent
someone spending a lot of effort before they find out that
CoAP doesn't work for their use-case.

7.1 - what if I want to only do discovery via DTLS? What
does "support" mean for port 5683 then? Carsten said that
you do need to still listen on 5683 even if you only
want to do work on <TBD>. I'm not so happy about that but
its not DISCUSS level.

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? Carsten
responded: "yep, that's what we want" and I'm ok with that,
if not convinced.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 14 May 2013 08:37:19 +0200

> DISCUSS this some more. (And did any of that get into 

So what should we do?
In my original reply, I tried to express that I'm not aware of a technical solution here.

The underlying problem is that it is not defined which security properties an https (or coaps) URI is supposed to have.

More amicably stated, it is the endpoint originating the https (or coaps) request that defines those security properties based on some context outside that URI.  So if a client asks a proxy to originate such a request, it also delegates setting up the specific security properties to that proxy.  E.g., the proxy is the one to select its set of trusted root certificates, and it may even be able to select a client certificate and other security parameters (httpauth...) based on the authorization status of the original requestor mediated through the security policies of the proxy.

In all cases, the proxy is part of the security chain.  Using a random proxy the security properties of which have not been established gives you no security whatsoever.  We could say that much in section 5.7, at the start of section 10, or in section 11.2.  In any case, these considerations are not specific to section 10 -- this may just merit an additional mention that the CONNECT-based security model of https does not carry over to CoAP cross-proxying.

Mixing secure and insecure legs on the way to an origin server may be quite appropriate based on the security properties of those legs -- e.g., converting from https to http is quite common with reverse proxies in a load balancing server farm.  Again, this is something that requires consideration of the whole chain.  In any case, I wouldn't want to forbid a proxy "upgrading" security (i.e., using https/coaps to forward a request that it received via http/coap), and I wouldn't want to forbid an originating node upgrading security on the leg to the proxy, even if it knows that the next leg will base its security properties not on https/coaps but something else (an initial coaps leg may also be required simply because DTLS is the way the CoAP client authenticates to the proxy).

Grüße, Carsten

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 May 2013 11:17:52 +0100

Hi Carsten,

>> DISCUSS this some more. (And did any of that get into 

First, clarity. I'm not sure I'm entirely clear on what's
what here. Then we can go from there.

Let me see if my understanding of forward proxies at
least is correct:

(1) a CoAP node with no forward proxy MUST try directly
connect to the authority in a coaps URL via DTLS.

(2) a CoAP node with no forward proxy does nothing with
an https URL - if it does something then its being an
HTTP node and RFC 2818 applies not the CoAP spec.

(3) A CoAP node with a forward proxy MUST send all
coaps and https requests in clear to that (one?)
forward proxy on port 5683.

(4) There is no provision for "don't proxy for these
domains" as there is in web browsers. Though that's
not a part of HTTP, maybe it, or something like that,
ought be part of CoAP? Do people implement that kind
of thing anyway?

(5) A forward proxy (p1) that receives a request MUST
try connect directly to the authority from the coaps
or https URL via (D)TLS if p1 has no forward proxy.
If p1 also has a forward proxy configured then p1
MUST also forward the request in clear to 5683. So only
the last forward proxy ever attempts (D)TLS. And nobody
earlier in the chain can tell which is the last proxy.
Nor can the (D)TLS server tell if the (D)TLS client
is a proxy.

(6) CoAP coaps/https proxying breaks (D)TLS client
authentication. If client authentication in (D)TLS is
requested by the (D)TLS server, then with CoAP the only
relevant client private key is the one that the "last
proxy" has.

Is the above correct? If not, where am I wrong?

I think once I have a correct understanding of the above
then I'll be able to think about reverse proxies, esp.
cases where the reverse proxy is in front of a bunch
of challenged CoAP nodes. (Which I guess is pretty different
from how HTTPS reverse proxies are deployed when they're
acting as TLS accellerators/load-balancers.)

So far, I'm thinking that DTLS as used with CoAP maybe
has a lot in common with ESP in IPsec, e.g., assuming
no change is made to the protocol, perhaps there's a
need for a security policy DB. But let's make sure I'm
not confused first, since I am often confused;-)

Ta,
S.

PS: I (dis)agree with various bits of text below, but let's
make sure we're on the same page before we go there.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 14 May 2013 13:52:31 +0200

Hi Stephen,

indeed, discussing this based on concrete examples probably works best.

> connect to the authority in a coaps URL via DTLS.

Yes.

> HTTP node and RFC 2818 applies not the CoAP spec.

Yes.

> forward proxy on port 5683.

We haven't defined how a CoAP node acquires a forward proxy and what URIs that then pertains to.
The thinking is indeed that this will be a client-local function.
I would expect the forward proxies for coaps and https URIs to be configured with security (i.e., via coaps).
This is necessary if there is any authentication required towards the proxy.
Does the current text imply that requests to a forward proxy always go in NoSec mode?
That would be a bug.

> ought be part of CoAP? Do people implement that kind

I haven't done a survey of what people are doing with forward proxies.
My personal experience is mainly with cross-proxying, and there is little use there for a "don't proxy for these domains".  We don't even expect to use domain names in many very constrained nodes, so one likely configuration would be "use the proxy if a regname authority is present, go direct if there is an IP literal".

> or https URL via (D)TLS if p1 has no forward proxy.

Indeed, that is implied by the URI scheme.
(Again, the open issue is what the security parameters are for that instance of (D)TLS.)

> MUST also forward the request in clear to 5683.

(See above.)

> So only
> the last forward proxy ever attempts (D)TLS.

(See above.)

> And nobody

Indeed.

> Nor can the (D)TLS server tell if the (D)TLS client

Right.  Something like forwarded-for would enable that.  However:
1) We haven't had the requirement stated yet,
2) this would probably be the most complicated CoAP option we have,
3) when that was discussed in the hallways, HTTP's Forwarded: was still up in the air,

> relevant client private key is the one that the "last

It "breaks" (D)TLS client authentication if that is intended for end-to-end use.
It actually enables client authentication if the proxy is a gateway between two security domains, i.e. it authenticates its client in one way and then maps this to an appropriate client identity for the origin server.

> acting as TLS accellerators/load-balancers.)

Certainly different, but in both cases the proxy/load balancer may have the role to "protect" the origin servers

> not confused first, since I am often confused;-)

A proxy that is gatewaying between two security domains certainly needs some form of policy table.
But this will be in terms of client and server identities and URIs, not in terms of IP addresses and ports.

Grüße, Carsten