Re: [core] 🔔 WGLC on draft-ietf-core-object-security

Hi Mališa,

Great to hear you are progressing with Wireshark for OSCORE!

Answers/comments inline:

From: Mališa Vučinić <malisa.vucinic@inria.fr<mailto:malisa.vucinic@inria.fr>>
Date: Thursday 14 December 2017 at 14:18
To: "core@ietf.org<mailto:core@ietf.org> WG (core@ietf.org<mailto:core@ietf.org>)" <core@ietf.org<mailto:core@ietf.org>>
Cc: "draft-ietf-core-object-security.authors@ietf.org<mailto:draft-ietf-core-object-security.authors@ietf.org>" <draft-ietf-core-object-security.authors@ietf.org<mailto:draft-ietf-core-object-security.authors@ietf.org>>
Subject: Re: [core] 🔔 WGLC on draft-ietf-core-object-security
Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>>
Resent-To: Göran Selander <goran.selander@ericsson.com<mailto:goran.selander@ericsson.com>>, John Mattsson <john.mattsson@ericsson.com<mailto:john.mattsson@ericsson.com>>, Francesca Palombini <francesca.palombini@ericsson.com<mailto:francesca.palombini@ericsson.com>>, <ludwig.seitz@ri.se<mailto:ludwig.seitz@ri.se>>
Resent-Date: Thursday 14 December 2017 at 14:18

Göran, all,

It was really a pleasure to witness how this spec advanced from draft-selander-ace-object-security-00 and evolved to its current form. Thank you for accommodating the requests coming from 6TiSCH and making this solution so efficient.

I am just starting to work on a Wireshark dissector and this made me go through the text on HTTP-to-CoAP and CoAP-to-HTTP proxying as one may have HTTP carrying OSCORE. I would like to understand better the added value of this part of the spec. Take as an example HTTP client generating request that is proxied/translated into a CoAP request. For the HTTP client to generate external_aad and ciphertext, it needs to implement portions of CoAP machinery. For example, to generate plaintext, the HTTP client needs to know in advance what CoAP Code will the proxied request have, how HTTP headers will translate to CoAP options and how to encode them in CoAP format. My question is whether it makes sense for an HTTP client to implement this, but not the rest of CoAP.

[GS] Carsten already commented about using HTTP for traversing firewalls. This thus enables end-to-end REST in practice, including deployments with mixed HTTP/CoAP legs. The feature was requested by e.g. OCF.

Second comment is related to normative language on error handling in -07. Background: Some error responses can be spoofed as they are not protected due to the lack of common keying material, so this opens up a DoS vector on the client. Current text in -07 states that the server MAY send this kind of response. Could you elaborate the reasoning behind this?

[GS] There was a request from one of the implementors to avoid unnecessary retransmissions and to be able to send info about what error it is. Typically error messages are protected, but if the error is related to OSCORE itself, e.g. that the server cannot find the security context, then the error message to the client cannot be protected. The DoS aspect related to a client receiving an unprotected error message depends on how the client acts on this message. The ability to send unprotected messages existed even without this.

What is the expected behavior of a client?

[GS] The application decides how to act. If an error message arrives, either the application specifies how to deal with it (e.g. based on the payload if any) or drops it without further processing.

Could you discuss somewhere security tradeoff being made when one opts for one approach or the other?

[GS] Yes, we should add a security consideration on this note.

Why do you not differentiate based on message type (NON/CON), as used in previous versions?

[GS] Because the error is sent independently of the underlying messaging layer, and there may not even be a messaging layer as in CoAP over TCP. The dependence on NON/CON was a mistake in the previous version that came up during the last interop, thanks to the implementers.

I hope this addresses your comments.

Göran

Mališa

On 20 Nov 2017, at 16:09, Jaime Jiménez <jaime.jimenez@ericsson.com<mailto:jaime.jimenez@ericsson.com>> wrote:

Dear CoRE WG,

As we discussed during this IETF, the OSCORE draft is in good shape for WGLC.
The authors have submitted a reviewed version dealing with the minor comments from IEF100.

https://tools.ietf.org/html/draft-ietf-core-object-security-07

The WGLC will end by 11th of December.

Best Regards,
- - Jaime Jiménez

_______________________________________________
core mailing list
core@ietf.org<mailto:core@ietf.org>
https://www.ietf.org/mailman/listinfo/core