Hi Ben, Thank you again for the additional feedback.
The changes are summarized in the git issue https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-535065314 I mostly made all the suggested text changes, summarized our discussion about extended-master-secret. I also made a change in Fig 2 and Fig 3 to address the issue you caught with the /128 blocks. The diff is here https://github.com/SanKumar2015/EST-coaps/commit/d16c53d3360430b5587021dc1a2d31f668c0c0fe . And a minor nit fix in https://github.com/SanKumar2015/EST-coaps/commit/ff5b303781231e34571352cb07fb895d5ecab791 I will reupload early next week. Please check out the issue in case you have further comments. Panos -----Original Message----- From: Ace <ace-boun...@ietf.org> On Behalf Of Benjamin Kaduk Sent: Monday, September 23, 2019 6:48 PM To: Panos Kampanakis (pkampana) <pkamp...@cisco.com> Cc: Peter van der Stok <stokc...@bbhmail.nl>; Jim Schaad <i...@augustcellars.com>; draft-ietf-ace-coap-est....@ietf.org; Michael Richardson <m...@sandelman.ca>; ace@ietf.org Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 Hi Panos, Sorry for the slow response here -- I was in telechat-prep mode last week. This is in pretty good shape, and I wanted to especially thank you for the presentation in the github issue -- that format was extremely helpful for me. I think we will probably need to upload one more minor revision before I initiate the IETF LC; please seem my comments below. In Section 4, I think we need to put the "for" back in "requests for a trusted certificate list". Also, refresh my memory: did we decide that there's no need to explicitly mandate the use of the "extended_master_secret" TLS extension? I'd also change the note about supported_groups vs. Supported Elliptic Curves to read "In addition, in DTLS 1.3 the Supported Elliptic Curves extension has been renamed to Supported Groups." I think we can move /csrattrs to the bottom of Table 2 (thank you for changing Table 1!). With the changes to the example in Figure 3, can you walk me through the block-size negotiation? Quoting: POST [2001:db8::2:1]:61616/est/sen(CON)(1:N1/0/256){CSR (frag# N1+1)}--> | ... Immediate response when certificate is ready ... | <-- (ACK) (1:N1/0/256) (2:0/1/256) (2.04 Changed){Cert resp (frag# 1)} POST [2001:db8::2:1]:61616/est/sen (CON)(2:1/0/128) --> <-- (ACK) (2:1/1/128) (2.04 Changed) {Cert resp (frag# 2)} So the ACK to the final fragment of the POST includes (2:0/1/256), or the first fragment of a 256-byte-fragmented version of the response. The client then goes and asks for (2:1/0/128), which is the second fragment of a 128-byte-fragmented version of the response. Is that just going to be the last 128 bytes of the thing it already got from the server? If so, is that something it would actually do (e.g., if it had to drop part of the server's response due to a buffer-size limitation) or is it not possible to only have part of a fragment (so it would need to either ask for (2:0/0/128) or (2:2/0/128)? It looks like you removed the text about "[the two representations] do not have to be in a particular order since each representation is preceded by its Content-Format ID" based on my remark about core-multipart-ct; that document has since been approved by the IESG and is explicitly confirming that there is no specific ordering requirement (in contrast to multipart/mixed), so we could put that clause back in this document if desired. I consider it more likely than not that a directorate reviewer will want to tweak the added language at the end of Section 5.8 explaining our divergence from RFC 7030; if you want to preemptively reword, my suggestion would be "Although [RFC7030] strongly recommends that clients request the use of CMS encryption on top of the TLS channel's protection, this document does not make such a recommendation; CMS encryption can still be used when mandated by the use case." Thanks! -Ben On Mon, Sep 16, 2019 at 05:38:59PM +0000, Panos Kampanakis (pkampana) wrote: > Hi Ben, > > I think we have now addressed all your feedback from the AD review. A big > chunk of the changes were agreed upon in the list emails threads. > > The iteration that we are planning to upload that includes all the > changes is at > https://github.com/SanKumar2015/EST-coaps/blob/master/draft-ietf-ace-c > oap-est.txt > > The summary of all your comments and what went into the text is in the > git issue https://github.com/SanKumar2015/EST-coaps/issues/150 To > break it down > - https://github.com/SanKumar2015/EST-coaps/issues/150#issue-489289217 has > most of the changes agreed on the list. > - > https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-528001807 > has an answer to your question about addressing the tls-unique issue in a new > draft. > - https://github.com/SanKumar2015/EST-coaps/issues/150#issuecomment-531853281 > has the last changes in response to your feedback that went into the draft > after Peter uploade the -13 iteration. > > Two places to pay attention to is that I removed the > > It is strongly RECOMMENDED that the clients request that the returned > > private key be afforded the additional security of the Cryptographic > > Message Syntax (CMS) EnvelopedData in addition to the TLS-provided > > security to protect against unauthorized disclosure." > and the > > The corresponding longer URIs from [RFC7030] MAY be supported." > The rationale behind that is in the git issue. > > Please have a look and let us know if there is anything missing. Otherwise we > will upload at the end of the week. > > Rgs, > Panos > > > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of Panos Kampanakis > (pkampana) > Sent: Tuesday, September 10, 2019 12:18 AM > To: Jim Schaad <i...@augustcellars.com>; 'Michael Richardson' > <mcr+i...@sandelman.ca> > Cc: draft-ietf-ace-coap-est....@ietf.org; 'Benjamin Kaduk' > <ka...@mit.edu>; ace@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 > > Hi Jim, > > We are tracking all of Ben's feedback here > https://github.com/SanKumar2015/EST-coaps/issues/150 > > The fixes that have gone in the draft so far are after each comment. There > are still some that we still need to update after the threads converged. > > Panos > > > -----Original Message----- > From: Ace <ace-boun...@ietf.org> On Behalf Of Jim Schaad > Sent: Monday, September 09, 2019 11:34 PM > To: 'Michael Richardson' <mcr+i...@sandelman.ca> > Cc: draft-ietf-ace-coap-est....@ietf.org; 'Benjamin Kaduk' > <ka...@mit.edu>; ace@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 > > Authors, > > Are we ready to produce a new draft that addresses most, if not all, of Ben's > comments? Do we have a pull request to deal with this that we can point to? > > Jim > > > -----Original Message----- > From: Jim Schaad <i...@augustcellars.com> > Sent: Monday, September 9, 2019 1:17 PM > To: 'Michael Richardson' <mcr+i...@sandelman.ca>; 'Benjamin Kaduk' > <ka...@mit.edu> > Cc: draft-ietf-ace-coap-est....@ietf.org; ace@ietf.org > Subject: RE: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 > > > > -----Original Message----- > From: Michael Richardson <mcr+i...@sandelman.ca> > Sent: Monday, September 9, 2019 9:38 AM > To: Benjamin Kaduk <ka...@mit.edu> > Cc: draft-ietf-ace-coap-est....@ietf.org; ace@ietf.org > Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2 > > > Benjamin Kaduk <ka...@mit.edu> wrote: > >> So, on a constrained device, I'd like to know what to expect (what to > >> code for). While I do'nt particularly care for > server-generated keys, > >> it should probably be specified correctly. I see that the complexity > >> of sorting this means that I think that Content-Format 284 > >> (unprotected) will get used most often. > > > Your constrained device is probably only going to implement one cipher > > [mode], too, right? If it's an AEAD mode, you use AuthEnvelopedData; > > otherwise, classic EnvelopedData. > > Yes, but each constrained device type might have a different set, and > the EST server for such an installation has to figure out how to send > the right thing. > > [JLS] This is the function of section 4.4.1.1 in RFC 7030 which says > that the DecryptKeyIdentifier must be present. This will provide the > EST server a method to identify the correct key and the correct > symmetric encryption algorithm. > > >> I think that we could go to TLS Exporter right now, but it would take > >> some work. > > > I'd rather have both classic-EST and coap-EST benefit than just > > coap-EST. > > So you'd agree to deferring this to a document (maybe in LAMPS?) that > would > Updates: 7030 and this document. _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
