Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2

[Benjamin Kaduk <[e-mail]>]

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-coap-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 <[e-mail]> On Behalf Of Panos Kampanakis (pkampana)
> Sent: Tuesday, September 10, 2019 12:18 AM
> To: Jim Schaad <[e-mail]>; 'Michael Richardson' <[e-mail]>
> Cc: [e-mail]; 'Benjamin Kaduk' <[e-mail]>; [e-mail]
> 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 <[e-mail]> On Behalf Of Jim Schaad
> Sent: Monday, September 09, 2019 11:34 PM
> To: 'Michael Richardson' <[e-mail]>
> Cc: [e-mail]; 'Benjamin Kaduk' <[e-mail]>; [e-mail]
> 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 <[e-mail]>
> Sent: Monday, September 9, 2019 1:17 PM
> To: 'Michael Richardson' <[e-mail]>; 'Benjamin Kaduk'
> <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: RE: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
> 
> 
> 
> -----Original Message-----
> From: Michael Richardson <[e-mail]> 
> Sent: Monday, September 9, 2019 9:38 AM
> To: Benjamin Kaduk <[e-mail]>
> Cc: [e-mail]; [e-mail]
> Subject: Re: [Ace] AD review of draft-ietf-ace-coap-est-12 part 2
> 
> 
> Benjamin Kaduk <[e-mail]> 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.