Subject: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)

From: Eric Rescorla <[email-masked]>
Date: Sat, 06 May 2017 15:59:17 -0700

Eric Rescorla has entered the following ballot position for
draft-ietf-core-coap-tcp-tls-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-coap-tcp-tls/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

After reading Mark Nottingham's review, I'm persuaded we should at least
discuss the relationship of this work to the parallel work in HTTP.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Document: draft-ietf-core-coap-tcp-tls-08.txt

TECHNICAL
You need to specify MTI cipher suites. I don't think that the
ones you specified in 7925 are very useful for TLS. Is this really
really what you want?

S 3.2.
Having the lengths offset by 13 bytes is, IMO, pretty silly.  I
realize it avoids duplication, but it also makes the packets hard to
read for not much value. As a practical matter, it expands the
1-byte length for the range 256-268, for a savings of less than
.5% even on those packets and on average far less.

S 4.1.
   The WebSocket client MUST include the subprotocol name "coap" in the
   list of protocols, which indicates support for the protocol defined
   in this document.  Any later, incompatible versions of CoAP or CoAP
   over WebSockets will use a different subprotocol name.

This doesn't make much sense, because you are willing to have
incompatible
protocols for TCP, where you use CSM to distinguish them, and you do
the same thing with ALPN.

S 5.5.
These release semantics seem quite problematic. In particular, when
people want an orderly close, they typically want the other side
to process all the outstanding requests and then return them, but
this doesn't seem to do that (note that just because the responses
need to be *delivered* in order doesn't mean they need to be generated
in order). So, for instance, say I have the following sequence of
events:

C                 S           DB
GET /a ->   
                  Request A ->      
Release ->
                  FIN
                  <- Response A

It seems like the only difference between Abort and Release is that
the sender is saying "don't expect that I processed any of your
messages", but in at least a lot of scenarios (e.g., where the
initiator is basically just a client), this doesn't actually tell
the server much about sequence because the responses aren't ordered
wrt Release AFAICT.

   Release message by closing the TCP/TLS connection.  Messages may be
   in flight when the sender decides to send a Release message.  The
   general expectation is that these will still be processed.

This is not really useful language.

   For CoAP over reliable transports, the recipient rejects such
   messages by sending an Abort message and otherwise ignoring the
   message.  No specific option has been defined for the Abort message
   in this case, as the details are best left to a diagnostic payload.

I don't understand this text. Abort seems to mean "I'm done", but then
how am I ignoring the message.

S 6.
I found this section pretty confusing. In 7959, when M=0 you need
to stay *under* the block boundary but here you say:

   In descriptive usage, a BERT Option is interpreted in the same way
as
   the equivalent Option with SZX == 6, except that the payload is also
   allowed to contain a multiple of 1024 bytes (non-final BERT block)
or
   more than 1024 bytes (final BERT block).

And your examples pretty clearly show it being >> 1024. What's the
reasoning here

   In control usage, a BERT option is interpreted in the same way as
the
   equivalent Option with SZX == 6, except that it also indicates the
   capability to process BERT blocks.

But:

   Block-wise Transfer Option.  If a Max-Message-Size Option is
   indicated with a value that is greater than 1152 (in the same or a
   different CSM message), the Block-wise Transfer Option also
indicates
   support for BERT (see Section 6).  Subsequently, if the Max-Message-

Is this an instruction to set the BTO to be 7? Or redundancy?

EDITORIAL
S 3.2.
      Length (Len):  4-bit unsigned integer.  A value between 0 and 12
      directly indicates the length of the message in bytes starting

I think you want to say "0 and 12 inclusive"

S 5.3.1.
   These are not default values for the option, as defined in
   Section 5.4.4 in [RFC7252].  A default value would mean that an
empty
   Capabilities and Settings message would result in the option being
   set to its default value.

This is pretty confusing text. I take it that it means that if
the base values of both A and B are 0, then:

   Start    // A=0, B=0
   CSM[A=1] // A=1, B=0
   CSM[B=2] // A=1, B=2

Whereas if these were default values, then this would be:

   Start    // A=0, B=0
   CSM[A=1] // A=1, B=0
   CSM[B=2] // A=0, B=2  <- A resets to default

