Subject: [core] Review of draft-ietf-core-coap-03

From: Eric Rescorla <[email-masked]>
Date: Sun, 7 Nov 2010 13:28:49 -0800

I've reviewed this document. Comments below.

My concerns here are primarily about the security parts, which seem a
bit handwavy. It's certainly possible to build systems where all the
security provided by channel security mechanisms (IPsec and DTLS) but
can't tell if this is such a system without more security analysis.

In particular:
- What's the general trust model in terms of the relationship between
  the servers and clients?
- What are the assumed capabilities of the devices in question?
- How is access control expected to behave with respect to proxy caches?
  (The HTTP story is clear but you've stripped out the HTTP access
  control mechanisms). I don't see how a server even verifies a
  client who goes through a cache.
- I'd like to see some discussion of cross-protocol attacks, which
  seem likely with the NoSec mode.

IPsec
You don't actually say this, but I'm assuming that you intend to
use IPsec's manual keying mode, rather than IKE. If so, this seems
to have a series of obvious problems around the lack of guaranteed
fresh keys/nonces, as well as replay attacks. In particular, if
you're going to have single-packet messages which control network
devices, it seems like anti-replay is very important, but RFC 4303
says:

   If the key used to compute an ICV is manually distributed, a
   compliant implementation SHOULD NOT provide anti-replay service.  If
   a user chooses to employ anti-replay in conjunction with SAs that are
   manually keyed, the sequence number counter at the sender MUST be
   correctly maintained across local reboots, etc., until the key is
   replaced.  (See Section 5.)

This seems like a fairly problematic combination and at minimum
needs some discussion.

I'm similarly concerned about the use of CCM, which fails
catastrophically in the face of replayed packets. I'd like to
understand how you're going to assure that the nonce is never replayed
in the face of very long-lived keys used throughout a large network.
Recall that the birthday limit for AES-CCM in ESP is only 2^{32}
packets, but even that's for ~0.5 probability of replay. The security
is weakened long before that.

IMO it's very unwise to use ESP this way w/o at minimum some form of
automatic key diversification.

DTLS
The claim that DTLS is an order of magnitude more complicated than CoAP
is unsupported and, for instance, if we're just counting pages that doesn't
appear to be correct. Certainly, if you just do TLS_PSK modes, that's
not correct. In my experience, the majority of the code in a TLS stack
is the crypto algorithms and the certificate processing. You will
need the crypto algorithms in any case and the PSK profile you have
chosen does not require certificates. If this is the basis for thinking
that DTLS inadequate, you may want to rethink that. Regardless, please
please remove this claim.

Similarly, I don't know what "appreciable handshake overhead" means.
Please provide some measurements for the profile you have chosen or
remove this as well.

The particular TLS PSK mode you specify has no private entropy other than
from the shared key. If you are going to select this mode, you need
language about the minimum entropy of the PSK. This is an issue for
IPsec as well, btw.

The PSK modes are not specified in 5246, so please fix this citation.

Throughout the document you write "cypher suite". The TLS term is "cipher
suite"

The question of whether you should use certs is quasi-orthogonal to whether
you use TLS_RSA_PSK. You can use self-signed certs with TLS_RSA_PSK.

S 10.3.1.
This seems kind of superfluous. Code in general has bugs and it's not
clear that "stringent tests" are that useful for finding them.

-Ekr