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

["Alexey Melnikov" <[e-mail]>]

Hi Jim,

On Fri, Dec 20, 2019, at 1:16 AM, Jim Schaad wrote:
> 
> 
> -----Original Message-----
> From: Benjamin Kaduk <[e-mail]> 
> Sent: Thursday, December 19, 2019 4:47 PM
> To: Alexey Melnikov <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail];
> [e-mail]; [e-mail]; [e-mail]
> 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

> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------

 (snip)

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

I think the text needs clarifying, as it is not clear on that.

> > ----------------------------------------------------------------------
> > 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 don't think this is clear, so it should be clarified in the document.

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