If that's so, perhaps you could say:

   These are not default values for the option, as defined in
   Section 5.4.4 in [RFC7252], because default values apply
   on a per-message basis and thus reset when the value is
   not present in a given CSM.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 May 2017 08:12:58 +0200

> Hi Eric,

thank you for this detailed review.

> DISCUSS:

I don’t think the work on HTTP/2 is in any way parallel to the work of bringing CoAP to work on TCP/TLS.

There are some elements of Mark’s review that leave me speechless (“reinventing framing”?  Any TCP-based protocol needs to reinvent framing, and it’s not like the HTTPs have found the definitive answer this perennial issue yet.). I generally think the competition that is hinted at here is constructed; in reality it does not exist.

I do believe that a discussion about the relationship of the three REST transfer protocols, CoAP and the two HTTPs, is useful, if well-prepared.

But let me dive in to some specifics below.

Indeed, you are uncovering an issue here:

The recommendations in the document (in 7925 Section 4.2, 4.3) are good for CoAP over TCP/TLS in the constrained-to-cloud use case.
For backend interfacing, and in particular for the WebSockets case, one would use what one has in those environments.

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

Generally speaking, it is not so clear that MTI cipher suites are as useful in this document as they are in the base CoAP spec, as this document describes a set of optional transport bindings that is needed in a number of quite different specific use cases, each of which come with their own specific environments.

> .5% even on those packets and on average far less.

This just mirrors the way CoAP is encoding lengths (and other values) in other places.

The 0.5 % savings is nice to have (but would indeed be a silly motivation on its own).
The motivation for the length encoding used in CoAP (which we iterated on quite a bit between 2012 and 2013) ultimately was to get deterministic coding: For each length, there is exactly one way to encode it, so it is harder to trip up implementations by (accidentally or deliberately) using an alternate encoding.

(The WG originally had decided to use a simpler fixed-length length for TCP, called L1.  Unfortunately, implementations at this point already had charged ahead and used the CoAP-style length encoding, called L3.  So the WG grudgingly switched to L3.)

> the same thing with ALPN.

The sentence was about “incompatible” in the sense that you wouldn’t even understand the CSM.
No idea why we would make changes like that, but unexpected protocol evolution does happen, and it is good that ALPN has us covered here.

> This is not really useful language.

I see what you mean.  The intention is that a Release actually does allow the other side to process outstanding requests, so in the above example the server would actually send “Response A” before closing.

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

> how am I ignoring the message.

Ignoring as in “not processing”.

(This is echoing the equivalent text from RFC 7252, do we need to use different wording?)

>   capability to process BERT blocks.

Right, this is from the time we didn’t have the CSM mechanism yet.

> Is this an instruction to set the BTO to be 7? Or redundancy?

Max-Message-Size is not redundant, as it gives you the actual message size the peer can process.
But the above language about indicating BERT capability in an SZX is redundant now.

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

> I think you want to say "0 and 12 inclusive”

Yes.

Now in https://github.com/core-wg/coap-tcp-tls/issues/148

>   not present in a given CSM.

“Reset when not present” would be confusing for my brain.

But yes, this has already confused other people, and we need to improve it.

Now in https://github.com/core-wg/coap-tcp-tls/issues/148

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 10 May 2017 12:23:29 +0200

Adding my remarks here as well.

> I do believe that a discussion about the relationship of the three REST transfer protocols, CoAP and the two HTTPs, is useful, if well-prepared.

I also do not see a competition between CoAP and HTTP/2. What this
initially tried to do is to describe how some companies (ARM, Microsoft,
Zebra) have been deploying CoAP in enterprise networks that block UDP
traffic.

Why it takes 2 years to standardize such basic features is a mystery to me.

In the long run, the story for IoT devices may be QUIC & HTTP/2 but
today HTTP/2 on IoT devices is essentially non-existent.

> Generally speaking, it is not so clear that MTI cipher suites are as useful in this document as they are in the base CoAP spec, as this document describes a set of optional transport bindings that…

From what I have seen in the IoT space is that there have been different
credentials being used. As such, there is no single ciphersuite that
matches the deployments. Mandating a single ciphersuite for use with
CoAP over TLS for a PSK-ciphersuite and another one for a
certificate/raw public key ciphersuite is fine. This is essentially what
RFC 7925 does.

