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

[Stephen Farrell <[e-mail]>]

Hi Carsten,

On 04/27/2013 08:33 PM, Carsten Bormann wrote:
> 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). 

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.

> 
> 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
> 
> 
>         ----------------------------------------------------------------------
>         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 they get longer with each review cycle, and ...
> 
>         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?
> 
> 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
> 
>         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.
> 
> 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?

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

> 
>         (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.
> 
> 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
> 
>         (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?)
> 
> 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

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.


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

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.

> 
>         (5) 4.6, last para  - this only applies to insecure uses of
>         CoAP, you should point that out
> 
> "can" is indeed probably too strong.
> -> Ticket
> 
>         (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.
> 
> 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.
> 
>         (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. 
> 
> Yes, it is.

Great.

> 
>         (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;-)
> 
> 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.
> 
>         (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?
> 
> Yes, we should point this out.
> -> Ticket
> 
>         (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?
> 
> 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.

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.

> 
>         ----------------------------------------------------------------------
>         COMMENT:
>         ----------------------------------------------------------------------

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.

> 
>         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.
> 
> (See above...)
> 
>         abstract: "CoAP easily..." is a bit of sales-talk, better to
>         say "CoAP is designed to easily..."
> 
> [1316]
> 
>         intro, 2nd para: better to not talk about the WG name and
>         its work really, but about the resulting protocol
> 
> 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 :-)
> 
>         intro, 2nd para: suggest s/limiting the use of/limiting the
>         need for/
> 
> [1317]
> 
>         intro, last para: more sales pitch language
> 
> But it's all true and not even exaggerated!
> 
>         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.)
> 
> Hmm.  See my attempt in [1320].
> 
>         2.2: This is the first time Token is used. Might be no harm
>         to distinguish that explicitly from Message ID.
> 
> [1318]
> 
>         2.3: For what "security reason" are proxies useful? 
> 
> The domain boundary controller one (see above).
> 
>         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.
> 
> [1319]
> 
>         Section 3: I didn't see where Message ID wrap-around was
>         described. I see Martin has a discuss on that which I
>         support.
> 
> (See my reply there.)
> 
>         3: Message ID - with 16 bits that imposes a rate limit on
>         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).
> 
>         3.2: So I can't have an option with a uint value where
>         missing != 0? Might be worth saying.
> 
> 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.
> 
>         4.1: middle two paragraphs seem like repetition - maybe they
>         could be deleted?
> 
> 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.
> 
>         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.
> 
> I don't want to hixiefy the spec too much (section 6 is worse enough).
> Just fixed the specific problem: [1321]
> 
>         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)
> 
> 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]
> 
>         4.3, last sentence in parenthesis - I have no idea what that
>         means
> 
> 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.
> 
>         4.4, last para: I just wonder if any NAT or v6 transition
>         schemes might invalidate this MUST?
> 
> 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.
> 
>         4.6, 1st sentence: don't get that, maybe better deleted.
> 
> 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.
> 
>         4.8.1, DEFAULT_LEISURE is in table 1 but not discussed until
>         section 8, a fwd ref at least would be good
> 
> [1322]
> 
>         5.2.2, "The server maybe initiates..." seems too casual.
> 
> [1323]
> 
>         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.
> 
> 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.)
> 
>         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.
> 
> Clarified some more: [1325]
> (Figure 11 is fine, because this operates on the actual number.)
> 
>         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?
> 
> 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.
> 
>         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.
> 
> 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.
> 
>         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?
> 
> 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]).
> 
>         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?
> 
> 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.)
> 
>         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.)
> 
> 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).
> 
>         6.2 - s/for privacy// - DTLS does authentication, integrity
>         and confidentiality, not privacy
> 
> Oops.  [1326]
> 
>         7.1 - what if I want to only do discovery via DTLS? What
>         does "support" mean for port 5683 then?
> 
> 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.)
> 
>         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?
> 
> 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.
> 
>         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?
> 
> s/the/a/ [1327]
> 
>         8.2.2 - Please make it clear(er) that bormann-coap-misc is
>         properly an informative ref. (Assuming it is.)
> 
> s/a/one/ [1328]
> 
>         section 9, last para: what's that mean? I got the feeling
>         the text was trying to hide something from me fwiw.
> 
> 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.
> 
>         6.5 - I thin you need a security consideration somwhere
>         about comparing coap(s) URIs and the potential for access
>         control screw-ups. 
> 
> Good point.
> -> Ticket
> 
>         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.
> 
> 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.
> 
>         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.
> 
> 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
> 
>         11.5 - this is a bit detailed, wouldn't a reference do
>         most of it?
> 
> 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 :-)
> 
>         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?
> 
> 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.
> 
>         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
> 
> The comments from that review should have been covered in -15 already.
>