Subject: Post-last-call review of draft-ietf-core-object-security-09

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Mar 2018 13:14:16 +1100

I have a number of concerns.  Primarily:

* This is only a partial solution.

* This is yet another solution for an existing problem with existing solutions.

* This doesn't appear to have any supporting security analysis.

* This is another protocol that abuses of HTTP by tunneling over it.

I also have a bunch of minor concerns and questions.

# Incomplete Solution

This is an incomplete solution, neglecting to address important and
difficult parts of the problem like key exchange.  If the working
group (or groups) intends to work on those more difficult problems, it
should do that and present a coherent solution.  I appreciate that big
problems are more tractable when broken down, but it's not clear how
this fits into a bigger picture.

The most mature seems to be the ACE profile in
draft-ietf-ace-oscore-profile-00, but the draft references two other
individual drafts as well.  Each presents a different interaction
model.  If the intent is to allow for many options, that makes
analysis harder.

# Security Analysis

I'm not going to go into the details of the various security claims or
mechanisms here, except to note that there is no reference to a
security analysis of this work, which makes me extremely nervous.
Even with the level of analysis that TLS 1.3 got, there were still a
few occasions when new tools or perspectives revealed new issues.  If
there is some analysis, citations are necessary.

If this depends on EDHOC or something else, then any analysis should
cover that as well or be very clear about stating assumptions.  Too
many times we've received an analysis that made assumptions that
didn't line up with the properties of the overall system, and that
leaves holes.

# High Level Concerns

This document continues the trend of building specialized solutions
for constrained endpoints rather than find ways to improve existing
solutions or provide generic capabilities.  This time, the problem is
end-to-end security.

This is a partial implementation of TLS - the record layer essentially
- with the hard parts deferred to another document and tight
integration with COAP.  Presumably that makes messages smaller, but
given the non-existent overlap between outer and inner messages, I
suspect that this isn't true.  DTLS has a 3+auth-tag octet overhead,
and the best examples here are less efficient than that.

The ATLAS proto-group is taking yet another approach.  Maybe we should
be having a discussion about XKCD 927 here (it would only be the
second in 24 hours for me).

One potential reason for a new design is the involvement of
intermediaries in the protocol and the need to route messages via
those intermediaries.  But this design actively works against any such
involvement.

# HTTP Use

This turns COAP from something that sort-of translates into HTTP to
something that abuses it by treating it as a simple tunnel.  I guess
that it turns COAP into something that abuses COAP as well if it comes
to that. I would encourage folks to read
http://httpwg.org/http-extensions/draft-ietf-httpbis-bcp56bis.html#getting-value-from-http
for context.  Why is a simpler substrate not possible?

The introductory parts of Section 10.2 are very hard to read.  For
instance, I can't parse this:

   All field semantics is given within the CoAP-Object-Security header field.

That applies to the bulk of the introductory material.  The actual
process is quite clear, thanks.

This is not true:

   Intermediaries are not allowed to insert, delete, or modify the
   field's value.  The header field is not preserved across redirects.

The point here is that the message that is sent is integrity
protected, so the intermediary can't modify the message without
detection.

What if the request is redirected by a server that doesn't understand OSCORE?

Requiring the use of the empty string as the value of an HTTP header
field is a good way to lose header fields.  Many intermediaries - and
stacks in general - silently discard such a header field.  If the
intent is to literally include two double quotes, say that very
clearly; the presentation makes it hard to know exactly what bits are
expected.  The examples don't help by adding " (empty string)", which
might be interpreted as being part of the value.

The new header field needs [A]BNF.

A new media type is defined, but I don't see any mention of a
codepoint for use with COAP and none of the examples show that media
type in use.

Is the expectation that a COAP-HTTP gateway understands the
significance of the new header field and insert the media type when
translating?  That seems like a stretch.

# Linking

Section 9 would benefit from an example.  Greatly.  It took me a while
to understand the intent of this mechanism.

RFC 8288 doesn't define a registry for target attributes.  That seems
like a major problem here if the intent is to avoid accidental
bustage.  "osc" is very low entropy and therefore prone to collisions,
and the net effect of making links unusable isn't an outcome that will
be expected.

If the user of a link is expected to acquire a security context from
somewhere without the link relation providing any help, I question the
value of this annotation.  If the intent is to mark resources
off-limits for clients that don't have keys, then that's one thing,
but the document doesn't establish what the expectations are regarding
OSCORE requirements on a resource.  Is it is supported *in addition
to* unprotected access or does "osc" mean that OSCORE is necessary for
accessing that resource.  The draft says the link "is to be accessed
using OSCORE", which hints that it is the latter, but it needs to be
very crisp.

I also don't see the path from here to using EDHOC/other for a
resource thus marked, if that is indeed an expected part of the bigger
picture.  I have questions of scope of applicability of EDHOC and the
ACE profile that would result from that sort of key agreement, but
that can wait.

# Examples

