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/86d785f2122596f28674fe8e403d30467c98abfb > > > 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)". 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). 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. 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? Thanks, Ben _______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
