Subject: [core] Stephen Farrell's Yes on draft-ietf-core-coap-17: (with COMMENT)

From: "Stephen Farrell" <[email-masked]>
Date: Sun, 26 May 2013 13:54:30 -0700

Stephen Farrell has entered the following ballot position for
draft-ietf-core-coap-17: Yes

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.

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

Thanks for addressing my discuss points. I've left the comments
in below from last time, but didn't check 'em against -17.

--- 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.