Subject: Re: [core] Stephen Farrell's No Objection on draft-ietf-core-observe-14: (with COMMENT)

From: Klaus Hartke <[email-masked]>
Date: Mon, 22 Sep 2014 16:00:46 +0200

Hi Stephen,

thank you for your review and questions.

Stephen Farrell wrote:
> - You probably won't want to but I'll ask anyway, just in
> case:-) The timing and sizes of notifications could expose
> sensitive information to a network attacker even if encrypted.
> TLS 1.3 is considering providing padding but TLS 1.2 and
> earlier don't really. HTTP/2.0 is also considering allowing
> padding. So should CoAP allow for padding in general, and if
> so, should this extension also? Or, is there a way to get the
> same result by sending out-of-date or other notifications that
> won't be accepted by the observer? If so, might it be worth
> documenting that? (However, it'd probably be better if both
> sides knew what was going on.)

That's a good question, and an important one. However, I feel that
this topic is something that should be discussed for the 'Internet of
Things' at large, not only in the scope of this extension of CoAP.

The two sides directly oppose each other: on the one hand we want to
minimize energy consumption (which is dominated by sending and
receiving messages), want timely delivery of messages and want small
messages; on the other hand techniques such as padding or sending
invalid messages increase the footprint until the signal cannot be
distinguished from the noise.

I guess the result will be highly application-dependent. The draft
currently does not try to provide any general privacy-enhancing
features.

> - I expected to see something about DTLS in section 7. Is
> there really nothing to be said about session lifetimes or
> expiry or keep-alives?  Has anyone tried this protocol over
> DTLS in the interops?

I've added the following paragraph to the end of Section 7:

   Resources can be observed over DTLS-secured CoAP using any of the
   security modes described in Section 9 of RFC 7252.  The use of DTLS
   is indicated by the "coaps" URI scheme.  All notifications resulting
   a GET request with an Observe Option MUST be returned within the same
   epoch of the same connection as the request.

I'm currently not aware of any issues related to session lifetimes or
keep-alives. But that may be simply because there are not many
implementations of this protocol running over DTLS yet. The DICE
working group is looking into questions like these.

The interops only tested short-term interactions (seconds to minutes),
not long-term interactions that could have led to session lifetime
problems.

Klaus

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Sep 2014 11:38:08 +0100

Hi Klaus,

> currently does not try to provide any general privacy-enhancing

Fair enough. I'm not surprised you'd prefer to not add a huge
new rat's nest to this document:-) Would someone here be willing
to/interested in bringing up that discussion in the core wg?
(Assuming that's the best current venue.)

In addition to the points you raised above, it could also be
the case that the best way to handle any such traffic is
between middleboxes (e.g. to accept that from within the home
you can detect things that are no longer detectable only
looking at traffic to/from the home). There'd also be trade
offs there related to the possible locations of such padding
or stripping middleboxes and real application endpoints. I
just mention this as it'd be an example of a kind of solution
that is not application specific which brings its own pros
and cons, I'm not saying a middlebox based approach is better.

>    epoch of the same connection as the request.

Fair enough again.

> not long-term interactions that could have led to session lifetime

Ah. Wouldn't that be worth considering? (Even if not for or in
this draft.) I can see problems possibly arising otherwise, and
if they do, then we'll need to fix 'em back here in the IETF I
guess - if different implementers/deployers handle that in
different ways I could see resources on devices being uselessly
consumed leading maybe to a DoS like effect in the worst case.

Cheers,
S.

---

From: Olaf Bergmann <[email-masked]>
Date: Tue, 23 Sep 2014 13:06:53 +0200

Hi Stephen, Klaus,

>>    epoch of the same connection as the request.

I read the last sentence in Klaus' new text that an observe relationship
ends when the DTLS session is renegotiated. To me, this looks odd from a
logical perspective as the renegotiation aims at continuing the ongoing
session -- the observer now has the additional burden of refreshing the
observe relationship. From an implementers perspective, this also means
that the CoAP layer needs to detect DTLS session renegotiation.

Gruesse
Olaf

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 23 Sep 2014 15:33:14 +0200

Stephen Farrell wrote:
> Klaus Hartke wrote:

It's unclear to me how session lifetimes work exactly in DTLS, so,
yes, I think this would be worth considering. The problem is not
specific to the "CoAP observe" protocol, though; it applies to any
long-term interactions over DTLS. I think draft-ietf-dice-profile [1]
would be a good place to write this down. Indeed there is already some
text on keep alives [2].

Klaus

[1] https://tools.ietf.org/html/draft-ietf-dice-profile-04
[2] https://tools.ietf.org/html/draft-ietf-dice-profile-04#section-10

---

From: Klaus Hartke <[email-masked]>
Date: Tue, 23 Sep 2014 15:40:46 +0200

Olaf Bergmann wrote:
>>>    is indicated by the "coaps" URI scheme.  All notifications resulting from

I'm not a security expert, but I vaguely remember some attack that
involved sending a request in one epoch and sending the response after
renegotiation in another epoch. That's why I put that sentence in. I
might misremember this, though, in which case I would agree that
re-establishing the observation should not be necessary.

Klaus

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 23 Sep 2014 14:46:27 +0100

On 23/09/14 14:33, Klaus Hartke wrote:
> I think draft-ietf-dice-profile [1]

Ah yes, that's a fine idea and a good place for that. Be great if
you could make a comment to the dice list on that so's it's more
likely to be tracked.

S.