Eric Rescorla
2017-05-06 22:59:17 UTC
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.
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.