I have been arguing that the specification should only support CoAP over
TLS but I was battled down.

Ciao
Hannes

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 May 2017 08:55:24 -0700

On Tue, May 9, 2017 at 11:12 PM, Carsten Bormann <[email-masked]> wrote:

> There are some elements of Mark’s review that leave me speechless
> (“reinventing framing”?  Any TCP-based protocol needs to reinvent framing,
> and it’s not like the HTTPs have found the definitive answer this perennial
> issue yet.). I generally think the competition that is hinted at here is
> constructed; in reality it does not exist.
>
> I do believe that a discussion about the relationship of the three REST
> transfer protocols, CoAP and the two HTTPs, is useful, if well-prepared.

I don't think this is a question of competition so much as whether it is
sensible to be developing very parallel technologies in different WGs, and
whether the settings in which those technologies will be deployed are
sufficiently different to justify that. That's always a question we should
be asking when we look at work.

> The recommendations in the document (in 7925 Section 4.2, 4.3) are good
> for CoAP over TCP/TLS in the constrained-to-cloud use case.
> For backend interfacing, and in particular for the WebSockets case, one
> would use what one has in those environments.
>
> Generally speaking, it is not so clear that MTI cipher suites are as
> useful in this document as they are in the base CoAP spec, as this document
> describes a set of optional transport bindings that is needed in a number
> of quite different specific use cases, each of which come with their own
> specific environments.

Fair enough. I think the key thing is that it be clear. within that, you
have several options:

- Inherit the 7295 MTIs
- Inherit the TLS MTIs
- Define your own MTIs.

I tend to think that the first is kind of unwise in this setting, but
ultimately it's a WG decision. It does, however, need to be clear.

> The motivation for the length encoding used in CoAP (which we iterated on
> quite a bit between 2012 and 2013) ultimately was to get deterministic
> coding: For each length, there is exactly one way to encode it, so it is
> harder to trip up implementations by (accidentally or deliberately) using
> an alternate encoding.
>

Being nitpicky: the property you are describing here is not deterministic
coding but rather
is something stricter (bijective, I guess). You could get deterministic
simply by requiring
people to pick the minimal encoding.

I'm not sure I am persuaded that this is actually less likely to trip
people up, given that
it requires integer addition that overflows the minimal size of the integer
you read into.
Again, this is a WG decision (hence this being a comment), but I'm not
persuaded that
this is the right answer.

> No idea why we would make changes like that, but unexpected protocol
> evolution does happen, and it is good that ALPN has us covered here.
>

Right, but my point is that this creates an inconsistency with the other
operating modes that don't include ALPN, so I don't see how you're
going to deploy it.

> I see what you mean.  The intention is that a Release actually does allow
> the other side to process outstanding requests, so in the above example the
> server would actually send “Response A” before closing.
>

I think it might help....

-Ekr

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 10 May 2017 18:25:28 +0200

> I don't think this is a question of competition so much as whether it is sensible to be developing very parallel technologies in different WGs, and whether the settings in which those technologies will be deployed are sufficiently different to justify that. That's always a question we should be asking when we look at work.

True.  We used to have a pretty good IESG consensus that it is worth to have an IETF stack for constrained devices.
The pretty good pickup of that stack by other SDOs seems to corroborate this.
In fact, the present document is on the table because both OCF and OMA saw a need for it.

Of course, there will always be people who say that Moore’s law will get rid of constrained environments.
There also always will be people to say that IP is too heavyweight in the first place for these.
Since chartering 6LoWPAN in 2005, we have spent a lot of time proving them wrong, and those SDOs would not understand why we stop doing that (and I wouldn’t either).

> Fair enough. I think the key thing is that it be clear. within that, you have several options:
> 
> - Inherit the 7295 MTIs
> - Inherit the TLS MTIs
> - Define your own MTIs.
> 
> I tend to think that the first is kind of unwise in this setting, but ultimately it's a WG decision. It does, however, need to be clear.

Again, this presumes MTIs are desirable (or even possible!), but we definitely can give better guidance.
Added this list to https://github.com/core-wg/coap-tcp-tls/issues/145

> Being nitpicky: the property you are describing here is not deterministic coding but rather
> is something stricter (bijective, I guess). You could get deterministic simply by requiring

