Re: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17: (with DISCUSS and COMMENT)

["Panos Kampanakis (pkampana)" <[e-mail]>]

Hi Alexey, 

Thanks for the feedback. 

We are tracking all your 4 comments and discussion points in a git issue in
https://github.com/SanKumar2015/EST-coaps/issues/155 There are 4 comments in
the issue, one for each of your points. The comments include all exchanged
information in this thread with Ben K, Jim S., Carsten, and Peter. 

At the end of each comments in the git issue you will see the change we
intend to make in the draft to address the feedback. Let us know if any of
them does not make sense. 

Rgs,
Panos



-----Original Message-----
From: Ace <[e-mail]> On Behalf Of Alexey Melnikov via
Datatracker
Sent: Wednesday, December 18, 2019 8:27 AM
To: The IESG <[e-mail]>
Cc: [e-mail]; [e-mail];
[e-mail]; [e-mail]
Subject: [Ace] Alexey Melnikov's Discuss on draft-ietf-ace-coap-est-17:
(with DISCUSS and COMMENT)

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?

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?


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

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
[e-mail]
https://www.ietf.org/mailman/listinfo/ace