Subject: Re: [core] 🔔 WGLC on draft-ietf-core-coap-tcp-tls

From: Brian Raymor <[email-masked]>
Date: Wed, 2 Nov 2016 00:16:05 +0000

I re-opened - https://github.com/core-wg/coap-tcp-tls/issues/11 - for tracking during WGLC and reviewed the audio for the discussion at IETF 96 - https://www.ietf.org/audio/ietf96/ietf96-charlottenburgii-iii-20160719-1359_50.mp3 - starting around 43:35.

There was strong consensus for Zach Shelby’s proposal – TLS [+ RFC7925] is mandatory-to-implement and on by default - as the minimal guidance for transport security which is compatible with the mandatory-to-implement language for DTLS in RFC7252. Both TCP and TLS are allowed.

…Brian

From: Göran Selander [mailto:[email-masked]]
Sent: Tuesday, October 25, 2016 1:00 AM
To: [email-masked] WG <[email-masked]>
Cc: Klaus Hartke <[email-masked]>; [email-masked]; Hannes Tschofenig <[email-masked]>; Jaime Jiménez <[email-masked]>
Subject: 🔔 WGLC on draft-ietf-core-coap-tcp-tls

Dear all,

I'd like to revisit the discussion on the status of TLS in CoAP over TCP implementations.

In the security considerations section

https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-04#section-7

it is stated:

"TLS version 1.2 or higher is mandatory-to-implement and MUST be enabled by default."

I thought one conclusion from Berlin was that we should align with RFC7252, which allows UDP or DTLS.

Considering that CoAP over TCP may be protected on other layers than transport layer, e.g. on application layer using OSCOAP — why is it necessary to mandate the implementation

of TLS?

In some use cases communication security may be required at multiple layers. But in other cases where TLS is not adequate/necessary as a second protocol and considering a constrained device may not be able to support multiple security protocol implementations, it doesn't make sense to always require TLS code.

I propose the quoted sentence is replaced with a statement saying something like for CoAP over TCP it is mandatory-to-implement a security protocol, and that security must be enabled by default. Recommended protocols can be provided, and mandatory-to-implement ciphersuites for a given protocol, like for DTLS in RFC7252. But it should not be restricted to TLS.

Regards,

Göran

From: core <[email-masked]<mailto:[email-masked]>> on behalf of Jaime Jiménez <[email-masked]<mailto:[email-masked]>>
Date: Tuesday 18 October 2016 at 11:22
To: "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>
Cc: Klaus Hartke <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Subject: [core] 🔔 WGLC on draft-ietf-core-coap-tcp-tls

Dear CoRE WG,

The core-coap-tcp-tls draft has gotten to a state that the authors feel is in good shape for WGLC.
We would like to ask the group to start checking this last version and the issues on the Github repository.

https://tools.ietf.org/html/draft-ietf-core-coap-tcp-tls-05