Well, if we could rely on peers always implementing the MUSTs…

> I'm not sure I am persuaded that this is actually less likely to trip people up, given that
> it requires integer addition that overflows the minimal size of the integer you read into.
> Again, this is a WG decision (hence this being a comment), but I'm not persuaded that

CoAP implementers already have coded this once (they might even re-use that code).

> operating modes that don't include ALPN, so I don't see how you're

Yes.  I think that sentence is making a gratuitous speculation about an unknown unknown, and we should get rid of it.

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

> I think it might help….

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

Grüße, Carsten

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 10 May 2017 09:34:40 -0700

On Wed, May 10, 2017 at 9:25 AM, Carsten Bormann <[email-masked]> wrote:
> Since chartering 6LoWPAN in 2005, we have spent a lot of time proving them
> wrong, and those SDOs would not understand why we stop doing that (and I
> wouldn’t either).
>

The issue at hand is not whether Moore's law will get rid of constrained
environments but
rather whether having a completely parallel stack is the right way to
accommodate such
environments.

> Again, this presumes MTIs are desirable (or even possible!),

You are of course free to disagree, but this is not an open question in
this case.
TLS 1.2 explicitly specifies an MTI cipher suite, and so if you do nothing
you
inherit it. (https://tools.ietf.org/rfcmarkup?doc=5246#section-9). I suppose
that you could explicitly disclaim an MTI here, but then I think you would
have some trouble :)

> but we definitely can give better guidance.

Yes.

