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

["Panos Kampanakis (pkampana)" <[e-mail]>]

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 <[e-mail]> On Behalf Of Panos Kampanakis (pkampana)
Sent: Monday, November 18, 2019 2:07 PM
To: Benjamin Kaduk <[e-mail]>
Cc: Yaron Sheffer <[e-mail]>; [e-mail]; [e-mail]
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 <[e-mail]>
Sent: Tuesday, November 12, 2019 6:06 PM
To: Panos Kampanakis (pkampana) <[e-mail]>
Cc: Yaron Sheffer <[e-mail]>; [e-mail]; [e-mail]
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
[e-mail]
https://www.ietf.org/mailman/listinfo/ace