Hi Panos, Sorry for the slow reply -- it was a busy telechat week for the IESG. These changes look good; please go ahead and re-upload.
Thanks, Ben On Mon, Dec 02, 2019 at 05:37:07AM +0000, Panos Kampanakis (pkampana) wrote: > Hi Ben, > > Can you confirm if the diff > https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f93657955555f2302baef2e39709ae05 > addresses your feedback? I will then re-upload it. > > Thanks, > Panos > > -----Original Message----- > From: Ace <[email protected]> On Behalf Of Panos Kampanakis (pkampana) > Sent: Monday, November 18, 2019 2:07 PM > To: Benjamin Kaduk <[email protected]> > Cc: Yaron Sheffer <[email protected]>; > [email protected]; [email protected] > Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 > > Hi Ben, > > All addressed, except for the last one. The diff is here > https://github.com/SanKumar2015/EST-coaps/commit/53933bb9f93657955555f2302baef2e39709ae05 > > > My responses below in Pk> > > I will wait for your confirmation before I upload version 17. > > Panos > > > -----Original Message----- > From: Benjamin Kaduk <[email protected]> > Sent: Tuesday, November 12, 2019 6:06 PM > To: Panos Kampanakis (pkampana) <[email protected]> > Cc: Yaron Sheffer <[email protected]>; > [email protected]; [email protected] > Subject: Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15 > > Hi Panos, > > On Wed, Oct 16, 2019 at 03:06:01PM +0000, Panos Kampanakis (pkampana) wrote: > > Hi Yaron, > > > > Thank you for the thorough review and feedback. > > > > To make sure I don't miss any of your comments over an email thread, I > > track all your feedback in git issue 152 > > https://github.com/SanKumar2015/EST-coaps/issues/152 There I tried to > > address all your comments and question and clarify some points. > > > > I also pushed minor changes to fix a few of the issues you brought up. > > The diff of the changes pushed is here > > https://github.com/SanKumar2015/EST-coaps/commit/86d785f2122596f28674f > > e8e403d30467c98abfb > > > > Please review the git issue and let us know if there are pending concerns. > > Otherwise I am planning to reupload a new iteration next week. > > Thanks for uploading the -16, and thanks again to Yaron for the very > thoughtful review. > > Sadly, I seem to have not looked at the github diff closely enough/in a > timely fashion, so I think we'll need to publish a -17 before I can move this > into IESG evaluation. Here's my remaining notes: > > Section 4 > > Private keys can be transported as responses to a server-side key > generation request as described in Section 4.4 of [RFC7030] and > discussed in Section 5.8 of this document. > > I think that, since Yaron brought it up, we should say "Section 4.4 of > [RFC7030] (and subsections)". > > PK> Fixed. > > curve. After the standardization of [RFC7748], support for > Curve25519 will likely be required in the future by (D)TLS Profiles > for the Internet of Things [RFC7925]. > > Sorry I missed this before -- "standardization" is a bit of a bugbear (7748 > is Informational, not even Standards-Track, let alone full Internet Standard). > > Pk> Replaced "standardization" with "publication". > > In a constrained CoAP environment, endpoints can't always afford to > establish a DTLS connection for every EST transaction. > Authenticating and negotiating DTLS keys requires resources on low- > end endpoints and consumes valuable bandwidth. To alleviate this > situation, an EST-coaps DTLS connection MAY remain open for > sequential EST transactions. For example, an EST csrattrs request > that is followed by a simpleenroll request can use the same > authenticated DTLS connection. However, when a cacerts request is > > I think we can also clarify that this "MAY remain open" is changing > expectations from RFC 7030, where the expectation was that the TLS connection > did not remain open. > > Pk> I added " which was not the case in [RFC7030]" > > Section 10.1 > > the first DTLS exchange. Alternatively, in a case where a /sen > request immediately follows a /crts, a client MAY choose to keep the > connection authenticated by the Implicit TA open for efficiency > reasons (Section 4). A client that interleaves EST-coaps /crts > request with other requests in the same DTLS connection SHOULD > revalidate the server certificate chain against the updated Explicit > TA from the /crts response before proceeding with the subsequent > requests. If the server certificate chain does not authenticate > against the database, the client SHOULD close the connection without > completing the rest of the requests. The updated Explicit TA MUST > continue to be used in new DTLS connections. > > I think Yaron was saying that "even if the optimization of keeping the DTLS > connection open is useful in the general case, it is very risky and prone to > misimplementation when combined with /crts". So, if I can rephrase the > propsal to be that we say something more like "even though in general the > DTLS connection can remain open for efficiency (Section 4), after a /crts > response, the client MUST close the DTLS connection and establish a new DTLS > connection for subsequent EST exchanges", are there reasons that we shouldn't > use that behavior? > > Pk> I am not sure it is worth to add more complexity specific to /crts. > Pk> We would be adding more complexity for the client to track if this > Pk> TLS connection is a cacerts connection then I need to close it, if > Pk> it is any other connection then I can interleave requests. I am not > Pk> convinced that the risk is that big either. A malicious user that > Pk> was authenticated by the Implicit DB could easily craft a cacerts > Pk> response that allows him to be authenticated by the Explict DB. In > Pk> other words an active attacker would have no problems of fooling the > Pk> Explicit DB if he was allowed in by the Implicit DB. I think the > Pk> whole issue here is conceptual. The moment we get a new Trust DB we > Pk> need to trust it and not use the old one, but I don't think that > Pk> keeping the connection open for one or two more requests is that > Pk> risky. Even RFC7030 allows for it in the event that the client does > Pk> not have an Implicit DB when it is starting > " The client MAY > provisionally continue the TLS handshake to completion for the > purposes of accessing the /cacerts or /fullcmc method. " > I think the language as it is now is pretty clear on what we are trying to > do. And the Security Considerations spells out clearly. Of course, as always, > some implementer could make a mistake, but that could happen with RFC7030 and > any other RFC as well. > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
