Re: [Ace] Secdir last call review of draft-ietf-ace-coap-est-15

[Benjamin Kaduk <[e-mail]>]

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