The examples in Section 6.3 are incomprehensible to me.  What is the
message you are sending?  Is it already protected?

Similarly, I can't see how you can fit the request you claim to be
making into the examples in Section 10.3.  You don't describe the AEAD
that is in use, or what keys.

The appendices are much better.

---

From: Göran Selander <[email-masked]>
Date: Fri, 30 Mar 2018 10:49:02 +0000

>Hi Martin,
>
>
>Thanks for good comments. Version -12 submitted. Replies inline labelled
>[GS].
>
>
>On 2018-03-08 03:14, "ietf on behalf of Martin Thomson"
><[email-masked] on behalf of [email-masked]> wrote:
>
>
>this fits into a bigger picture. The most mature seems to be the ACE
>profile in
>[GS] Pre-shared keys will be used in IoT deployments for performance
>reasons for time to come. We have included a recommendation for forward
>secrecy, but repeated key exchanges are not possible for all IoT
>scenarios. A key exchange protocol for OSCORE is a separate activity.
>Each option needs to show its feasibility to adequately address the use
>cases as well as its use with OSCORE.
>
>
>
>
># Security Analysis
>
>
>[GS] There is a new appendix D giving an overview of the security
>properties.
>This appendix is not addressing a future key exchange protocol but the use
>of COSE_Encrypt0 with an AEAD as specified in the draft.
>
>
>[GS] There is no dependency on EDHOC.
>
>
># High Level Concerns
>
>
>[GS] The new appendix D is hopefully doing a better job in explaining the
>end-to-end security setting and the assumed role of the intermediaries.
>
>
>
>
># HTTP Use
>
>
>to that. 
>[GS] OSCORE is using CoAP in two ways: the inner/end-to-end encrypted
>message which is using CoAP and essentially all its features and
>extensions, and the outer/transport message which is only using a limited
>set of the CoAP functionality but which complies with most of its
>features and extensions.
>
>
>The use of HTTP was introduced on request to address certain end-to-end
>REST settings e.g. HTTP client to CoAP server, where the HTTP client is
>assumed to know how to map a (CoAP-mappable) HTTP request into CoAP (RFC
>8075) as well as OSCORE. In this setting at the core of the inner message
>is a translated HTTP message. So, while not taking advantage of all HTTP
>features this construction is doing more than a simple tunnelling.
>
>
>
>
>   I would encourage folks to read
>   
>http://httpwg.org/http-extensions/draft-ietf-httpbis-bcp56bis.html#getting
>   -value-from-http for context. Why is a simpler substrate not possible?
>
>
>[GS] I don’t know what that simpler substrate would be given the use case
>above.
>
>
>
>
>The introductory parts of Section 10.2 are very hard to read.
>
>
>
>
>[GS] Admittedly, there were several details on HTTP missing and we are
>grateful
>for this review. The HTTP related sections are now restructured and
>more details are provided.
>
>
>
>
>For
>[GS] The introductory parts are rephrased.
>
>
>
>
>This is not true:
>
>
>[GS] This was not intended as a statement of integrity, but as a
>statement of what an intermediate is expected to do according to
>instructions about
>required documentation related to the new HTTP header field. We have
>tried to clarify that.
>
>
>
>
>[GS] Please see the updated description.
>
>
>[GS] Yes, thanks, this is changed to AA.
>
>
>
>
>[GS] Agreed, included.
>[GS] This has been discussed on the CORE WG mailing list and in the f2f
>meeting. We don’t have a show-stopping use case for this codepoint at the
>moment, but have anyway included it in -12 for potential future use cases.
>
>
>
>
>[GS] Since the CoAP-HTTP gateway must understand OSCORE to make the
>correct translation, it would know when to insert the media type. So,
>indeed, this is assumed.
>
>
>
>
># Linking
>
>
>[GS] A simple example is added.
>
>
>[GS] This is a copy of a corresponding text in RFC 7641. We think that
>this is not for OSCORE to solve. Please see:
> https://mailarchive.ietf.org/arch/msg/core/yLGC6quPw7SmOmmkjz3L1pIDNJ4
>
>
>
>
>[GS] Ok, thanks for the comment. We did try to improve the text so that,
>as you guessed, the mean is the latter. Now the text reads:
>The "osc" attribute is a hint indicating that the destination of that
>link is only accessible using OSCORE, and unprotected access to it is
>not supported.
>
>
>
>
>[GS] OK, let’s get back on that in the context of those protocols.
>
>
>
>
># Examples
>
>
>[GS] The examples are intended to how the COSE_Encrypt0 object is
>compressed and divided into OSCORE option and payload.
>In -11 some of the examples missed the "Before compression” part which is
>now included. Hope that makes more sense.
>
>
>
>
>[GS] This is now section 11.5 and 11.6. These are not test vectors, the
>examples are intended to illustrate the translation of message fields. We
>have tried to clarify that.
>
>

>
>
>Again, thanks for good comments!
>
>
>Göran
>