> CoAP implementers already have coded this once (they might even re-use

This is not really a technical argument about the merits of this design
choice.

As I said, this is a COMMENT, so you're free to simply ignore me, but if
your
objective is to persuade me, you have not yet done so.

-Ekr

---

From: Brian Raymor <[email-masked]>
Date: Wed, 24 May 2017 01:11:43 +0000

On 05/10/2017 03:24 AM, Hannes Tschofenig wrote:
[original response @ https://www.ietf.org/mail-archive/web/core/current/msg08739.html]

>> After reading Mark Nottingham's review, I'm persuaded we should at 
>> least discuss the relationship of this work to the parallel work in HTTP.
>> 
<snip>

> I also do not see a competition between CoAP and HTTP/2. What this initially tried to do is to describe how some
> companies (ARM, Microsoft, Zebra) have been deploying CoAP in enterprise networks that block UDP traffic.

Samsung too. And perhaps one of our OCF+IETF participants could speak to the current OCF and/or IoTivity status. See also this presentation - https://www.ietf.org/proceedings/interim-2016-t2trg-03/slides/slides-interim-2016-t2trg-03-sessa-iotivity-status-and-future-direction-00.pdf

> In the long run, the story for IoT devices may be QUIC & HTTP/2 but today HTTP/2 on IoT devices is essentially non-existent.

Encouraged by Dave Thaler, there was a candid discussion of rationale in https://github.com/core-wg/coap-tcp-tls/issues/50. As Hannes wrote in the issue:

    I can give you the motivation why we are interested in CoAP over TLS /TCP. We have an existing implementation of LWM2M,
    which uses CoAP. We spent a lot of time getting that implementation rock-solid. Some enterprise deployments, which happen
    to have interesting firewall policies, do not allow us to use UDP. Hence, we were interested to add a TCP-based transport to CoAP.     
    Making this enhancement turns out to be reasonably simple.

    As Carsten explained, CoAP has found its way into various SDOs and that's what people now implement. CoAP is sort-of understood
    and there are lots of implementations available. Switching to something else takes time and resources. There are also much fewer 
    implementations of HTTP/2 for embedded devices available.  Maybe in a few years we will be using HTTP/2 instead of CoAP over 
    TCP/TLS but today we just want to get our existing deployments document and standardized. I am sure that people will take a closer look 
    at the different options in more detail in the future.

While the DISCUSS is perfectly reasonable (I raised similar questions about IETF guidance in the github issue above), it feels inopportune that this specific concern is being expressed so late in the process rather than during proposed adoption of the working draft especially since both WGs are in the same Area. 

Dave Thaler's issue was prompted by Gabriel Montenegro's HTTPbis presentation at IETF 96 which explored protocol reuse / HTTP/2 availability - https://www.ietf.org/proceedings/96/slides/slides-96-httpbis-3.pdf.  This was a second natural opportunity for early questions to be raised between the HTTPbis and CoRE chairs?

...Brian

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 May 2017 20:22:28 -0500

>      Making this enhancement turns out to be reasonably simple.

I'll note that the rationale for using WebSockets for this purpose 
appears to be significantly less clear, and the combination of TCP and 
WebSockets into a single document even more so.

/a

---

From: Brian Raymor <[email-masked]>
Date: Wed, 24 May 2017 02:56:14 +0000

> I'll note that the rationale for using WebSockets for this purpose appears to be significantly less clear, and the combination of TCP and 

I agree with what Hannes wrote in his earlier response to you - https://www.ietf.org/mail-archive/web/core/current/msg08729.html - 

    The authors of the document have different views about the inclusion of the support of WebSockets in the document.
    I leave it to the responsible AD to decide what the best document structure is and what is indeed covered as part of the
    CORE working group charter.

I would encourage the authors of draft-savolainen-core-coap-websockets (based on their specific domain expertise) to weigh in on some of the WebSockets questions/concerns raised arising during these reviews. 

...Brian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 May 2017 06:37:30 +0300

Websockets is in the same document beause it is 95 % the same problem.  Of course, we could split off the 5 % into a separate document as a delta from TCP. I fail to see why (except maybe as a ploy to get more of the original authors accommodated).

Sent from mobile

> On 24. May 2017, at 05:56, Brian Raymor <[email-masked]> wrote:
> 
>

---

From: Dave Thaler <[email-masked]>
Date: Fri, 26 May 2017 17:26:55 +0000

Brian Raymor wrote:
> Samsung too. And perhaps one of our OCF+IETF participants could speak to the current OCF
> and/or IoTivity status.

I believe OCF just sent a liaison statement on this topic, based on OCF consensus at a meeting earlier this week, which should answer that question (in short: it's implemented in iotivity, normatively referenced in OCF specs that are in the process of being published... sort of like sitting in the RFC editors queue, and expected to be in lots of products shipping "soon").

My understanding (it was before my time) is that the choice of using COAP (over UDP) was made long before HTTP/2 was a thing and so using COAP over other underlying layers was a natural extension.   Older OIC specs did have a partial specification of OCF over HTTP(S), but as it was never fully fleshed out it was removed from later specs and current Iotivity code implementing OCF protocols just uses coap.

> Encouraged by Dave Thaler, there was a candid discussion of rationale in
> https://github.com/core-wg/coap-tcp-tls/issues/50. As Hannes wrote in the issue:
[...]

Right, I didn't raise an objection (because of the reality cited by Hannes and OCF),
I just suggested an applicability paragraph explaining the relationship and tradeoffs.

Dave

---

From: Brian Raymor <[email-masked]>
Date: Wed, 31 May 2017 23:33:05 +0000

Ekr,

With regard to the original DISCUSS - "After reading Mark Nottingham's review, I'm persuaded we should at least discuss the relationship of this work to the parallel work in HTTP" - are there further questions that need to be addressed on this thread?  

Thanks,
...Brian

-----Original Message-----
From: Dave Thaler 
Sent: Friday, May 26, 2017 10:27 AM
To: Brian Raymor <[email-masked]>; Hannes Tschofenig <[email-masked]>; Carsten Bormann <[email-masked]>; Eric Rescorla <[email-masked]>
Cc: [email-masked]; The IESG <[email-masked]>; [email-masked]; [email-masked]
Subject: RE: [core] Eric Rescorla's Discuss on draft-ietf-core-coap-tcp-tls-08: (with DISCUSS and COMMENT)

Brian Raymor wrote:
> Samsung too. And perhaps one of our OCF+IETF participants could speak 
> to the current OCF and/or IoTivity status.

> Encouraged by Dave Thaler, there was a candid discussion of rationale 
> in https://github.com/core-wg/coap-tcp-tls/issues/50. As Hannes wrote in the issue:
[...]

Right, I didn't raise an objection (because of the reality cited by Hannes and OCF), I just suggested an applicability paragraph explaining the relationship and tradeoffs.

Dave