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

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

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

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/

----------------------------------------------------------------------
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.