There is at the moment one open issue left in the tracker ( https://github.com/core-wg/coap-tcp-tls/issues/31  ) which is mostly editorial. The issues raised during last IETF - about Observe over reliable transports -  have been closed and new text has been added to the appendix: https://github.com/core-wg/coap-tcp-tls/issues/5

Best Regards,
- - Jaime Jiménez

---

From: Göran Selander <[email-masked]>
Date: Fri, 4 Nov 2016 08:17:06 +0000

Hi Brian,

I may be wrong, but as I read RFC7252, it specifies the binding to DTLS, and, given that binding, what is mandatory to implement (NoSec and RPK with a certain ciphersuite). 

The analogy would be that this draft specifies the binding to TLS and what is mandatory to implement with this binding. 

I believe we all agree that security must be mandatory to implement, and on by default. But since there is now more than one candidate security protocol for CoAP over TCP (and for CoAP over UDP) it doesn't make sense for constrained devices to mandate the implementation of one specific protocol. 

Note that OSCOAP was not adopted at the time when the discussion on TLS was held. Hence the case with more than one candidate security protocol with TCP was only theoretical, maybe not even understood, and IMHO not sufficiently considered in that discussion. 

Göran

> On 2 nov. 2016, at 01:16, Brian Raymor <[email-masked]> wrote:
> 
> From: core <[email-masked]> on behalf of Jaime Jiménez <[email-masked]>
> To: "[email-masked] WG" <[email-masked]>
> Cc: Klaus Hartke <[email-masked]>, "[email-masked]" <[email-masked]>, Hannes Tschofenig <[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 04 Nov 2016 09:25:17 +0100

Göran Selander <[email-masked]> writes:

> I believe we all agree that security must be mandatory to implement,

Yes.

> and on by default.

I don't know what that means.

Security is a process.  If people aren't doing the process, then
"switching on security" in a protocol implementation isn't giving you any.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 4 Nov 2016 09:27:14 +0100

I think in this context it would be better to replace 'security' with
'TLS'.

It makes sense to mandate implementing TLS and to use it per default.

Ciao
Hannes

On 11/04/2016 09:25 AM, Carsten Bormann wrote:
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Göran Selander <[email-masked]>
Date: Fri, 4 Nov 2016 09:54:28 +0000

> On 4 nov. 2016, at 09:25, Carsten Bormann <[email-masked]> wrote:
> 

My understanding is "must be used unless there is a good reason not to". But to make that decision of course requires the right processes in place. 

Göran

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 04 Nov 2016 10:59:09 +0100

> It makes sense to mandate implementing TLS and to use it per default.

That doesn't answer my question.  What does "use TLS" mean?

On a desktop or server, it means securely running processes like
regularly updating root cert lists and hundreds of megabytes of CRLs;
keeping accurate time in all situations; ...

What are the equivalent processes for "use TLS" on a constrained device?
Is there enough commonality here that a "by default" process can be defined?

I do not believe this question should be answered in the CoAP-over-TLS
draft; security processes for IoT are a subject of active research, not
something where we have enough solid knowledge for an MTI.

Obviously, we can leave the wishful statement "on by default" in; we are
in RFC 6919 land then unless this is read as a general statement of
direction as opposed to something specific that can be implemented
interoperably.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 4 Nov 2016 11:39:01 +0100

Hi Carsten,

of course, there is more needed to build a complete product. CoAP alone
will most likely not get you anywhere.

TLS assumes certain things to be present (and so does CoAP and other
protocols).

TLS requires the client to have a ciphersuite configured (which requires
certain credentials for the client). This does not necessarily require
you to replicate what is needed for a web browser since those are
implement the WebPKI model.

The information in RFC 7925 should be enough to pick the right
configuration.

I guess you are saying that CoAP itself is a building block and the way
how IoT is used today it does not really make any sense to talk about
randomly plugging things together.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 04 Nov 2016 12:41:58 +0100

> randomly plugging things together.

Indeed, and that means to me that "on by default", which would mean some
such random plugging, is not we what can seriously recommend.

Grüße, Carsten

---

From: Brian Raymor <[email-masked]>
Date: Fri, 4 Nov 2016 15:43:30 +0000

Hi Göran,

Regarding - “Hence the case with more than one candidate security protocol with TCP was only theoretical, maybe not even understood, and IMHO not sufficiently considered in that discussion.”

I recommend that you review the audio from IETF 96. Object security as an alternative was raised and discussed at the meeting.

Thanks,
…Brian

From: Göran Selander [mailto:[email-masked]]
Sent: Friday, November 4, 2016 1:17 AM
To: Brian Raymor <[email-masked]>
Cc: [email-masked] WG <[email-masked]>; Klaus Hartke <[email-masked]>; [email-masked]; Hannes Tschofenig <[email-masked]>; Jaime Jiménez <[email-masked]>
Subject: Re: 🔔 WGLC on draft-ietf-core-coap-tcp-tls

Hi Brian,

Göran

On 2 nov. 2016, at 01:16, Brian Raymor <[email-masked]<mailto:[email-masked]>> wrote:
I re-opened - https://github.com/core-wg/coap-tcp-tls/issues/11 - for tracking during WGLC and reviewed the audio for the discussion at IETF 96 - https://www.ietf.org/audio/ietf96/ietf96-charlottenburgii-iii-20160719-1359_50.mp3 - starting around 43:35.

…Brian

From: Göran Selander [mailto:[email-masked]]
Sent: Tuesday, October 25, 2016 1:00 AM
To: [email-masked]<mailto:[email-masked]> WG <[email-masked]<mailto:[email-masked]>>
Cc: Klaus Hartke <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Jaime Jiménez <[email-masked]<mailto:[email-masked]>>
Subject: 🔔 WGLC on draft-ietf-core-coap-tcp-tls

Dear all,

it is stated:

of TLS?

Regards,

Göran

Dear CoRE WG,

Best Regards,
- - Jaime Jiménez

---

From: Göran Selander <[email-masked]>
Date: Fri, 4 Nov 2016 16:34:00 +0000

Hi Brian,

> On 4 nov. 2016, at 16:43, Brian Raymor <[email-masked]> wrote:
> 
> Hi Göran,
>  

I already did, and, yes, it was raised and discussed, but without going into names you can also hear that some voices argue that TLS should be mandatory because security should be. So even if applicaton layer security was mentioned I don't think that alternative was well understood (or considered) by all that expressed their opinion. 

Göran

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 04 Nov 2016 18:54:20 +0100

Göran Selander <[email-masked]> writes:

> I already did, and, yes, it was raised and discussed, but without
> going into names you can also hear that some voices argue that TLS
> should be mandatory because security should be. So even if applicaton
> layer security was mentioned I don't think that
> alternative was well understood (or considered) by all that expressed their opinion.

I think the place where the discussion went beyond this was where people
opined that you want to stack TLS on top of Object Security so you can
privacy-protect (on the current proxy-to-proxy-hop) the secured objects
that you are lugging around.

To me, this sounds like a reasonable thing to do in some applications,
but it is not nearly as much of a requirement than having security in
the first place.

Grüße, Carsten