[core] Update on coap-tcp-tls

[Brian Raymor]

Most (21) of the WGLC issues have been addressed in the editor's draft and closed:
https://github.com/core-wg/coap-tcp-tls/milestone/4?closed=1

7 open issues remain - https://github.com/core-wg/coap-tcp-tls/issues:

Signaling (5)

Could the authors/contributors (Carsten, Hannes, Klaus) of draft-bormann-core-coap-sig-02 help clarify this set of issues - https://github.com/core-wg/coap-tcp-tls/labels/request-clarification - Let me know if you'd prefer a conference call to address.

The remaining Signaling issue explores whether there are new requirements when responding to a Ping - https://github.com/core-wg/coap-tcp-tls/issues/69. Please review the issue for background and potential solutions. I'd welcome your thoughts.

Securing CoAP issues (2)

The Securing CoAP proposal was reviewed by Göran and Hannes and "baked" on the list. It's ready to be closed:
https://github.com/core-wg/coap-tcp-tls/issues/11

Bill has proposed an amendment for Securing WebSockets. Any WG comments?
https://github.com/core-wg/coap-tcp-tls/issues/102

Thanks,
...Brian

[Brian Raymor]

Jaime and I had a conference call with the draft-bormann-core-coap-sig-02 authors (Carsten, Hannes, Klaus) to review https://github.com/core-wg/coap-tcp-tls/issues and a related pull request - https://github.com/core-wg/coap-tcp-tls/pull/103 - related to Signaling.

There were some design proposals from the meeting that I would like to share for WG comment:

https://github.com/core-wg/coap-tcp-tls/issues/82


There was consensus to remove the Server-Name Option in the upcoming coap-tcp-tls-06. This feature has not been implemented.
It provided minimal value at the cost of additional security considerations.

It did offer a mechanism to set the default value for the URI-Host option:

For TLS, the base value for the Server-Name Option is given by the SNI value.
For Websockets, the base value for the Server-Name Option is given by the HTTP Host header field.

Similar text will need to be added to -06 per - https://github.com/core-wg/coap-tcp-tls/issues/108

https://github.com/core-wg/coap-tcp-tls/issues/69

Changing:

Upon receipt of a Ping message, a single Pong message is returned with the identical token.

To [big breath]:

Upon receipt of a Ping message, the receiver SHOULD return a single Pong message with the identical token as soon as practical, unless
there is an option with delaying semantics, such as the Custody Option.


...Brian

From: core [mailto:core-***@ietf.org] On Behalf Of Brian Raymor
Sent: Tuesday, January 17, 2017 9:21 PM
To: ***@ietf.org WG <***@ietf.org>
Subject: [core] Update on coap-tcp-tls


Most (21) of the WGLC issues have been addressed in the editor's draft and closed:
https://github.com/core-wg/coap-tcp-tls/milestone/4?closed=1

7 open issues remain - https://github.com/core-wg/coap-tcp-tls/issues:

Signaling (5)

Could the authors/contributors (Carsten, Hannes, Klaus) of draft-bormann-core-coap-sig-02 help clarify this set of issues - https://github.com/core-wg/coap-tcp-tls/labels/request-clarification - Let me know if you'd prefer a conference call to address.

The remaining Signaling issue explores whether there are new requirements when responding to a Ping - https://github.com/core-wg/coap-tcp-tls/issues/69. Please review the issue for background and potential solutions. I'd welcome your thoughts.

Securing CoAP issues (2)

The Securing CoAP proposal was reviewed by Göran and Hannes and "baked" on the list. It's ready to be closed:
https://github.com/core-wg/coap-tcp-tls/issues/11

Bill has proposed an amendment for Securing WebSockets. Any WG comments?
https://github.com/core-wg/coap-tcp-tls/issues/102

Thanks,
...Brian

[Carsten Bormann]

Post by Brian Raymor
Upon receipt of a Ping message, the receiver SHOULD return a single Pong message with the identical token as soon as practical, unless
there is an option with delaying semantics, such as the Custody Option.

Maybe separate the two levels of requirement here:

— return single Pong message with the identical token (MUST)
— as soon as practical, unless option in Ping with delaying semantics (SHOULD)

Grüße, Carsten

[Brian Raymor]

Good point.

Upon receipt of a Ping message, the receiver MUST return a Pong message with an identical token in response.
Unless there is an option with delaying semantics such as the Custody Option, it SHOULD respond as soon as practical.

Thanks,
...Brian

-----Original Message-----
From: Carsten Bormann [mailto:***@tzi.org]
Sent: Thursday, February 2, 2017 1:57 PM
To: Brian Raymor <***@microsoft.com>
Cc: ***@ietf.org WG <***@ietf.org>
Subject: Re: [core] Update on coap-tcp-tls

Post by Brian Raymor
Upon receipt of a Ping message, the receiver SHOULD return a single Pong message with the identical token as soon as practical, unless
there is an option with delaying semantics, such as the Custody Option.

Maybe separate the two levels of requirement here:

— return single Pong message with the identical token (MUST) — as soon as practical, unless option in Ping with delaying semantics (SHOULD)

Grüße, Carsten