-----Original Message-----
From: Benjamin Kaduk <[email protected]>
Sent: Thursday, December 19, 2019 4:47 PM
To: Alexey Melnikov <[email protected]>
Cc: The IESG <[email protected]>; [email protected];
[email protected]; [email protected]; [email protected]
Subject: Re: Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with
DISCUSS and COMMENT)
On Wed, Dec 18, 2019 at 05:27:06AM -0800, Alexey Melnikov via Datatracker
wrote:
> Alexey Melnikov has entered the following ballot position for
> draft-ietf-ace-coap-est-17: 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-ace-coap-est/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> Thank you for this well written document. I have a couple of small
> DISCUSS points and a few minor comments/questions that I would like to
discuss.
>
> DISCUSS:
>
> 5.4. Message Bindings
>
> o The CoAP Options used are Uri-Host, Uri-Path, Uri-Port, Content-
> Format, Block1, Block2, and Accept. These CoAP Options are used
> to communicate the HTTP fields specified in the EST REST messages.
> The Uri-host and Uri-Port Options can be omitted from the COAP
> message sent on the wire.
>
> The statement above
>
> When omitted, they are logically
> assumed to be the transport protocol destination address and port
> respectively. Explicit Uri-Host and Uri-Port Options are
> typically used when an endpoint hosts multiple virtual servers and
> uses the Options to route the requests accordingly.
>
> and the last quoted statement: How can the sender know whether or not
> it is Ok to omit Uri-Host/Uri-Port?
How do you know when you need to send SNI to a TLS server? "If you try
without and get a strange certificate back." I think that a similar
situation is possible here, though of course you may just know from
out-of-band configuration.
[JLS] That is the exact case that I was about to bring up. Of course you
can always send the SNI for TLS because there is lots of "space" in the TCP
connection to hold it. This is targeted at the case where you have multiple
CoAP servers sitting on the same address/port pair. I think this is going
to be a very rare case as the use of an additional port or address is fairly
simple and the savings on the wire of not including the host and port
options can be significant.
> 7. Parameters
>
> It is recommended, based on experiments,
> to follow the default CoAP configuration parameters ([RFC7252]).
> However, depending on the implementation scenario, retransmissions
> and timeouts can also occur on other networking layers, governed by
> other configuration parameters. When a change in a server parameter
> has taken place, the parameter values in the communicating endpoints
> MUST be adjusted as necessary.
>
> The last sentence: use of MUST with passive voice is really unhelpful
here.
> Adjusted by whom? How can this MUST be satisfied?
[JLS] My assumption is that is this going to be done either by a congestion
protocol, a couple have been looked at in the CoRE working group. It could
also be done by a provisioning agent or by a firmware update. Lots of
options but no specific one is required.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Comment:
>
> 5.1. Discovery and URIs
>
> Clients and servers MUST support the short resource EST-coaps URIs.
>
> Just to clarify: the original EST URIs are prohibited in COAP-EST?
My understanding is that the servers also have to support the original
(long) EST paths.
[JLS] My understanding is that the short names MUST be supported. Support
for the long names is optional and would probably be implemented as aliases
on the server side. I would not expect clients to use the long names as
they consume more network bandwidth (hence the short names). A server is
very likely to support both the long and short names if it is supporting
both EST and COAP-EST.
jim
-Ben
> In 5.8:
>
> In the case where the asymmetric encryption key is suitable for
> transport key operations the generated private key is encrypted with
> a symmetric key which is encrypted by the client-defined (in the
> CSR)
>
> I would break up this sentence into 2 to make it clearer, as I
> initially read this as 2 encryption operations applying to the generated
private key itself.
> So I suggest something like:
>
> In the case where the asymmetric encryption key is suitable for
> transport key operations the generated private key is encrypted with
> a symmetric key. The symmetric key itself is encrypted by the
> client-defined (in the CSR)
>
> asymmetric public key and is carried in an encryptedKey attribute in
> a KeyTransRecipientInfo structure.
>
> Finally, if the asymmetric
> encryption key is suitable for key agreement, the generated private
> key is encrypted with a symmetric key which is encrypted by the
> client defined (in the CSR) asymmetric public key and is carried in
> an recipientEncryptedKeys attribute in a KeyAgreeRecipientInfo.
>
> As above.
>
>
_______________________________________________
Ace mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ace
