Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07

[Jim Schaad <[e-mail]>]

> -----Original Message-----
> From: Ace <[e-mail]> On Behalf Of Jim Schaad
> Sent: Monday, January 28, 2019 1:37 PM
> To: 'Panos Kampanakis (pkampana)' <[e-mail]>; [e-mail]
> Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
> 
> Clipping out things which are not issues:
> 
> 
> > -----Original Message-----
> > From: Ace <[e-mail]> On Behalf Of Panos Kampanakis
> > (pkampana)
> > Sent: Friday, January 18, 2019 12:59 PM
> > To: Jim Schaad <[e-mail]>; [e-mail]
> > Subject: Re: [Ace] FW: WGLC comments draft-ietf-ace-coap-est-07
> >
> > Hi Jim,
> >
> > Again, thank you for your thorough reviews. We addressed all of them.
> > The new version of the draft is at
> > https://github.com/SanKumar2015/EST-
> > coaps/blob/master/draft-ietf-ace-coap-est.txt
> >
> > For a more easily consumable content, your latest feedback was tracked
> > and addressed here https://github.com/SanKumar2015/EST-
> > coaps/issues?utf8=%E2%9C%93&q=is%3Aissue+draft-ietf-ace-coap-est-07
> >
> > I also lay out the changes  below:
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > - About the persistent DTLS connections (Sect 7), the last two
> > paragraphs
> of
> > section 7 explain why in some cases DTLS connections need to stay open
> > for a limited amount of time. They also point to the Section 11.1
> > about the caveats of a persistent connection and the implicit DB. I do
> > not think it
> is up to
> > this draft to tell the client that he should use the new cert after an
> > enrollment. The old cert might still be perfectly valid or the new
> > cert
> may be
> > generated for a non DTLS client auth use. So, I don't think we need to
> state in
> > this draft that the new cert needs to be used in new DTLS connections.
> >
> > - About the DTLS connections (Sec 11.1), We have usecases where a
> > client does not want to spend the resources, time, performance
> > implications to do
> > 3-5 DTLS connections back to back in order to update its trustanchor
> > and
> do
> > its enrollments for multiple certs. In this cases, explained in
> > section 7
> last
> > paragraphs will keep a persistent DTLS connection. That is what
> > section
> 11.1 is
> > trying to explain. Please keep in mind that in there we state that it
> > is RECOMMENDED for the client to start using the new explicit DB right
> > after the cacerts request. We just add the MAY keep the authenticated
> > with implicit DB DTLS connection open in some cases, but then he MUST
> > use the new DB starting for the next DTLS connection.
> >
> > So, I think our language in Sections 7 and 11.1 suffices when talking
> about
> > persistent TLS connections.
> 
> Any time that the set of trust anchors is changed, you have also changed
the
> set of things that you are going to trust.  If you remove the trust anchor
for
> the current connection, or restrict it in some manner, you may no longer
> have any trust in that connection.  This is the worry that I have.  I
completely
> agree that doing multiple certificate requests (not sure why) or a query
> about the csr attributes followed by the certificate request is totally
> reasonable.
> 
> You say that the client should use the new explicit trust anchors right
after
> the cacerts request, but if you do not tear down the DTLS connection you
are
> not doing that.  You are still using the old implicit trust anchors.
> The MAY in section 11.1 for me is overridden by the previous SHOULD unless
> this case is specifically called out in section 7.  I cannot understand
the logic
> that says when you get a certificate a year from now the explicit TAs
SHOULD
> be used, but it does not matter when you get the first certificate.
> 
> *  It does not look from the version on github that you made any changes
for
> the examples:
> 
> Examples:
> 
> * Section A.1  I don't know what the meaning of Max-Age would be for a GET
> request.  You may want to remove this just to avoid confusion.
> 
> * Section A.2 - I am unclear about the Content-Format note in this
example.
> If you are asking for a specific content then the correct option would be
> Accept.  If you are indicating the content type of the response then you
> should probably put a header line in to that effect.
> 
> In the virtual CoAP WG meeting last week we went through in some explicit
> detail that both Content-Format and Max-Age have no meaning when
> appearing on a request and therefore should not be there.
I may be wrong about content-format, but if there is only one choice I am
not sure that it is needed.
> 
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace